La prima parte del file di configurazione racchiude le proprietà base del progetto:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<project name="MyLibrary">
<webURL>http://10.0.0.201/ccnet/server/local/project/MyLibrary/ViewProjectReport.aspx</webURL>
<workingDirectory>C:CCProjectsMyLibrarymain</workingDirectory>
<artifactDirectory>C:CCProjectsMyLibraryArtifacts</artifactDirectory>
<modificationDelaySeconds>30</modificationDelaySeconds>
<category>Samples</category>
<triggers>
<intervalTrigger name="continuous" seconds="30"/>
</triggers>
<!-- ... -->
Ogni progetto è racchiuso in un elemento <project> e tramite l'attributo name ne viene specificato il nome da visualizzare nei report. Esaminiamo le proprietà principali di questo elemento.
| Proprietà di <project> | Descrizione |
|---|---|
webUrl |
indica l'URL della webDashboard da cui visualizzare i report |
workingDirectory |
la cartella del disco in cui verrà gestita l'integrazione del progetto |
artifactDirectory |
la cartella in cui archiviare tutti gli artefatti generati |
modificationDelaySeconds |
indica il tempo che deve trascorrere tra la modifica e l'inizio delle operazioni di integrazione |
La proprietà modificationDelaySeconds può essere impostata anche congiuntamente al nodo <trigger>, che indica invece l'intervallo con cui controllare il repository di codice per verificare se è presente una nuova versione. Ad esempio un trigger di 20 secondi con modificationDelaySeconds a 120 indica di controllare ogni 20 secondi se qualcuno ha effettuato un checkin, se il repository è modificato si aspettano 120 secondi, al termine dei quali si controlla ancora. Se nessuno ha fatto ulteriori checkin nei 120 secondi si lancia la build, altrimenti si aspettano ancora 120 secondi.
Queste impostazioni servono a limitare il numero di build per e il relativo sovraccarico del server dovuto alle troppe integrazioni in un piccolo intervallo di tempo.
Source control e compilazione
Nel nodo <sourcecontrol> vengono invece impostate tutte le proprietà relative al Source Control Management System, che in questo esempio è SubVersion.
<sourcecontrol type="svn"> <workingDirectory>BuildToolssvn</workingDirectory> <trunkUrl>svn://10.0.0.201/htmlitsample/Lezione3</trunkUrl> <username>alkampfer</username> <password>$uper$ecure</password> <autoGetSource>true</autoGetSource> </sourcecontrol>
La working directory permette di specificare la cartella che contiene l'eseguibile di SubVersion (svn.exe); come si può notare, nell'esempio è stato impostato un percorso relativo, perché la distribuzione di SubVersion è inserita assieme ai sorgenti.
Questa particolarità è assolutamente fondamentale per una corretta integrazione continua, è bene che tutti i tool necessari per l'integrazione siano contenuti nel repository del progetto, in modo da semplificare la configurazione delle macchine di build.
La trunkUrl contiene invece l'indirizzo del repository dove risiede il progetto da integrare, seguito dalle credenziali con cui accedere e da un parametro (autoGetSource) che indica se scaricare o meno in maniera automatica l'ultima versione prima di una integrazione. L'ultima parte permette semplicemente di specificare la tipologia di labeller da usare e come lanciare lo script nant.
<labeller type="defaultlabeller">
<prefix></prefix>
<incrementOnFailure>false</incrementOnFailure>
</labeller>
<tasks>
<nant>
<executable>BuildToolsnant-0.85nant.exe</executable>
<buildFile>trunksrcSample1MyLibraryDefault.build</buildFile>
<targetList>
<target>build</target>
</targetList>
</nant>
</tasks>
Il <labeller> serve per creare le etichette univoche per le build e non fa altro che generare un numero intero autoincrementato, che viene poi passato allo script nant. Al termine si trova il nodo <tasks>, in cui si specifica come eseguire l'integrazione, in questo esempio basta eseguire uno script nant. Anche in questo caso si può notare come l'eseguibile nant.exe sia stato incluso nel controllo di codice sorgente in modo da avere tutti i tool necessari per la compilazione semplicemente facendo un checkout del repository.
