Il source control system

Quando finalmente la pianificazione raggiunge un livello sufficiente, si inizia la scrittura del codice e, lavorando in team, è assolutamente necessario utilizzare un Source Control System (SCS) per poter lavorare contemporaneamente sugli stessi progetti. TFS fornisce un SCS centralizzato basato su Sql Server, in questo modo effettuando il backup dei database di Sql Server relativi a TFS si effettua automaticamente anche il backup di tutto il codice del progetto.

I file risiedono nel server, quindi è necessario lavorare su una copia locale e stabilire una "mappatura" tra i file sulla nostra macchina e quelli nel server; questa mappatura in Tfs prende il nome di Workspace.

Nel Workspace, quindi, sono stabilite le correlazioni tra i file sul server e la loro mappatura su un particolare pc, un particolare utente e per una specifica cartella. Per ogni tripletta: utente, pc, cartella, possiamo avere un mapping differente. Può sembrare complicato, ma si tratta semplicemente di fornire a TFS, per ogni file memorizzato in una data cartella di un certo PC, l'utente associato ed il relativo file sul server.

Per creare e gestire i workspace, si parte dal Team Explorer. Se visualizziamo il sorgente con la sezione Source Control, notiamo che, la prima volta, il percorso locale viene indicato come not mapped, è sufficiente cliccarvi sopra per scegliere il percorso dove mappare tutto il workspace

Una volta creato un workspace è possibile iniziare ad eseguire le operazioni più comuni sui file come:

Operazione	Descrizione
Get Latest	Recupera dal server la versione più recente di un file o di un'intera cartella
Check Out	Indica al server che si sta iniziando a modificare il file, con questa operazione è anche possibile imporre lock ed evitare quindi che altri sviluppatori possano modificare il file
Check In	Invia le modifiche al server, che aggiornerà la versione più recente con quella inviata
Revert	Annulla eventuali modifiche locali al file, ripristinando l'ultima versione del server
History	Controlla la storia del file, mostrando chi ha modificato il file e quando, con la possibilità di confrontare due diverse versioni di un file
Annotate	Permette di indicare, per ogni riga su un file, chi la ha scritta e quando

Per chi è abituato a Source Safe, l'operazione di Check Out non è di default esclusiva, questo significa che più sviluppatori possono effettuare il check out contemporaneo di uno stesso file. In questo caso i conflitti vengono risolti al momento del check in. Questo assicura la massima produttività e minimizza i tempi morti che derivano dall'uso esclusivo dei file, anche se richiede una attenzione maggiore, per non generare troppi conflitti.

Dunque il check out non è bloccante,ma l'operazione viene comunque comunicata al server: ciò permette a tutto il team di sapere se un file è in modifica e ci permette di evitare i conflitti. Se Marco deve modificare un file e vede che è già in Check Out da parte di Luca, può ad esempio lavorare su un'altra sezione del progetto attendendo che Luca finisca di lavorare su quello specifico file, oppure modificarlo comunque, sapendo che forse sarà necessario successivamente effettuare un merge. L'operazione di check-out viene fatta automaticamente da Visual Studio appena si modifica un file, oppure può comunque essere richiesta dal solution explorer tramite il menu contestuale.

Il primo workspace creato mappa l'intero percorso del server in una cartella locale, in questo modo tutto il contenuto viene scaricato e sincronizzato. Questo naturalmente non è sempre necessario, se ad esempio per un Team Project si sono create tre solution differenti relative ad esempio a:

• data and business layer
• interfaccia Web
• interfaccia WPF

Un programmatore che lavora solamente con la prima può migliorare le prestazioni semplicemente effettuando un "cloacking" delle cartelle relative alle altre soluzioni, in modo da evitarne la sincronizzazione. Ogni cartella impostata come "Cloacked" viene infatti esclusa dal processo di sincronizzazione, diminuendo il numero di file e velocizzando le operazioni di Get Latest e Check In.

Per impostare queste opzioni si parte sempre dalla visualizzazione del source control, sopra l'indicazione della cartella locale appare una combo che lista tutti i workspace presenti ed ha anche un'opzione chiamata "workspaces" che permette di editare un qualsiasi workspace.

In questo caso, come si vede in figura, è stato deciso di non scaricare il percorso del source control chiamato FrontEnd. Sempre nella stessa finestra si possono vedere tutte le proprietà del workspace: il nome del pc, del server tfs, l'utente attualmente utilizzato ed i permessi. Per i permessi abbiamo tre valori disponibili: privato, pubblico, o pubblico limitato ed è particolarmente importante se si utilizzano postazioni condivise. Un workspace privato può essere infatti usato solamente dal suo proprietario, il pubblico limitato può essere usato da tutti, ma solo il proprietario può fare check-in ed amministrarne le proprietà, infine il workspace pubblico può essere usato da qualsiasi utente ed è particolarmente adatto ad essere usato in computer condivisi.

Installando i Tfs Power Tools (strumenti aggiuntivi forniti da Microsoft in un unico addin gratuito) è anche presente un'integrazione con windows explorer, che permette di gestire i sorgenti direttamente facendo click con il tasto destro su di una cartella che fa parte di un workspace, questo tool è particolarmente utile per i grafici o per chi in generale non gestisce file di progetto, ma ha comunque la necessità di poter operare con i sorgenti di un progetto in maniera semplice e veloce.

Check-in ed Integrazione con i Work Item

L'operazione più comune effettuata con un source control system è il Check-In, tramite la quale le modifiche locali vengono inviate al server. In Visual Studio esistono molti modi per iniziare una operazione di check-in, il più semplice consiste nel cliccare con il tasto destro sulla solution, sul progetto, sulla cartella o sul file di cui si vuole fare check-in e scegliere il comando Check-In.

La finestra che appare è mostrata in figura ed è suddivisa in più tab, selezionabili dai bottoni a sinistra. Di default la finestra si apre sul tab "source Files" in cui sono mostrati i file che sono stati modificati nel workspace locale ed è presente una texbox per inserire un commento. Se l'operazione di check-in è effettuata su un certo progetto o da una cartella specifica, vengono elencati solo i file di quel progetto o cartella, possiamo quindi decidere semplicemente cosa condividere sul server.

Tutti i file modificati hanno vicino una checkbok, per cui possiamo selezionare una qualsiasi combinazione. Per conoscere le modifiche effettuate rispetto alla versione nel workspace, clicchiamo con il tasto destro su un file e scegliamo di effettuare un compare con la versione del workspace (quella di partenza) o con la Latest, ovvero quella presente nel server.

Premendo SHIFT+Invio con un file selezionato, facciamo automaticamente il confronto con la versione del workspace come mostrato nella prossima figura in cui si vede come dalla versione iniziale si sia aggiunto un commento al metodo divide.

Il vantaggio di utilizzare un unico strumento come Tfs, per la gestione di tutto il ciclo di vita, è dato dalla grande interazione presente tra i vari componenti. Il secondo tab della finestra di check-in, chiamato work item, permette infatti di scegliere uno o più Work Item da collegare all'operazione di check-in.

Nella prossima figura vediamo infatti come il check-in sia associato al WI 10. La relazione è di due tipi:

• associate effettua l'associazione tra il check-in ed il Work Item
• resolve oltre ad effettuare l'associazione mette il Work Item nello stato Resolved

In questo modo è possibile, per ogni check-in, capire le ragioni che hanno portato alla scrittura di quella porzione di codice e visualizzare quali requisiti sono stati implementati o quale bug è stato chiuso. Questa possibilità è fondamentale per ottenere la tracciabilità dei requisiti, fondamentale per la riuscita di progetti con team di grandi dimensioni.

Nella finestra di check-in troviamo anche le tab: Check-in Notes, che permette di aggiungere note specifiche di check-in e la Policy Warning, che visualizza la violazione di eventuali regole impostate. Di base non è presente nessuna regola, ma è possibile aggiungerne per verificare che il check-in soddisfi particolari requisiti; tra le regole disponibili vi sono ad esempio: commento obbligatorio, obbligatorietà di associare uno o più Work Item, esecuzione delle metriche di codice, e molte altre.

Anche se le regole di check-in possono rendere la vita difficile agli sviluppatori, garantiscono che ogni check-in soddisfi un livello di qualità minimo. Se si lavora in grandi progetti, quando si hanno migliaia di check-in, tutti senza commenti e completamente scorrelati dalle specifiche, si può apprezzare la possibilità di forzare lo sviluppatore ad introdurre queste infromazioni.

Vi sono moltissime altre funzionalità del source control di Team Foundation Server, possiamo esaminarle tutte su MSDN.