FoxyBlog

La volta scorsa abbiamo visto come installare CruiseControl.NET e abbiamo lanciato per la prima volta il server.
Ora dobbiamo dire a CC.NET quali progetti deve monitorare e cosa deve fare quando nota delle modifiche.
Per fare tutto questo bisogna modificare un file xml che si chiama ccnet.config.

Il file di configurazione

La definizione di ogni progetti può essere suddivisa in 4 zone logiche:

• Definizione del progetto (7 - 13)
• Definizione del repository del sorgente dove controllare per vedere se ci sono modifiche (17 - 23)
• Definizione di come fare la build del progetto (27 - 31)
• Operazioni da fare dopo la build (35 - 37)

Definizione del progetto

Questa zona è abbastanza banale: definisce semplicemente il nome del progetto, le directory nulle quali CC.NET andrà a lavorare e quando deve essere scatenata la build: tipicamente si vuole che siano scatenate in seguito alle modifiche ad un repository di codice e quindi si usa il seguente tag per definire ogni quanto tempo CC.NET deve andare a verificare il repository.

E' inoltre possibile modificare alcuni comportamenti standard di CC.NET con altri blocchi di configurazione:

• State Manager: è possibile cambiare la posizione dove vengono salvati file con gli stati dei progetti
• Labeller: è possibile definire il formato della label, ovvero del numero di build (di default è un numero)

Definizione del repository del codice sorgente

CC.NET oltre a poter controllare direttamente il contenuto di una directory, supporta svariate tipologie di repository di codice sorgente (questi moduli si chiamano "Source Control Block"):

• Visual Source Safe
• CVS
• Vault
• ecc...

Inoltre si possono controllare contemporaneamente più tipologie di repository (usando il Multi Source Control Block) e impostare anche dei filtri su quello da monitorare all'interno di un repository (usando il Filtered Source Control Block).

In questo articolo guardiamo come configurare VSS, mentre vi rimando alla documentazione ufficiale per la configurazione di altri Source Control Block.

La configurazione di tutti i Source Control Block deve essere compresa nel tag <sourcecontrol> e deve avere l'attributo type che specifica quale Source Control Block stiamo andando a configurare (vss nel caso di Visual SourceSafe).

Entrando nello specifico di VSS abbiamo questi parametri di configurazione:

• autoGetSource: specifica se, oltre a verificare la presenza di modifiche, CC.NET deve anche scaricarle nella sua working directory (e non è detto che vogliate che lo faccia, ad esempio, se volete gestire lo scaricamente all'interno del processo di build)
• applyLabel: specifica se, una volta terminato con successo il processo di build, CC.NET deve applicare la label col numero progressivo di build a tutti i file presenti nel repository
• project: il nome del progetto dentro a VSS
• username e password: le credenziali con le quali CC.NET deve collegarsi a VSS (per applicare le label l'utente deve avere permesso di scrittura)
• ssdir: la directory contenente il file SRCSAFE.INI che definisce il DB di repository di source safe da usare
• workingDirectory: la directory locale di lavoro (deve essere uguale a quella definita nella parte sulla definizione del progetto... per qualche strano motivo non viene letta di default

Definizione del processo build

CC.NET supporta 3 tipologie di build:

• Visual Studio.NET
• NAnt
• generico builder da linea di comando

A prima vista, sembrerebbe che il builder VS.NET sia il migliore (o più facile) da usare. Invece non è così:

• necessita di VS.NET installato sul server di build, e cioè è raramente possibile
• inoltre per i progetti web necessita anche di webDav configuato e installato perchè, come tutti noi sappiamo, VS.NET carica i progetti web dal loro URL (tipicalmente http://localhost/nomeProgetto/nomeProgetto.csproj) mentre probabilmente, sul build server non avremo voglia di metterci a configurare anche tutti questi mapping di virtual directory
• infine non è detto che vogliamo fare la build di tutti i progetti presenti nella solution (ad esempio potremmo voler tenere alcuni progetti solo come references)

I due meccanismi di build consigliati sono NAnt e il nuovo motore di build che sarà presente in VS.NET 2005 (MSBuild) che però per ora non ha un suo builder block: opteremo quindi per NAnt.

La configurazione del Builder Block deve essere all'interno del tag <build> e specificare type="nant".

Tutti i parametri di configurazione sono opzionali, ma, anche per chiarezza, è meglio specificarli:

• executable: il percorso del programma nant.exe
• buildFile: il nome del file di build relativo alla workingDirectory specificata prima
• buildArgs: eventuali parametri da passare a nant (ad esempio dei parametri di build, come, nel nostro caso, la directory dove salvare la build)

Integrazione tra NAnt e CC.NET

Grazie ad un Bulder Block specifico, CC.NET passa a NAnt le seguenti proprietà:

• ccnet.label: il numero di build col quale verrà identificata la build
• ccnet.buildcondition: il motivo per il quale è stata lanciata la build (può essere ForceBuild o IfModificationExists)

Inoltre l'output generato da NAnt viene automaticamente integrato con il build log di CC.NET, senza bisogno di dover fare un merge manuale.

Operazioni da fare dopo la build

Una volta terminata la fase di build CC.NET può gestire due tipologie di attivatà:

• Task
• Publisher

I Task sono considerati ancora parte integrante del processo di build, e se uno di questi fallisce, fa fallire l'intera build. Integrati con CC.NET esistono due task già pronti, ma se ne possono sviluppare di nuovi in base alle proprie esigenze:

• NUnit: lancia il processo di Unit Testing sul codice appena compilato
• File Merge: serve per integrare nel build log l'output di eventuali tool esterni usati durante il processo di build

I Publisher invece sono delle attività eseguite alla fine di tutto, per notificare l'esito della build.
I due più comunemente usati sono:

• xmllogger: pubblica il build log in formato xml nella cartella artifactDirectory specificata nella definizione del progetto
• email: invia delle mail ad un'elenco di destinatari. E' possibile raggrupparli in gruppi di notifica, e inviare ad alcuni la mail ad ogni build, e ad altri solo in caso di cambio di stato della build (da success a failed o viceversa)

Conclusione

Nella prossima "puntata" daremo un'occhiata a NAnt, per poi guardare un semplice progetto di integration, cioè che gestisce due progetti diversi che interagiscono tra di loro.
Ma tutto questo dopo la NZ