Modo migliore: ristrutturare una soluzione esistente di Team Foundation Server (TFS)

Question

Modo migliore: ristrutturare una soluzione esistente di Team Foundation Server (TFS)

#1 da (11 voti)

12

Nel mio reparto stiamo sviluppando diversi AddOns più piccoli per alcuni server di comunicazione unificati. Per il controllo delle versioni e lo sviluppo distribuito utilizziamo un Team Foundation Server 2012.

Ma c'è solo una grande soluzione TFS per tutte le nostre applicazioni e librerie:

Soluzione principale
- Applicazioni
  - App 1
  - App 2
  - App 3
- Esterni
- Biblioteche
  - Lib 1
  - Lib 2
- Strumenti

Il percorso "Applicazione" contiene tutte le applicazioni principali. Questi non dipendono l'uno dall'altro, ma dipendono dai progetti Librerie ed Esterni.

Il percorso "Externals" contiene alcune DLL esterne a cui si fa riferimento nelle nostre applicazioni e librerie.

Il percorso Librerie contiene librerie di uso comune (modelli di interfaccia utente, classi di supporto, ecc.). Non dipendono l'uno dall'altro e vengono referenziati nei progetti Librerie e Strumenti.

Il percorso Strumenti contiene alcuni programmi di supporto come gli helper di installazione, l'aggiornamento dei servizi Web, ecc.

Ora, ci sono alcuni punti importanti per cui vorrei cambiare questa struttura:

Non possiamo utilizzare le build del server.
È scomodo gestire la gestione della Scrum TFS con sprint, impedimenti, ecc. con una struttura di soluzione del genere.
Ogni sviluppatore ha sempre accesso a tutti i progetti nella soluzione.
Una build completa dura troppo a lungo se si colpisce accidentalmente [F6] in Visual Studio ...

Che cosa cambieresti in questa soluzione? Come rompere questi progetti in soluzioni più piccole, come dovrebbero essere strutturate queste soluzioni.

Il mio primo approccio sarebbe, per creare un progetto TFS per ogni applicazione, libreria e strumento. Ma come posso garantire che, ad es. L'app 2 contiene sempre la versione più recente di Lib 1? Devo monitorare le modifiche su Lib 1 e aggiornare l'App 2 manualmente non appena cambia la Lib? O posso in qualche modo forzare Visual Studio ad usare sempre la versione più recente di un progetto esterno in qualche modo?

Modifica: sul TFS c'è solo una raccolta di progetti di team TFS, contenente un progetto di team TFS. Il progetto Team contiene una grande soluzione di Visual Studio, che contiene diverse cartelle contenenti (vedi la struttura sopra) con ognuna di esse contenente più progetti VS.

La mia domanda ora è, come vorresti riorganizzare:

I progetti del team TFS
I progetti VS

project-management projects-and-solutions team-foundation-server

posta dhh 05.12.2012 - 21:03

fonte

1 risposta

Leggi altre domande sui tag project-management projects-and-solutions team-foundation-server

Ereditarietà vs proprietà aggiuntive con valore null Quanto è stato progettato prima? [duplicare]

score 11 · Accepted Answer

Rimanere uniti con un progetto TFS Team, che diventa un problema quando si tenta di eseguire l'aggiornamento e presenta alcune limitazioni quando si tratta di elementi di lavoro del progetto cross-team. Invece dovresti fare un uso pesante di Aree e Iterazioni.

Dividi la tua soluzione VS in più soluzioni, una per applicazione principale. Questo accelera molto le build locali, così come il build server.

TFS2012 ha un nuovo concetto chiamato Teams, crea un team per applicazione e imposta iterazioni e backlog predefiniti per ciascuno. In questo modo è possibile gestire il backlog per ciascuno o visualizzare il team root per visualizzare un backlog arretrato. Quindi puoi gestire gli sprint a livello di applicazione o, in generale, a seconda delle tue esigenze.

Crea pacchetti NuGet per tutte le librerie di riferimento di terze parti che non ne hanno già uno. Memorizzali in un repository privato (cartella condivisa di Windows) e abilita la funzionalità di ripristino del pacchetto per NuGet facendo clic con il pulsante destro del mouse su ogni soluzione e attivandola (consente anche il ripristino del pacchetto per scaricare i pacchetti nelle impostazioni vs).

Se si dispone di librerie interne condivise, creare anche pacchetti NuGet e creare una soluzione vs contenente semplicemente tale libreria. Aggiungi un comando post build per creare il pacchetto nuget o estendi il tuo modello di build tfs per farlo (ci sono già un certo numero di modelli che lo fanno già).