Nei precedenti articoli abbiamo visto come utilizzare ant per implementare i diversi processi (build, testing, etc…) nei progetti. In questo articolo si chiude la serie, mostrando il passo successivo, ovvero l‘automazione dei processi utilizzando ancora ant per realizzare soluzioni di Continuous Integration.

Continuous Integration

La Continuous Integration è una pratica dello sviluppo software introdotta per i contesti in cui i diversi membri di un progetto integrano il loro lavoro frequentemente, almeno una volta o anche più volte al giorno. Essa consiste nell‘esecuzione automatica dei processi di build e testing durante ciascuna fase di integrazione, al fine di individuare i possibili errori il prima possibile.
Tale approccio ha portato alla significativa riduzione dei problemi di integrazione e ha consentito lo sviluppo di software più rapidamente.

Il termine Continuous Integration nasce nell‘ambito dell‘eXtreme Programming ed è una delle pratiche alla base di tale metodologia di sviluppo. Tuttavia non bisogna essere degli sviluppatori XP per capire quanto l‘esecuzione automatica dei processi di build e testing sia importante e apportatrice di effetti benefici per ogni progetto.

I vari benefici possono essere riassunti nella nota espressione “riduzione del rischio”. Introducendo un meccanismo di Continuous Integration si è in grado, infatti, di sapere esattamente a che punto ci si trova nel ciclo di sviluppo, cosa funziona nel sistema e quali sono i bug.
Ciò avviene monitorando continuamente lo stato del repository del progetto e mettendo a disposizione un ambiente allineato e certificato in ogni momento.
Per quanto riguarda poi i bug tale pratica non li elimina, ma ne riduce il numero consentendo di intervenire prontamente ed in modo mirato nei casi in cui se ne introducano di nuovi.
Questo è tanto più vero quanto più efficaci sono i test: l‘automatizzazione del processo di testing consente, infatti, di eseguire le diverse suite di test quotidianamente o anche con frequenza maggiore, migliorando la qualità  del codice prodotto senza rallentare il normale ciclo di sviluppo del software.

Per tutti questi motivi la Continuous Integration non è rimasta confinata nel contesto dell‘eXtreme Programming, ma è entrata a far parte dello sviluppo software in generale come procedura di quality assurance.

Automatizzazione dei processi in Ant

Ant, come sottolineato in questa serie di articoli, è uno strumento estremamente versatile e consente di eseguire in modo meccanico e ripetibile i vari processi di un progetto. Tuttavia prima di lanciare un target ant si devono spesso compiere dei passi manuali che non sempre rendono immediata l‘esecuzione di un processo.

Il primo di questi passi è costituito dalla configurazione del workspace del progetto e riguarda il setting dei path dipendenti dalla propria macchina nei file di properties di ant e nei file di configurazione. Quest‘attività  va ripetuta ogni volta che si esegue il checkout e, vuoi per la sua meccanicità , vuoi per l‘inesperienza dei neofiti del progetto, è spesso fonte di errori e dimenticanze.

Ancora una volta però ant ci fornisce gli strumenti per risolvere tali problemi offrendoci un modo per rendere tutti i files di configurazione parametrici e indipendenti dalla piattaforma utilizzata.
Questo meccanismo è noto come tokenizzazione e consiste nella definizione, appunto, di un token, ovvero un marcatore, che poi viene valorizzato a runtime con un valore relativo all‘environment locale.

Figura 1 – Effetti della tokenizzazione su un file

L‘implementazione di questa tecnica con ant sfrutta il task , che è usato nelle copie/spostamenti di file, e richiede i seguenti interventi:

• si specificano i token delimitati dal separatore nei vari file di configurazione/properties che si vogliono tokenizzare (ant di default usa il carattere @, ma è possibile usare un altro separatore previa la sua definizione negli attributi begintoken ed endtoken del task );
• si indicano nel build.xml i valori da sostituire token (si possono ad esempio sfruttare la property basedir di ant e le variabili di environment per specificare proprietà  e path relativi all‘ambiente locale).

Di seguito è riportato un esempio di build file che esegue una tokenizzazione (si noti l‘uso del task che trasforma i back slash() in slash(/) per evitare problemi nel caso dei path calcolati su piattaforma windows):

 
 

 
 
  
  
  
  
  
 

    
  
   
   
    
     
    
  

  
   
   
    
    
  

  
   
   
    
    
    
   
  
 

Anche dopo aver configurato correttamente il proprio workspace non si è tuttavia ancora pronti per eseguire in modo automatico tutti i target ant . Per alcuni, si pensi ad esempio al target che lancia i test di integrazione, sono necessari degli ulteriori step manuali come lo start dell‘application server e l‘avvio di tutte le altre componenti dell‘architettura applicativa utilizzate (p.e. motori di tariffazione, documentale, …).

In questi casi per automatizzare si possono sfruttare i task e , che permettono di invocare, rispettivamente, applicazioni esterne native e Java.
I task indicati consentono di eseguire dei comandi sul sistema operativo ospitante e di effettuare o meno lo “spawn” (ovvero l‘esecuzione fuori al di fuori della virtual machine di ant) delle applicazioni lanciate quando l‘attributo fork è impostato a true.
Nel frammento di build file sottostante è mostrato un esempio di target che lancia i test di integrazione effettuando start, deploy e stop sull‘application server:

 
 
 
 
  
  
 
 
  
  
 
   
 
 
 
 

 
 
  
  

A questo punto disponiamo di un build file automatizzato, ovvero che non richiede più quei passi manuali che prima si dovevano compiere per lanciare tutti i target ant.
Possiamo quindi sfruttare il sistema operativo per schedulare i processi ant con la periodicità  desiderata; possiamo inoltre eseguirli su una base di codice allineata integrando il repository o con dei task ant, se disponibili per il particolare sistema SCM usato, o con degli script a parte.
Per completare questa soluzione di Continuous Integration si può infine pensare di aggiungere un MailLogger all‘invocazione di ant in modo da inviare delle email di alert a seconda dell‘esito dei processi ant.

È lecito ora chiedersi se c‘è un modo per semplificarci la vita, evitando di ripetere per ogni progetto tutta questa fatica. La risposta alla domanda è ovviamente affermativa ed è costituita dai server di Continuous Integration.
Questi tool offrono, infatti, una completa assistenza nell‘implementazione di una soluzione di Continuous Integration presentando all‘utilizzatore le seguenti caratteristiche:

• Integrazione di sistemi di versionamento (CVS, Subversion, …)
• Integrazione di build-tool (Ant, Maven, …)
• Feedback e reporting con diversi sistemi di notifica (E-mail, Instant messenger, RSS, …)
• Labeling (cioè la possibilità  di taggare sul repository dopo ogni build eseguita con successo)
• Gestione delle dipendenze tra diversi progetti

Va precisato che non tutte le features elencate sono supportate da ciascun server di Continuous Integration, ma di volta in volta va selezionato il prodotto che meglio si adatta alle proprie esigenze.

Apache Continuum

Vediamo ora come mettere in piedi in pochi passi una soluzione di Continuous Integration, partendo da una situazione in cui si ha un build file automatizzato (con i precedenti accorgimenti) ed utilizzando Apache Continuum, un server open source di Continuous Integration.

Il setup e la configurazione di Continuum sono immediati. Ad esempio in Windows bastano i seguenti 4 passi:

1. Scaricare il file ZIP di Continuum
2. Estrarre il contenuto dello zip in una directory locale
3. Andare nella dir binwin32 ed eseguire il file run.bat
4. Aprire il browser e digitare nella barra degli indirizzi http://localhost:8080/continuum

L‘accesso alla web application di Continuum avviene di default con un account guest che ha diritti read only su tutti i progetti. Al primo accesso appare comunque la seguente pagina di amministrazione che permette di creare un utente amministratore e di settare una serie di proprietà  comuni a tutti i progetti (p.e. le directory di lavoro, di build e di deploy).

Figura 2 – Pagina di amministrazione di Continuum

L‘interfaccia web di Continuum rende molto semplice la creazione di un progetto di Continuous Integration. Dopo essersi loggati con l‘utente amministratore, è sufficiente nel nostro caso cliccare su “Add Ant Project”e configurare lo strumento di versionamento utilizzato, come mostrato nella figura che segue:

Figura 3 – Creazione di un progetto in Continuum

Dopo aver inserito queste informazioni, Continuum è già  pronto per l‘uso: esegue,infatti, il polling del repository ogni ora e lancia il target di default nel build.xml nella root del progetto. Ovviamente è possibile modificare le proprietà  del progetto per definire l‘intervallo di tempo che meglio risponde alle proprie esigenze, così come il target ed il build file da eseguire.

Come appena mostrato, Continuum consente quindi di implementare soluzioni di Continuous Integration in modo semplice ed immediato. Questo strumento, infatti, sebbene sia uno dei server di Continuous Integration più recenti apparsi sulla scena, ha riscosso subito molti consensi grazie alla sua facilità  d‘uso ed al suo supporto di diversi sistemi di versionamento e tool di build. Di seguito sono riportate per completezza le principali caratteristiche di Continuum:

• Supporto dei seguenti sistemi di versionamento: Subversion, CVS, StarTeam, Bazaar, e Perforce (c‘è anche un supporto parziale per Visual Source Safe e ClearCase)
• Supporto dei seguenti tool di build: Ant, Maven1, Maven2, e Shell (command line)
• Interfaccia web
• Possibilità  di girare come servizio Windows
• Notifiche via mail e IM
• Scheduling basato su Quartz

Conclusioni

Nell‘articolo si è parlato di come automatizzare l‘esecuzione dei processi ant, utilizzando la tokenizzazione per la sostituzione dei percorsi relativi nei file di properties/configurazione e i task e per l‘invocazione di applicazioni esterne.
Quindi si è mostrato come usare un build file automatizzato in Apache Continuum per realizzare in pochi passi una soluzione di Continuous Integration.

Riferimenti

[ANT] Sito ufficiale del progetto Jakarta Ant
http://jakarta.apache.org/ant

[ADG] Jessy Tilly – Eric Burke, “Ant Definitive Guide”, O‘Reilly

[JDA] Eric Hatcher – Steve Loughran, “Java Development with Ant”, Manning

[CONT] Sito ufficiale di Apache Continuum
http://maven.apache.org/continuum/

[CIC] http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html

Amedeo Cannone

Amedeo Cannone si è laureato in Ingegneria Informatica presso l‘università degli studi di Bologna.
Dal 2003 lavora per il Gruppo Imola per cui svolge attività di consulenza su tematiche architetturali e di processo.
Al momento sta seguendo alcuni progetti di integrazione SOA e si sta interessando di ESB e JBI.
Il profilo completo è visualizzabile su LinkedIn all‘indirizzo
http://www.linkedin.com/pub/dir/Amedeo/Cannone