Il termine integrazione continua identifica una serie di operazioni automatiche, utili per la compilazione del progetto e la raccolta di metriche.
Il primo obiettivo è quello di verificare che il codice, anche subendo modifiche da diversi sviluppatori, sia sempre in uno stato compilabile ed utilizzabile da tutto il team. Per questo si effettuano frequenti test di integrazione, che vanno dalla semplice compilazione del progetto fino all'esecuzione dei test, dal calcolo di alcune metriche (code coverage, code analysis) allo svolgere ogni operazione che possa fornire dati interessanti sul progetto.
Team Foundation Server fornisce una piattaforma di integrazione continua chiamata Tfs Build, che costituisce il terzo pilastro della versione Basic.
Sebbene convenzionalmente si parli di Tfs Build, le operazioni svolte da questo servizio non si limitano quindi alla sola compilazione, ma una Build Automatica prevede anche l'esecuzione dei test, il calcolo di metriche e di ottenere informazioni tali da avere una visibilità "continua" sullo stato di salute di un progetto.
La Team Build è costituita da due componenti:
- il Build Controller, che si occupa di orchestrare l'esecuzione degli script di build
- i Build Agent che sono i componenti che eseguono fisicamente la build stessa.
Lo scenario più semplice è quello in cui si installano il controller ed uno o più agent sulla stessa macchina in cui abbiamo installato TFS basic. Questa configurazione è però sconsigliata, perché l'operazione di build è onerosa in termini di risorse: con un build server sulla stessa macchina del TFS rischiamo di peggiorarne le prestazioni.
La scalabilità di TFS e la sua natura di "Software + Services", permette però di installare il controller e gli agent su macchine separate, in modo da suddividere il carico e garantire la massima scalabilità.
L'installazione della prima macchina è banale: basta inserire il DVD di TFS, scegliere di installare il build service e configurare il tutto indicando l'utente usato per eseguire il servizio e la Project Collection da usare. Un controller può infatti operare su una sola Project Collection, quindi se abbiamo più collection, è necessario avere, per ciascuna, almeno una macchina di build.
Quanto all'utente da usare per il servizio, la soluzione più semplice è creare un utente chiamato BuildAgent, con diritto "run as service" e sufficienti privilegi in TFS per eseguire una build. Dato che il concetto di Build Agent è nativo in TFS esiste un gruppo apposito chiamato Project Collection Build Service Account da usare per tutti gli utenti dei build agent.
Una volta configurata la prima macchina, possiamo verificare che il servizio sia operativo nella console di amministrazione.
Figura 33. Build Controller configurato ed operativo con un singolo agent
(clic per ingrandire)
Se la macchina di build non ha risorse sufficienti ad eseguire tutte le build configurate è possibile affiancare altri agent in modo semplice. Basterà installare un altro Build Service su una seconda macchina, durante la configurazione e dopo che si è scelta la Project Collection, la procedura rileva che è già presente un controller e mostra quindi la configurazione attuale.
Figura 34. Configurazione di Build Agent aggiuntivi per una Project Collection
(clic per ingrandire)
Proseguendo nella configurazione, il wizard chiede se si vuole effettuare uno scale out del build services, rimpiazzare un controller oppure configurare in seguito la struttura.
Figura 35. Gestire la scalabilità dei build service
(clic per ingrandire)
La prima opzione serve per aggiungere ulteriori Build Agent ad un controller esistente; l'opzione di rimpiazzo è utile se un vecchio controller non è più operativo o deve essere sostituito e infine la possibilità di configurare l'agent successivamente è necessaria se si vuole configurare l'agent per Lab Management, oppure se si vuole solo installare l'infrastruttura di build per lasciare che qualcun altro si occupi della sua configurazione.
Se scegliamo di effettuare uno scale out, è sufficiente specificare l'account da usare come Build Agent, dato che tutte le opzioni salienti sono appannaggio del Build Controller e non devono essere nuovamente specificate.
Figura 36. Configurare il Build Service
(clic per ingrandire)
In questo modo possiamo installare Build Agent su diverse macchine della rete, suddividere il carico di lavoro e poter eseguire quindi più script di integrazione.
Se tutti gli agent sono equivalenti tra di loro è possibile lasciar decidere al controller in maniera autonoma quello da utilizzare, se invece esistono delle differenze è utile configurarli utilizzando il concetto di Tag. Se si visualizzano le proprietà di un Build Agent è infatti visibile a destra la lista dei tag associati. Nella figura seguente notiamo ad esempio i tag VSUltimate e Windows2008.
Un Tag è una semplice stringa, possiamo aggiungerne di nuovi premendo "add new Tag" ed inserire un testo qualsiasi, Tfs tiene traccia di tutti i tag associati agli agent e li presenta nella configurazione, per facilitare le operazioni ed evitare errori di digitazione.
In figura è infatti possibile notare la presenza del tag Windows7 nello stato non selezionato, questo perché almeno un altro agent possiede questo tag e il sistema lo presenta tra le opzioni possibili.
L'uso dei tag è utile quando è necessario scegliere in che agent effettuare la build, ad esempio per il calcolo del code coverage, ma nella macchina dell'agent deve essere installato Visual Studio in versione Premium o Ultimate. Può accadere che non tutti i Build Agent soddifino questi requisiti, in questo caso impostiamo l'esecuzione di quella particolare build solo sulle macchine che hanno il tag VSUltimate, che abbiamo associato a tutti gli agent che hanno Visual Studio Ultimate installato.
