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
manual
L'opzione Continuous Integration
L'opzione Rolling Builds
L'ultima opzione permette invece di impostare una build giornaliera. La Gated Check-in
Il terzo step, permette di impostare il workspace Build Agent
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
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
Build Controller
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
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.sln
|
| 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"
|
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
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),
- Team Foundation Server 2008 in Action
- Visual Studio Application Lifecycle Management centre
- Team Foundation Server documentation
