Una delle più interessanti novità del TFS 2013 è il supporto a Git, già introdotto in TF Service a gennaio e disponibile ora anche per la versione on-premise. Tutto quello che si deve fare è semplicemente scegliere Git come Version Control System durante la creazione del vostro nuovo Team Project ed il gioco è fatto, avete un Team Project basato su Git.

Il supporto non è solamente lato Server, anche Visual Studio 2013 è in grado di lavorare nativamente con un repository Git. Una volta connessi ad un Team Project basato su Git è infatti possibile effettuare subito un clone del repository per iniziare a lavorare. Nota: Il supporto a Git da parte di Visual Studio non è solamente per i progetti di Git hostati da Team Foundation Server, ma può essere usato per lavorare con qualsiasi progetto Git, anche se hostato in GitHub ad esempio.

Una volta scelta la cartella locale dove effettuare il clone, è sufficiente procedere alla creazione di una solution al suo interno, ed il source control è automaticamente attivato. Gli aspetti importanti da tenere in considerazione sono due, il primo è selezionare “add to source control” per informare Visual Studio che si vuole inserire la solution sotto controllo di codice sorgente, il secondo è creare la solution in una sottocartella del percorso che avete precedentemente clonato.

A questo punto si può iniziare a sviluppare utilizzando l’integrazione tra Visual Studio e Git. Per ulteriori approfondimenti sul supporto a Git all’interno di Visual Studio è possibile consultare i miei articoli su MSDN Italia [Differenze tra Source Control Centralizzato e Distribuito].

In VS2013 l’integrazione con Git si avvia verso la completa parità con il Source Control standard di TFS, ad esempio è possibile associare Work Items direttamente nella ui, senza essere costretti ad usare la convenzione di indicare #workitemid nel commento del changeset.

In questo caso il commit viene associato con il Task 2 ed una volta che si è effettuato il Push verso il server, sarà possibile visualizzare tutti i Work Item associati direttamente dall’interfaccia Web.

Se lo si preferisce è comunque ancora possibile utilizzare la convenzione di inserire il Work Item Id preceduto da un HashTag, ad esempio se si effettua il push di un commit che contiene #3 nel commento si richiede di associarlo al Work Item con Id 3.

D’altra parte in realtà il Team Explorer fa proprio questo; anche se voi selezionate il Work Item tramite una query o con Drag And Drop di base il Team Explorer non fa altro che aggiungere al vostro commento una serie di righe per connettere i Work Items nella forma

Related Work Items: #wid

Naturalmente anche nel fronte della build Git è supportato al pari del source control Standard di TFS, in questo caso è possibile ad esempio specificare di effettuare la build su più di una branch.

In questo caso si è specificato che per le build schedulate o manuali la branch di default che verrà compilata è la master, però per la continuous integration si è scelto di monitorare non solamente la master ma anche la branch Dev. In questo modo qualsiasi push che riguarda la branch master o dev, se la build è in integrazione continua, scatenerà una build.

Nella build di TFS 2013 è stato anche aggiunta l’opzione di copiare il risultato della build direttamente nel server non usando uno share di rete, in maniera analoga a quanto avviene con il TF Service (che usa un Azure Blob Storage per salvare la drop folder)

Per quanto riguarda il processo, è ora possibile avere accesso alla definizione della Build per git ed in generale sono presenti tutte le opzioni principali che avete con il Source Control Standard di TFS. Dovete specificare il percorso di uno o più progetti che verranno compilati (avete una dialog che vi permette di scegliere semplicemente i file dal vostro percorso senza obbligarvi a digitare il percorso manualmente), di base verranno eseguiti tutti i test dei progetti il cui nome contiene Test e come si può vedere è possibile anche specificare un percorso per la pubblicazione dei simboli.

In generale il workflow delle Build è stato semplificato e contiene le stesse opzioni sia per i progetti basati su TFSVCS sia su quelli basati su Git, con le dovute differenze del caso, ad esempio la possibilità per le build basate su Git di monitorare più di una branch.

Le funzionalità che ancora non sono presenti per Team Project basati su git sono: le Code Review ed il My Work (compresa la sospensione del lavoro), che sono invece presenti ancora solamente per progetti basati sul source control standard di Team Foundation Server.

Gian Maria.