Organizzazione del codice sorgente in TFS 2010

Question

Abbiamo appena installato TFS 2010. Migreremo la nostra fonte in TFS ma ho una domanda su come organizzare il codice.

TFS 2010 ha un nuovo concetto di raccolte di progetti, quindi ho deciso che gruppi diversi all'interno della nostra organizzazione otterranno il proprio gruppo. Il mio team sviluppa molte applicazioni web diverse e abbiamo diversi componenti condivisi. Utilizziamo anche alcuni componenti di terze parti (come Telerik).

Chiaramente ogni applicazione Web è un proprio progetto, ma dove inserisco i componenti condivisi? Ogni componente dovrebbe essere nel proprio progetto con build e oggetti di lavoro separati?

Esiste una procedura consigliata o un modo consigliato per eseguire questa operazione specifica per TFS 2010?

Answer 1

La procedura consigliata consiste nell'avere tutto ciò che è necessario per creare una soluzione nella cartella Principale/Tronco. Noi utilizzare il seguente formato:

"Project 1" 
    "DEV" (Folder) 
     "Feature 1" (Branch) 
     "Main" (Root branch) 
    "Release" (Folder) 
     "Release 1" (Branch) 
    "RTM" (Folder) 
     "Release 1.0" (Branch) 
     "Release 1.1" (Branch) 

Questo mantiene tutti i rami allo stesso livello in modo da non avere alcun dubbio su quale sia un ramo e che è una cartella.

Questo è il tuo Struttura del progetto della squadra, ma per quanto riguarda la struttura della cartella reale in ciascuno dei comparti:

Main (Root branch) 
    "Builds" (Folder that contains all of the MSBuild and Workflows for building) 
    "Documents" (Folder that contains version specific documents) 
    "Deployment" (Folder that contains config required for deployment | We use TFS Deployer from Codeplex) 
    "Setup" (Folder contains all of the setup resources) 
    "[Company].[Namespace].*" (Folders that contains a project) 
    "Tools" (Folder for all your nuts and bolts) 
    "Toolname" (Folder for a specific tool or reference library) 

L'idea è che sia la scelta del team se utilizzare una nuova versione di un prodotto esterno o libreria di riferimento. Solo perché una squadra può eseguire l'aggiornamento a una nuova versione di NUnit non significa che un'altra squadra scelga di non farlo in quanto si tratta di settimane di lavoro.

Con tutti i mezzi, un progetto "Strumenti" centrale che aggiorni sempre con le ultime e il tuo team tira da lì, ma non ha dipendenze esterne. Rende un incubo creare build automatizzati e consente agli sviluppatori di aggiornarsi anche se non è un buon momento. Inoltre, assicurati di trattare qualsiasi dipendenza esterna come uno strumento anche se proviene da un altro team interno.

Riferimenti:TFS Deployer

Answer 2

Ho due risposte: cosa facciamo e cosa suggerisco per voi.

Per noi, abbiamo una suite di app Web che hanno tutti MOLTI componenti condivisi. In quanto tale, sebbene si tratti di circa 50 diversi assembly (VS Projects) e 5-10 soluzioni (a seconda di come la si guarda), c'è una sovrapposizione molto significativa tra tutti loro, il che significa che vogliamo usare TFS per-dev piuttosto che unire di ramificare e unire le risorse sovrapposte. Pertanto, manteniamo tutto ciò in un unico progetto TFS. Ecco come abbiamo impostato la nostra (nomi cambiati per dare un senso a voi):

"Official Projects" (Collection) 
    "Production Applications" (Project) 
    "Technology Proof of Concepts" (Project) 
    "Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future. 
    "TFS Configuration" (Project) 
"Playground" (Collection) 
    "John Doe" (Project) 
    "Jane Doe" (Project) 
    "Security Team" (Project) 
    "Production Test" (Project) 

Nella nostra messa a punto, abbiamo un posto per il codice ufficiale della società. Inoltre, disponiamo di un'area in cui le persone possono divertirsi senza temere di incasinare nulla mentre sono in grado di trarre vantaggio da vari benefici correlati a TFS.

Tuttavia, nel tuo scenario, se sto leggendo tra le righe correttamente, vorrei suggerire qualcosa di diverso. Le mie ipotesi:

1. Ogni progetto, oltre ad avere alcune assemblee comuni (sto pensando di registrazione, la sicurezza, e di altri gruppi di utilità che sono condivisi a livello aziendale), sono progetti non collegati.
2. Gli assembly condivisi/comuni non vengono regolarmente modificati, quindi è possibile utilizzare riferimenti DLL anziché riferimenti di progetto in cui si utilizza sempre la versione aggiornata del giorno/ora del codice.
3. (presupposto basato su TFS mentre sto ancora imparando) È possibile diramare i progetti dalla stessa raccolta ma non è possibile diramarli tra le raccolte.
4. Oltre agli assembly condivisi sopra menzionati, nessun altro codice è condiviso tra i team.

Quindi, con questi presupposti, vorrei andare con qualcosa di simile:

"Common Resources" (Collection) 
    "Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc. 
    "Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions. 
    "Version 2" (Project) 
    "Version 3" (Project" 
    etc. 
"Team 1" (Collection) 
    "Project 1" 
    "Project 2" 
    "Project 3" 
    "Project 4" 
    "Project 5" 
"Team 2" (Collection) 
    "Project 1" 
    "Project 2" 
    "Project 3" 
"Team 3" (Collection) 
    "Project 1" 
    "Project 2" 
etc. 

Facendo in questo modo, si fa riferimento alle assemblee comuni tramite i riferimenti DLL. Tu come team o dev su un progetto specifico puoi decidere quando inizi a utilizzare una versione più recente di un assembly comune. Per fare ciò, si ottiene semplicemente l'ultima versione sul ramo di quella versione e quindi si aggiunge un riferimento ad esso. Se la mia ipotesi n. 3 è sbagliata, allora spero che tu possa fare qualcosa di meglio. Altrimenti, ogni progetto ha il proprio spazio (che può contenere più di una soluzione/progetto VS che è una buona idea) e il tuo team ha la propria collezione per stare lontano dagli altri team.

Solo il mio $ 0.02 vale ...

Answer 3

Usa gli spazi di lavoro, non solo il lavoro attraverso team di recupero, ma funziona con la maggior parte delle tecniche di controllo delle versioni.

Answer 4

Abbiamo adottato un approccio semplice a componenti di terze parti e creato per loro un progetto separato. Quindi, quando un altro progetto deve fare riferimento all'assembly o alla DLL, si dirama la cartella in cui si trova l'assembly, in una cartella "ThirdParty" nel progetto di destinazione.

Questo ci dà anche un meccanismo per distribuire gli aggiornamenti a gruppi di terze parti in modo graduale utilizzando un'unione in avanti dalla cartella di base.