CruiseControl.NET

I suoni per il CC.Tray

Gian Maria Ricci — Fri, 08 Aug 2008 13:51:00 GMT

Il Cruise Control .NEt è veramente uno strumento che quando hai messo su la prima volta non ne puoi più fare a meno. Una delle cose che preferisco è che quando uno sviluppatore rompe la build, (ad esempio si scorda di aggiungere con tortoise i nuovi file) subito il cc.tray diventa rosso e segnala il problema. Sono quindi lontani i giorni in cui la mattina fai un update e ti trovi che la soluzione non compila, mancano file o ci sono errori e lo sviluppatore che fatto l'ultimo checkin è andato in ferie proprio quel giorno :D :D La cosa più carina è però la possibilità di suonare un file audio se la build si rompe, dopo una piccola ricerca ho trovato in un sito questo bellissimo suono di piatti rotti :D. Spesso quando sono in skype la gente mi dice "hey...ti si è rotto un piatto a casa?" Naturalmente quando invece la build compila ancora è necessario sentire un bell'applauso :D. alk.

Come mi piace la gestione di siti web del vs 2005

Gian Maria Ricci — Tue, 03 Apr 2007 12:34:00 GMT

E stamane sono 3 blog.....è strano da parte mia, ma stamane è cominiciata storta e quando comincia storta nulla va più per il verso giusto. Mi accorgo che il progetto CC.NET non compila più correttamente, vado a vedere gli errori e vedo strani errori che da me in locale non va. Vado in terminal server nella macchina e mi accorgo che il problema è il subversion, il progetto è un sito web abbastanza grande e per problemi di performance solitamente testiamo i controlli utente in progetti più piccoli suddividendo in sezioni il progetto principale. Il problema è che le reference dei progetti web sono tenuti nella cartella bin e ankh o subversion tendono a metterli nel repository. La situazione attuale è che una dll viene aggiunta nel repository, quando il server fa update trova che la stessa dll è già nella cartella causa compilazione precedente, quindi stoppa l'update dicendo che non può prosegure. La soluzione è stata aggiungere nello script nant una action che cancella tutte le directory bin dei progetti web prima dell'update, in questo modo l'update non fallisce...vediamo oggi cosa altro può andare storto. Alk.

Cruise Control .NET - Eseguire test Nunit

Gian Maria Ricci — Thu, 18 Jan 2007 19:46:00 GMT

In questa sesta parte si esaminerà come eseguire i test NUnit dopo la build del progetto.

CruiseControl.NET - Riepilogo

Gian Maria Ricci — Thu, 11 Jan 2007 10:43:00 GMT

La prossima uscita (spero oggi o cmq al massimo Sabato mattina) riguarderà NANT, e se ce la faccio anche NCOVER. Ho pensato che potrebbe essere interessant dare una riletta alla prima parte (i primi 5 post) rimetterli più in bella forma e poi pubblicarli su DotNetMarche. Mi piaceva per questo sapere quanti sarebbero interessati, perchè se alla fine a nessuno importa perchè i post sul blog sono sufficienti risparmio lavoro Ciao a tutti. Alk.

CruiseControl.NET - Metriche di codice (FxCop)

Gian Maria Ricci — Wed, 10 Jan 2007 10:19:00 GMT

In questo sesto intervento si inizia a capire la vera utilità di CC.NET inserendo FxCop come primo tool di metrica nella build automatica.

Esempi per Cruise Control .NET

Gian Maria Ricci — Fri, 05 Jan 2007 19:24:00 GMT

Per rendere più concreti gli esempi che faccio per CC.NET potete trovare a questo indirizzo le ultime versioni degli script http://dotnetmarche.googlecode.com/svn/trunk/Alkampfer/CCNetBlogCode Questo è l'indirzzo del subversion di google relativo a dotnetmarche per cui è conveniente farne il checkout in locale con il Tortoise. Se qualcuno non volesse istallare il subversion fatemelo sapere, magari creo una versione zippata da scaricare direttamente dal sito. Alk. powered by IMHO 1.3

Cruise Control .NET - Copiare le build nella cartella degli artefatti

Gian Maria Ricci — Wed, 03 Jan 2007 18:59:00 GMT

In questo post si conclude la prima parte sul piccolo tutorial relativo al CruiseControl.NET mostrando come copiare le ultime build nella cartella degli artefatti mantenendo nel contempo tutto lo storico delle varie build.

Impostare il numero di versione del progetto

Gian Maria Ricci — Fri, 29 Dec 2006 16:09:00 GMT

In questo 4° post su CruiseControl .NET verrà mostrato come generare automaticamente un nuovo numero di versione ad ogni build ed assegnarlo al progetto in maniera automatica.

Cruise Control .NET, La web dashboard

Gian Maria Ricci — Wed, 20 Dec 2006 11:13:00 GMT

So che fare due post così vicini tra loro non è politicamente corretto :S comunque volevo fare un ulteriore considerazione sulla seconda parte delle mie impressioni su CC.NET. Se consultate la documentazione di CC.NET trovate sicuramente che nelle ultime versioni è stato aggiunto un task particolare per MSBuild, per cui ci si chiede "perchè utilizzare il nant da cui poi non facciamo altro che chiamare MSBuild, invece di utilizzare l'appropriato task per MSBuild??". Le mie ragioni personali sono le seguenti. In primo se utilizzo MSBuild come task, poi per coerenza lo dovrei utilizare anche per fare altre operazioni tipo copiare file in giro, fare test etc etc, per questi task è meglio Nant. MSBuild non è presente per Visual Studio 2003, meglio quindi abituarsi ad utilizare il task del NANT, se abbiamo una soluzione di VS2005 utilizziamo MSBuild altrimenti utilizziamo il suo task <solution>. Stranamente l'output del WebDashboard mi sembra migliore nel caso di NANT. Prima di spiegare cosa è e come funziona il Dashboard, bisogna sapere che i vari tool producono output che deve essere preso da CC.NET per essere mostrato all'utente in modo da far vedere cosa sta succedendo nelle varie build. MSBuild non emette di suo output XML, per cui il suo output non può essere consumato da CC.NET che vuole solamente XML come output. Per questo sono stati fatti formatter appositi su cui potete anche trovare ulteriori informazioni. Il task risultante nel mio caso è questo. <msbuild> <executable>E:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> <workingDirectory>F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\TestProject1</workingDirectory> <projectFile>TestProject1.sln</projectFile> <buildArgs>/T:rebuild /p:Configuration=Debug</buildArgs> <targets>Build</targets> <timeout>15</timeout> <logger>E:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> </msbuild> Come vedete ho specificato nel logger la dll che esegue la formattazione, nonostante quseto nel webdashboard non vedo gli warning di compilazione BUILD SUCCESSFUL Project: CCNetTest Date of build: 20/12/2006 9.57.01 Running time: 00:00:05 Integration Request: continuous triggered a build (IfModificationExists) Last changed: 2006-12-20 09.56.49 Last log entry: Modifications since last build (1) Modified CCNET /trunk/TestProject1/TestProject1/Class1.cs 2006-12-20 09.56.49 Se invece si lancia MSBuild internamente a NAnt, nant prende tutto l'output di MSBuild, lo mette in un CDATA section del suo output file e CC.NET riesce a trovare gli warning. BUILD SUCCESSFUL Project: CCNetTest Date of build: 20/12/2006 9.59.14 Running time: 00:00:07 Integration Request: continuous triggered a build (IfModificationExists) Last changed: 2006-12-20 09.58.48 Last log entry: Modifications since last build (1) Modified CCNET /trunk/TestProject1/TestProject1/Class1.cs 2006-12-20 09.58.48 Warnings: (2) Class1.cs(10,10): warning CS0219: The variable 'other' is assigned but its value is never usedClass1.cs(10,10): warning CS0219: The variable 'other' is assigned but its value is never used Per questa ulteriore ragione ho preferito mostrare come lanciare msbuild direttamente da uno script NANT. Alk. powered by IMHO 1.3

Cruise Control .NET - La prima build

Gian Maria Ricci — Wed, 20 Dec 2006 10:42:00 GMT

Nella speranza che qualcuno sia interessato alle mie esperienze in CC.NET oggi posto subito questa seconda parte. Nella prima parte si è visto come istallare e configurare il CC.NET affinchè punti ad un repository subversion e faccia sempre il getlatest ad ogni nuova modifica. Oggi viene il momento di capire come fare un build. LA mia esperienza personale è questa, dopo avere passato un 20 min in rete a documentarmi ho deciso di utilizzare Nant. Si potrebbe anche utilizzare MSBuild, ma purtroppo non esiste in visual studio 2003, le cui solution possono invece essere buildate direttamente da Nant, ed inoltre si può comunque lanciare MSBuild direttamente da Nant. Passo1: la prima cosa da fare è capire come fare il build di una solution Visual Studio 2005 con MSBuild, la riga di comando è questa. msbuild F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\TestProject1\TestProject1.sln /T:rebuild /p:Configuration=Debug Come si può vedere basta specificare la solution, il parametro T con cui si chiede un rebuild ed infine la configurazione che in questo caso è quella di debug. Passo2: Ora che sappiamo come utilizzare msbuild per effettuare una build bisogna capire come lanciarlo da uno script Nant. Premetto che non ho mai utilizzato Nant e per questo la soluzione che posto è quella che mi è venuta in mente per prima . Il primo passo è scaricare il Nant e mettere il tutto direttamente nella cartella di subversion dove sono i sorgenti. Questa è infatti una best practice, tenere gli strumenti di build assieme ai sorgenti. A questo punto bisogna creare un file di build per il nant, lo ho creato nella stessa cartella della solution è lo ho chiamato TestProject.build. <?xml version="1.0"?><project name="TestProject1" default="MSBuild"> <property name="projectdir" value="F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\TestProject1"/> <property name="MSBuildDir" value="E:\WINDOWS\Microsoft.NET\Framework\v2.0.50727"/> <target name="MSBuild"> <exec program="${MSBuildDir}\msbuild.exe" commandline=" ${projectdir}\TestProject1.sln /T:rebuild /p:Configuration=Debug" basedir="."/> </target> </project> Attendo i commenti di chi conosce veramente il Nant. Una breve spiegazione la posso dare anche subito, un file build è un file XML con un funzionamento simile a quello dei makefile con cui si compilavano i programmi C/C++. Iniziamo a definire un nodo progetto, in cui specifichiamo il task di default. Internamente con il tag property si mettono delle variabili, quel tanto che basta per rendere lo script più comprensibile. A questo punto il tag target permette di specificare le attività da fare, inizialmente ne ho messa una chiamata MSBuild, il cui unico task è lanciare con il tag exec la compilazione tramite MSBuild. A questo punto bisogna testare lo script con il Nant NAnt.exe -buildfile:F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\TestProject1\TestProject1.build Una volta che si è verificato che tutto è ok si può andare a modificare il file di configurazione principale di CC.NET aggiungendo un nuovo task. <cruisecontrol> <project name="CCNetTest"> ...Questa parte è come nell'esempio precedente. <tasks> <nant> <executable>F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\BuildTools\nant-0.85\bin\nant.exe</executable> <buildFile>F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\TestProject1\TestProject1.build</buildFile> <targetList> <target>MSBuild</target> </targetList> </nant> </tasks> </project></cruisecontrol> Come potete vedere si è aggiunto un nodo tasks, in cui specifichiamo un task di tipo nant, di seguito specifichiamo dove abbiamo messo gli eseguibili, che come potete vedere si trovano nel subversion assieme ai sorgenti, si specifica quale è il file di build ed infine si mette la lista dei target, nel nostro caso solamente MSBuild. A questo punto potete provare a modificare un file sorgente, fare il check in e vedrete al prossimo controllo il vostro progetto automaticamente compilato. Con questo primo step avete il vostro primo sistema di Continuos Integration, anche se la vera potenza di CC.NET deve ancora essere utilizzata. Alk. powered by IMHO 1.3