Il modo migliore: ristrutturare una soluzione esistente Team Foundation Server (TFS)

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

Ma: esiste un'unica soluzione TFS di grandi dimensioni per tutte le nostre applicazioni e librerie:

• Soluzione principale
  • applicazioni
    
    • App 1
    • App 2
    • App 3
  • Esterni
  • biblioteche
    
    • Lib 1
    • Lib 2
  • Utensili

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

Il percorso "Externals" contiene alcune DLL esterne a cui fanno riferimento le 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 citati nei progetti Librerie e Strumenti.

Il percorso Strumenti contiene alcuni programmi di supporto come help di installazione, aggiornamento di servizi Web, ecc.

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

• Non possiamo usare build di server.
• È scomodo gestire la gestione della mischia di 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 ...

Cosa cambieresti in questa soluzione? Come suddivideresti questi progetti in soluzioni più piccole, come dovrebbero essere strutturate tali soluzioni.

Il mio primo approccio sarebbe quello di creare un progetto TFS per ogni applicazione, libreria e strumento. Ma come posso assicurarmi che, ad esempio, App 2 contenga 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 in qualche modo posso forzare Visual Studio a utilizzare sempre la versione più recente di un progetto esterno?

Modifica: su TFS, c'è solo una raccolta di progetti di team TFS, contenente un progetto di team TFS. Il Team Project contiene una soluzione Visual Studio di grandi dimensioni, che contiene diverse cartelle contenenti (vedere la struttura sopra) con ciascuna contenente più progetti VS.

La mia domanda è ora, come vorresti riorganizzare:

1. I progetti del team TFS
2. I progetti VS.

Attenersi a un progetto di gruppo TFS, avere più diventa una seccatura quando si tenta di aggiornare e presenta alcune limitazioni quando si tratta di elementi di lavoro del progetto a squadre incrociate. Invece dovresti fare un uso intensivo di aree e iterazioni.

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

TFS2012 ha un nuovo concetto chiamato Teams, crea un team per applicazione e imposta iterazioni e backlog predefiniti per ognuno. In questo modo è possibile gestire il backlog per ciascuno o visualizzare il team di root per visualizzare un backlog arrotolato. Quindi puoi gestire gli sprint a livello di applicazione o in generale a seconda di ciò che ti si addice.

Crea pacchetti NuGet per tutte le librerie di riferimento di terze parti che non ne dispongono già. Memorizzarli in un repository privato (cartella condivisa di Windows) e abilitare la funzione di ripristino del pacchetto per NuGet facendo clic con il tasto destro su ogni soluzione e abilitandola (consentire anche il ripristino del pacchetto per scaricare i pacchetti in vs impostazioni).

Se hai librerie interne condivise, crea anche pacchetti NuGet per loro e crea una soluzione vs che contenga solo quella libreria. Aggiungi un comando post build per creare il pacchetto nuget o estendi il tuo modello tfs build per farlo (ci sono un certo numero di modelli là fuori che lo fanno già).