Nel precedente articolo abbiamo visto come installare un Build Server on premise su una Project Collection che risiede invece su TFS on Azure, in questo articolo vedremo come creare una semplice build in TFS11 che effettui on premise la build di un progetto che risiede su TFS on Azure.
Nel Team Explorer è presente la sezione build, che una volta aperta presenta subito in alto un link per creare una nuova build (New Build Definition).
Già nella prima schermata possiamo notare delle aggiunte rispetto alla versione precedente, oltre al nome ed ad una descrizione sono infatti presenti tre opzioni per gestire la coda della build.
La prima opzione è il default ed è il comportamento solito, la seconda opzione invece permette di tenere la coda di build in pausa, questo significa che se qualcuno richiede una build, oppure una build viene automaticamente richiesta dal sistema dopo un check-in, la build verrà accodata, ma non eseguita a meno che un amministratore non forzi lo start. La terza opzione permette di disabilitare la coda di build, impedendo quindi che nuove build possano essere accodate. Questa opzione è utile perchè permette di disabilitare o sospendere temporaneamente una build, magari per alleggerire il carico al build server in momenti in cui altre build hanno la precedenza.
Per quanto riguarda i Trigger nulla è cambiato dalla versione precedente.
In questo caso possiamo decidere che la build verrà lanciata solo manualmente, oppure ad ogni check-in, ogni check-in ma non più di una ogni tot minuti, schedulata ed infine Gated Check-in. Successivamente possiamo definire il Workspace allo stesso modo della versione precedente. Notate che il Workspace può anche essere preso da un workspace già creato precedentemente.
Arrivati alla schermata dei Build Defaults abbiamo una piacevole sorpresa
Il risultato della build può essere inviato ad uno share di rete, come per le versioni precedenti, ma può anche essere direttamente inviato al source control. Questa opzione è sicuramente da ponderare con attenzione, perchè in questo caso andiamo ad inserire contenuto nei database di TSF, ma può essere una validissima alternativa per alcune build importanti, specialmente per quanto riguarda la possibilità di avere sempre disponibili i file pdb con i simboli.
Infine abbiamo il tab process che è quello che contiene la definizione vera e propria della build.
Le opzioni sono molto simili a quelle della versione precedente, l’opzione più importante è la solution che deve essere “buildata”, ma abbiamo un aggiunta interessante. Potete infatti vedere che specificando di eseguire i test (in questo caso si richiede di cercare test in qualsiasi dll che contiene la parola test nel nome), avete la possibilità di scegliere se eseguire i test in x86 o in x64, possibilità che non era presente in precedenza, dato che MsTest girava solamente a 32 bit.
Una volta terminata la configurazione del processo si può scegliere la politica di Retention, ovvero per quanto tempo tenere le varie build
In questo caso ho la possibilità di decidere separatamente in base al risultato della build (magari non voglio tenere dati per le build stoppate) e per la tipologia di build (pubblica / privata).
A questo punto la build è stata creata ed è visibile nel team explorer, potete fare tasto destro ed accodarne una nuova, in modo da verificare che tutto sia ok.
Il nome della build è di default un numero incrementale, in questo caso il team explorer ci fa subito vedere la lista delle build lanciate da me che sono in coda di esecuzione, se vogliamo possiamo poi aprire il dettaglio della coda di build per vederle tutte, ma se siete interessati solamente alle vostre le avete direttamente visibili nel Team Explorer. Quando la build è completata potete effettuare doppio click ed aprire il dettaglio di esecuzione.
Nella figura precedente potete anche osservare una interessante funzionalità di VS11, quando aprite la build, essa non si apre realmente assieme agli altri tab, ma il suo tab appare tutto a destra, (è quello evidenziato in blu). Questo tab serve da “anteprima”, in questo modo potete aprire più risultati di build, che verranno tutti rappresentati nello stesso tab di "anteprima” ed evitando quindi di avere decine di build result aperti nel document well principale.
Come potete vedere, creare una build machine per i vostri progetti su TFS on Azure è questione di pochi minuti e pochi click.
Gian Maria.
