Nei post scorsi abbiamo visto come è possibile settare
CC.NET per effettuare la compilazione del nostro progetto ad ogni nuovo
check-in, in questo post verrà mostrato come generare automaticamente un
numero di build progressivo in modo da avere una numerazione coerente per tutte
le build che vengono effettuate. Il primo passo è agire nel file ccnet.config ed
aggiungere una sezione per il labeller
<labeller type="defaultlabeller">
<prefix>1.0.0.</prefix>
<incrementOnFailure>false</incrementOnFailure>
</labeller>
Naturalmente questo non è sufficiente, il labeller infatti genera un nuovo
numero di versione ad ogni build riuscita ed imposta questo nuovo numero in una
variabile per il Nant, ma non aggiorna i file di progetto, operazione che è
delegata al NANT. Il passo successivo è quindi aggiungere questa sezione nel
file di build.
<target name="Version" depends="GetPublishingProperties">
<asminfo output="TestProject1\AssemblyInfoVersion.cs" language="CSharp">
<imports>
<import namespace="System" />
<import namespace="System.Reflection" />
</imports>
<attributes>
<attribute type="AssemblyVersionAttribute" value="${CCNetLabel}" />
<attribute type="AssemblyFileVersionAttribute" value="${CCNetLabel}" />
</attributes>
</asminfo>
</target>
Per svolgere le operazioni di versioning si è creato un nuovo target chiamato
Version che dipende dal target GetPublishingProperties che vedremo tra poco. Il
target Version ha un solo task di tipo <asminfo> il cui scopo è generare
un file di configurazione per il progetto in uno dei linguaggi supportati, nel
nostro caso C#. Dato che questo task non è in grado di modificare
l’assemblyinfo.cs ma può solamente generare un file ex novo ho adottato la
seguente tecnica. In primo luogo ho tolto dal file AssemblyInfo.cs i numeri di
versione dell’assembly (questo comporta che la scheda proprietà del visual
studio non mostra più i numeri di versione del progetto, ma non è un problema
per me), la versione dell’assembly viene quindi definita in un nuovo file
AssemblyInfoVersion.cs che ho aggiunto al progetto il quale contiene i soli due
attributi AssemblyVersion e AssemblyFileVersion e può quindi essere rigenerato
ogni volta sovrascrivendo il vecchio file. Questo file non è sotto il controllo
del codice sorgente in modo che CC.NET possa gestire la sua numerazione in
maniera indipendente, se lo si desidera si può anche fare un check in automatico
ma bisogna ricordare di escludere il controllo di questo file nel repository
altrimenti si entra in un ciclo senza fine.
A questo punto per completezza è
necessario vedere il target GetPublishingProperties il cui scopo è solamente
settare alcune variabili di ambiente necessarie per la pubblicazione degli
artefatti.
<target name="GetPublishingProperties">
<if test="${not property::exists('CCNetArtifactDirectory')}">
<property name="CCNetArtifactDirectory" value="F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\Artifacts"/>
</if>
<if test="${not property::exists('CCNetWorkingDirectory')}">
<property name="CCNetWorkingDirectory" value="F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder"/>
</if>
<if test="${not property::exists('CCNetLabel')}">
<property name="CCNetLabel" value="1.2.3.4"/>
</if>
<property name="artifactsdir" value="${CCNetArtifactDirectory}\buildlogs\${CCNetLabel}"/>
<property name="publishLatest" value="${CCNetArtifactDirectory}\builds\latest" />
</target>
Come si può notare il task if di Nant permette di settare dei valori alle
variabili di ambiente CCNetWorkingDirectory, CCNetArtifactDirectory nel caso il
file di build venga invocato direttamente al di fuori di CC.NET. Personalmente
infatti quando modifico il file di build lo testo sempre direttamente con il
nant per semplicità e quindi le variabili di ambiente che sono settate dal
CC.NET sono vuote e debbono essere impostate a mano. La variabile più importante
in questo caso si chiama CCNetLabel e contiene il nuovo numero di versione
generato dal CC.NET. Il resto del task serve solamente a impostare alcune
directory che saranno necessarie nei prossimi tutorial per archiviare e
pubblicare le build una volta generate.
Il risultato attuale è che ora ad
ogni build viene assegnato un numero incrementale che permette di tenere traccia
in maniera automatica delle varie build del progetto.
Alk.
powered by IMHO 1.3