Durante l’evento Alm@Work14 organizzato da DomusDotNet, ho notato un certo interesse riguardo la sessione sull’organizzazione dei Team Project in un Team Foundation Server ed ho quindi deciso di pubblicare qualche post sull’argomento su GetLatestVersion.

La prima problematica che molti hanno è quella di decidere a cosa corrisponde un Team Project nella propria azienda, decisione che

• 1) è tutt’altro che semplice
• 2) non è univoca e dipende dalla propria organizzazione.

Detto questo si capisce come purtroppo sia possibile sbagliare nell’organizzazione e quindi vi è la necessità di capire come riorganizzare il tutto. Ad esempio una azienda potrebbe partire creando un Team Project per ogni commessa/progetto, per rendersi poi conto che in realtà in questo modo si è frazionato troppo l’ambiente. I fattori da tenere in considerazione sono molti e necessiterebbero di molti post dettagliati, nondimeno è possibile dare delle linee guida generiche.

La prima linea guida che mi sento di dare è evitare di creare troppi Team Project, anzi, nella maggioranza dei casi un solo Team Project può essere più che sufficiente ed è il miglior modo di gestire i propri progetti.

Questa considerazione deriva anche dal fatto che, se ci si rende conto di avere frazionato in troppi Team Projects, è decisamente difficile intervenire per riunirli in un unico Team Project, mentre se si è scelto un unico Team Project e ci si rende conto che è “troppo grande” si può frazionarlo con relativa semplicità.

Bisogna infatti tenere conto che, anche avendo un unico Team Project è possibile suddividerne i contenuti in maniera molto semplice. Supponiamo di avere un unico Team Project e di voler però gestire progetti logicamente distinti, magari commissionatici da più clienti esterni differenti.

Per quanto riguarda il source control, esso è un file system virtuale, per cui è possibile usare la classica suddivisione per cartelle per dividere più “progetti logici” all’interno di un singolo Team Project. Ogni sottocartella può poi avere permessi separati, in questo modo si può anche gestire lo scenario in cui solamente alcune persone possono accedere al sorgente di un determinato progetto. E’ possibile usare quante sottocartelle si vuole, per cui non vi sono problemi.

Per quanto riguarda i Work Item, anche in questo caso esiste il concetto di Area, che altro non è che un campo particolare, presente in tutti i Work Item, che permette di suddividerli appunto in Aree. Anche le aree sono organizzate ad “Albero” e quindi è possibile creare un area per ogni progetto logico, in modo da suddividere i Work Item tra i vari progetti. Le aree possono inoltre avere specifici parametri di sicurezza. Questo permette di decidere ad esempio che solamente alcuni utenti/gruppi possono vedere/modificare Work Item in una determinata area. Anche le query supportano il concetto di Folder, e quindi possono essere facilmente raggruppate per ogni “progetto Logico”

L’unica parte che non permette una suddivisione diretta sono le build, che vengono purtroppo mantenute tutte allo stesso livello per tutto il Team Project. Per questo è buona norma usare un prefisso nel nome che ne indichi il progetto logico di appartenenza (o usare comunque un tool di terze parti per supportare l’organizzazione in cartelle delle build all’interno di Visual Studio.

L’approccio a Team Project singolo è sicuramente il migliore quando si è una piccola ditta, con pochi membri, che sviluppa però più Progetti separati (anche per committenti differenti). In realtà in questi scenari tutti lavorano su tutto ed è quindi molto comodo avere un unico Team Project. Ricordate infatti che Visual Studio permette la connessione ad un solo Team Project per volta, per cui avere troppi Team Project piccolini vi costringerà ad un continuo cambio di Team Project in VS, operazione decisamente fastidiosa.

Nei prossimi post spiegherò invece come è possibile sfruttare il concetto di Team, introdotto con il TFS 2012, per gestire in maniera efficace combinazioni di più Team / Backlog.

Gian Maria.