113 / 134
GIUGNO-LUGLIO 2017
AUTOMAZIONE OGGI 399
113
- parallelizzare e scalare l’architettura di test per ottenere tempi
di compilazione più veloci. Ciò dovrebbe includere la possibilità
di effettuare test e simulazioni di tutti i diversi ambienti hardware
sui quali il software sarà distribuito;
- realizzare una supervisione intelligente, in grado di compren-
dere quale sia il minore numero di test da rieseguire in presenza
di una variazione del codice sorgente.
Questa architettura, intelligente e scalabile, offre alle aziende un
indubbio vantaggio competitivo, in quanto esse possono facil-
mente rispettare le date di rilascio dei prodotti e reagire rapida-
mente ai cambiamenti del mercato.
Anticipare il test: Agile Development
o Test-Driven Development (TDD)
Lo scopo di un sistema di CI evoluto è abilitare i test subito e
spesso (sviluppo basato su test), al fine di evitare ciò che è noto
come ‘l’inferno dell’integrazione’. Nelle moderne applicazioni
embedded, con milioni di righe di codice, lasciare la fase di col-
laudo per ultima è una pratica pericolosa.
Gli sviluppatori potrebbero trovarsi costretti ad abbandonare un
progetto, o ad affrontare gravi difficoltà finanziarie e possibili san-
zioni per aver scoperto un bug troppo tardi. Il ben noto grafico
di Figura 1 illustra perfettamente il punto in cui è più facile e più
conveniente ricercare e correggere un bug prima che sia tardi.
La CI è pensata per essere combinata con test di unità au-
tomatizzati. Storicamente, si riteneva fosse meglio eseguire
tutti i test di unità nell’ambiente locale degli sviluppatori e
confermare che tutti questi test fossero stati superati, prima
di rendere disponibile questo codice archivio, per evitare la
diffusione di codice con problemi.
Con lo sviluppo delle pratiche di CI è stato introdotto il con-
cetto di server di compilazione, per eseguire automatica-
mente i test di unità e, nel tempo, questo è stato ampliato
per includere anche l’applicazione di processi continui di QA.
Questa evoluzione migliora la qualità del software, riduce il
time-to-market e costruisce una solida base per il futuro del
codice, riducendo la prevalenza del Debito Tecnologico (Tech-
nical Debt).
Jenkins: un ‘maggiordomo’ a disposizione
Senza Jenkins, uno strumento open source server-based di Conti-
nuous Integration scritto in Java, eseguire la ricompilazione incre-
mentale di un’applicazione può richiedere ore e i test potrebbero
necessitare di settimane, mentre Jenkins abilita test continui
ogni volta che una variazione del codice sorgente viene eseguita
molto rapidamente.
Introdotto a inizio 2005, Jenkins ha ora oltre 400 plug in, che
consentono al software di essere utilizzato con altri linguaggi di
codifica per supportare la compilazione e il test di qualsiasi pro-
getto. Jenkins è meglio descritto come ‘job server’, con nessun
limite riguardo a quale processo sia necessario eseguire, che si
tratti di un comando ‘make’ per compilare e collegare un’appli-
cazione, di uno script batch per installare le precondizioni per un
test, o di un eseguibile, che favorisca un ambiente di simulazione
completo di un sistema embedded. Jenkins assiste la CI offrendo
un’infrastruttura distribuita di test, che fornisce la possibilità di
definire un elenco di ‘nodi’ (questi possono essere macchine fi-
siche o virtuali), ‘taggare’ un nodo per indicare i tipi di processi
che possono essere eseguiti, inviare da remoto liste di processi
di nodi e relazionare sullo stato di un processo quando questo
è terminato. In termini semplici, Jenkins è il ‘maggiordomo’ che
prende istruzioni sotto forma di un elenco di processi da eseguire.
Il risparmio di tempo è uno dei vantaggi chiave della CI e Jenkins
contribuisce a questo offrendo un ambiente di lavoro per un
approccio ottimizzato e distribuito alla compilazione ed esecu-
zione dei test. Jenkins gioca dunque un ruolo vitale nella CI, ma
è necessario software aggiuntivo per gestire il processo di inte-
grazione complessivo e fornire visibilità per un ambiente di test
CI completo. Perché la CI sia più efficace, infatti, tutti i membri
del team di sviluppo software devono essere messi in grado di
condividere i test ed essere sempre aggiornati riguardo alla rapi-
dità dei rilasci. Tuttavia, molte delle applicazioni odierne vengono
distribuite in più ambienti e configurazioni, pertanto l’ambiente
di compilazione e test deve poter testare diversi sistemi operativi
e combinazioni hardware. Questo è normalmente controllabile
con i file di configurazione, le macro e le opzioni del compilatore
per specificare le diverse versioni. È fondamentale che il testing
sia completato per ogni configurazione, per cui il sistema CI più
evoluto ha bisogno di strumenti per gestire i processi.
Figura 1 - I ritardi che un test tardivo del software possono
comportare non sono solo costosi in termini di tempo, ma
anche finanziariamente
Figura 2 - Jenkins è una sorta di ‘maggiordomo’ che prende
istruzioni sotto forma di un elenco di processi da eseguire