Continuous Integration con CruiseControl.net – Introduzione

Massimo — Fri, 06 Mar 2009 21:51:59 +0000

Con questo primo articolo iniziamo una serie di incontri sul Continuous Integration. In particolare, dopo una prima panoramica sui concetti base, entreremo nel vivo con dettagli tecnici dedicati alla messa in opera di un sistema di Continuous Integration con CruiseControl.net su piattaforma Microsoft .Net Framework.

Indice degli articoli

Introduzione (questo articolo)

Che cosa è il Continuous Integration

Il Continuous Integration(abbreviato anche con CI) è una pratica di sviluppo principalmente orienta al software. Pratica che è emersa soprattutto negli ultimi anni grazie anche alla grande diffusione di metodologie come l’Extreme Programming e ad importanti sostenitori come Martin Folwer. Con pratica si intende una serie di metodi e di strumenti atti a migliorare la qualità del codice, la velocità dei tempi di rilascio e in generale a migliorare la coesione del gruppo di sviluppo. I principi alla base dell’Extreme Programming non sono oggetto di questo articolo. Invito dunque ad approfondire questo argomento con i link e i libri suggeriti nella sezione Linkografia & Bibliografia a fondo articolo.
Entriamo nel dettaglio. Per introdurre il discorso utilizzerò le stesse parole di Martin Fowler riportando la traduzione del suo articolo introduttivo sul Continuous Integration:

“Il Continuous Integration è una pratica di sviluppo software, dove i membri del team integrano il loro lavoro frequentemente, normalmente ogni persona integra il proprio lavoro almeno una volta al giorno, il che conduce a più di una integrazione al giorno. Ogni integrazione è verificata da una build automatica (test inclusi) che rileva errori di integrazione il più velocemente possibile. Molti team trovano che questo approccio conduca ad una significativa riduzione dei problemi di integrazione, permettendo al team di sviluppare software coeso più rapidamente.”

Martin Fowler da Continuous Integration , 2006

In altri termini, ogni modifica apportata al codice dell’applicazione, da ogni singolo membro del team di sviluppo, viene integrata attraverso un processo di build che ne verifica, in tempi brevi, la qualità e la coesione con il resto del codice. E’ importante capire il concetto build.

Build (letteralmente costruzione) è quell’insieme di operazioni che permettono di combinare diversi componenti software in un singolo sistema. In una visione ristretta questo può coincidere con un processo di compilazione dove il codice sorgente viene validato, linkato e compilato. La build così concepita è tipica dei linguaggi compilati, anche se, con alcune differenze, è applicabile anche ai linguaggi interpretati. In una visione più ampia, però, il processo di build può essere pensato come una complicata attività di configurazione, esecuzione ed integrazione di programmi e di sistemi più complessi. La build così come concepita nel Continuous Integration è molto più simile a quest’ultima definizione.

Con queste premesse si può certamente concludere che il Continuous Integration diventi così parte indispensabile del processo di sviluppo, di mantenimento e di distribuzione di un software applicativo.

Come funziona il Continuous Integration

Per mettere in pratica il Continuous Integration è necessario adottare, nel proprio lavoro quotidiano, una serie di abitudini e di eseguire alcune attività con l’ausilio anche di appositi strumenti software. Eccone un elenco:

Dotarsi di un repository centrale dove depositare tutto il codice sorgente del programma.
Per fare questo possiamo utilizzare un qualsiasi sistema di controllo versione (o SCM – Souce Code Management) come Subversion, Git, Mercurial, CVS o Microsoft Visual SourceSafe. L’operazione di deposito del proprio lavoro sul repository è detto commit.
Automatizzare la build attraverso strumenti software.
Per fare questo abbiamo la possibilità di scegliere tra prodotti opensouce o commerciali. Nei nostri articoli ci concentreremo su CruiseControl.net, un prodotto opensouce di ThoughtWorks. Tra i prodotti commerciali mi sento di consigliare TeamCity di JetBrain (stesso produttore nel noto plugin per Microsoft Visual Studio, Reshaper) che oltre ad essere multi piattaforma è disponibile gratuitamente nella versione Professional.
Includere test automatici nel processo di build.
In generale è buona norma dotarsi di un numero adeguato di test automatici attraverso l’utilizzo di metodologie come il TDD (Test-Driver Development) e di appositi framework di unit test come NUnit, xUnit, MSTest o MbUnit. Solo per citarne alcuni di quelli nativi per il .Net Framework. Per una lista completa, anche per altri linguaggi, consultare la sezione Linkografia & Bibliografia.
Depositare quotidianamente il lavoro svolto sul repository.
E’ importante che tutto il team di sviluppo segua questa regola fondamentale. Questo è un concetto chiave del CI. Il lavoro svolto deve essere, almeno quotidianamente, integrato con il resto dell’applicativo in modo da verificarne la correttezza. Personalmente consiglio il commit del proprio lavoro sul repository al termine di ogni singolo task completato.
E’ importante che la mainline (o trunk o basecode) rimanga in uno stato corretto.
Il codice sorgente che fa parte del codice base di sviluppo è detto mainline o trunk (in subversion) o in più generale basecode. Il commit di un programmatore può generare degli errori che fanno fallire il processo di build della mainline. Se questo accade è importante correggere tempestivamente queste problematiche, in modo da mantere la mainline di sviluppo sempre perfettamente integrata e corretta. In questo senso è bene che un programmatore non termini la propria giornata lavorativa senza aver prima sistemato gli eventuali problemi di un commit sul trunk.
Mantenere la build della mainline leggera.
Questo semplice concetto racchiude in sé un aspetto importante. Quando eseguo il commit di un pezzo di codice è essenziale avere il risultato dell’integrazione in tempi brevi. In questo modo posso correggere i problemi tempestivamente.
Il team deve essere sempre informato sullo stato di integrazione.
In questo senso ci viene incontro CrusiControl.net che ad ogni integrazione invia una mail di responso a tutto il team. Inoltre CruisControl.net possiede una comodissima interfaccia di amministrazione via web dove è possibile monitorare la situazione delle build ed eseguire vari tipi di attività.
Automatizzare il processo di distribuzione.
Inteso anche e soprattutto come creazione automatica del programma di installazione del proprio applicativo. Per fare questo sono disponibili moltissimi strumenti come NSIS, InnoSetup e InstallShield.

Cosa vedremo nei prossimi articoli

Nei prossimi articoli ci focalizzeremo sui punti 2, 3, 6, 7 e 8. Vedremo quindi tutta la fase pratica di installazione e configurazione di CruiseControl.net, come configurarlo per un tipico progetto Microsoft .Net. Nello specifico andremo ad impostare il processo di build per ottenere i seguenti risultati:

3 progetti in CruiseControl.net, uno per l’integrazione continua, una per le metriche sul codice e una di deploy.
Integrazione degli Unit Test con NUnit e NAnt
Analisi qualità del codice e del design con Microsoft FXCop & Microsoft StyleCop
Coverage degli Unit Test con NCover
Varie metriche sul codice sorgente con SourceControl
Ricerca del codice duplicato con Simian
Generazione della documentazione con SandCastle

Blog Informatico » NCover

Continuous Integration con CruiseControl.net – Introduzione

Che cosa è il Continuous Integration

Come funziona il Continuous Integration

Cosa vedremo nei prossimi articoli

Linkografia & Bibliografia

Continuous Integration

Extreme Programming

Repository (Controllo di versione o SCM – Source Code Management)

Continuous Integration Software

Unit Test & TDD