Una volta installati i Build Agent, possiamo gestire l'ambiente di build dal Team Explorer di Visual Studio effettuando un click con il tasto destro su Build/Manage Build Controller ed avere una visualizzazione dell'ambiente attuale.
In figura vediamo come appare la lista di tutti gli agent configurati per il Build Controller associato a questa Project Collection ed il loro stato. In questo esempio abbiamo fermato, infatti, la macchina virtuale chiamata TfsBasicBa per evidenziare come l'agent relativo sia stato marcato come unavaliable.
Una volta configurati gli agent possiamo creare la prima build: clicchiamo col tasto destro sull'icona delle build e scegliendo l'opzione "New Build Definition". Nella prima schermata della configurazione dobbiamo solo indicare un nome ed una descrizione. Per ogni progetto è infatti normale avere più build distinte ed è quindi utile poter associare una descrizione testuale che spieghi in dettaglio le operazioni effettuate.
Figura 39. Impostare un trigger
(clic per ingrandire)
In figura viene invece mostrata la seconda schermata di configurazione in cui si scelgono i trigger, ovvero le condizioni al verificarsi delle quali il controller esegue lo script di build. L'opzione di default è manual con la quale si lascia che sia l'utente a decidere quando eseguire la build.
L'opzione Continuous Integration invece accoda una build ad ogni check-in del codice, in questo caso bisogna avere grande cura nel calcolo della durata, altrimenti rischiamo di accodare più build di quante il sistema riesca ad eseguirne.
L'opzione Rolling Builds serve per attenuare questo problema, perché permette di lanciare una build ad ogni check-in, ma non più frequentemente di un certo intervallo. Se abbiamo una build che dura circa 15 minuti e una media di un check-in ogni 5 minuti, potremmo impostare una "Rolling Builds" con un intervallo di 30 o 40 minuti per evitare di saturare l'agent e lasciare spazio ad eventuali altre build.
L'ultima opzione permette invece di impostare una build giornaliera. La Gated Check-in ha un significato completamente differente, ad ogni Check-In il sistema effettua una build con le ultime modifiche e se la build fallisce il Check-In viene rigettato. Questa opzione va naturalmente utilizzata con cautela e naturalmente deve essere condivisa da tutti gli sviluppatori, per evitare che le persone siano frustrate dall'impossibilità di eseguire un check-in.
Il terzo step, permette di impostare il workspace da usare per la build. Come abbiamo detto, un workspace è un mapping tra i file presenti nel source control ed una cartella locale e dato che il Build Agent deve comunque recuperare i file per effettuare la build, è necessario definire un workspace valido.
Figura 40. Creazione di un workspace ad-hoc per la build
(clic per ingrandire)
La configurazione deve essere fatta con cautela, ad esempio per progetti complessi con molte solution, è consigliabile configurare il workspace in modo da scaricare solamente i file necessari alla build.
Facciamo il caso in cui il progetto sia composto da cinque solution, separate in cartelle differenti. Se creiamo una build per la solution numero uno, è logico impostare nel workspace tutte le cartelle delle altre solution come "cloacked".
Grazie a questo tipo di accortezze, il Build Agent, durante la build, recupererà solo i sorgenti necessari dal source control, diminuendo il tempo di esecuzione e le risorse occupate.
Una corretta configurazione è necessaria anche per l'integrazione continua, dato che una nuova build viene lanciata per ogni check-in su un file presente nel relativo workspace. Tornando all'esempio precedente, se non si crea un workspace corretto, per ogni check-in su qualsiasi solution, sarà lanciata la build relativa alla solution uno, anche se in realtà essa non è cambiata.
Per quanto riguarda invece la parte di Build Default, mostrata nella prossima immagine, si deve scegliere il Build Controller da utilizzare e specificare se il risultato della build deve essere copiato in un apposito share di rete chiamato drop folder.
Alcune build infatti hanno solamente lo scopo di verificare alcune metriche di codice e producono solo statistiche, altre hanno lo scopo di rendere disponibili i file compilati, ad esempio per i tester; la drop folder serve quindi come repository dove copiare il risultato della build: le dll, gli exe gli eventuali packages per gli applicativi web, etc etc..
Il tab process, è il più interessante perché contiene la reale definizione di "cosa fare".
Figura 42. Definizione del processo della build
(clic per ingrandire)
Il parametro più importante è il build process template che identifica un workflow di WorkflowFoundation 4.0 che contiene la reale sequenza di operazioni. Per semplificare la configurazione, la maggior parte delle opzioni viene esposta dal workflow sotto forma di proprietà, che possono essere impostate direttamente tramite la sezione "Build Process parameters" senza editare direttamente il workflow.
Una discussione dettagliata di tutti i parametri è al di fuori dello scopo di questa guida, per una introduzione è sufficiente familiarizzare con i fondamentali:
| Parametro | Descrizione |
|---|---|
| Items to Build | identifica le solution o i progetti da compilare e in che configurazione. In figura ad esempio si è scelto di compilare la solution Math.slnnella configurazione AnyCPU|Debug |
| Automated Test | si può automatizzare lo unit testing e richiedere di eseguire i test presenti in qualsiasi assembly il cui nome contenga la stringa "test" ed usando il file di impostazione ForBuild.testsettings |
Esaminando gli altri parametri notiamo che si può configurare la build in maniera molto dettagliata: ad esempio possiamo scegliere il formato del nome della build, che per default è una combinazione di: nome, data e numero incrementale giornaliero, si possono impostare parametri per l'esecuzione dei test, richiedere che l'agent abbia specifici tag, calcolare il code coverage, etc.
L'ultimo tab della configurazione è quello relativo alle retention policy: le regole con cui il tfs gestisce lo storico.
Come si vede in figura, per ogni tipologia di risultato (stopped, failed, partially succeeded e succeeded) possiamo scegliere quante build mantenere.
Questa opzione è fondamentale per non saturare di build obsolete il tfs e la drop folder. Nella colonna "What to Delete" possiamo indicare poi cosa cancellare effettivametne, di default è indicato "all", ma è possibile scegliere di cancellare solamente alcune parti della build, ad esempio i dati dalla drop folder, ma tenere il risultato dei test come storico.
Una volta creata la build è sufficiente un doppio click su di essa per visualizzare lo storico delle sue esecuzioni, assieme ad un rapporto dettagliato per ogni esecuzione.
Bibliografia
Gli argomenti trattati in questo capitolo possono essere approfonditi su questi testi:
- Professional Application Lifecycle Management with Visual Studio 2010 (wrox), di Mickey Gousset, Brian Keller ed altri.
- Team Foundation Server 2008 in Action (Manning) di Jamil Azher
- Visual Studio Application Lifecycle Management centre on MSDN
- Team Foundation Server documentation on MSDN
