Integrazione continua e Jenkins

Vitalij Zadneprovskij

JUG Roma

5 Febbraio 2014

Infosons

Inferno dell'integrazione

● Scarico il codice sorgente● Faccio le mie modifiche● Eseguo i test● Decido di fare commit● Peccato che qualcuno ha fatto

commit sulle stesse classi● Cerco di gestire tutti i conflitti● Non posso! Sono troppi! :-O● Ri-scarico il codice e

ricomincio da capo :-(Fonte: computerfixperts.com

2 / 14

Come si fa ad evitarlo?

● Mantieni un repository del codice sorgente● Automatizza il build● Rendi il build auto-testante● Tutti eseguono una commit alla baseline

tutti i giorni● Ogni commit fa partire una build● Fai in modo che la build sia veloce● Esegui i test in un clone dell'ambiente di

produzione● Prendere le ultime versioni dei pacchetti

deve essere facile● Ognuno può vedere quello che sta

succedendo● Automatizza il dispiegamento

Putin scopre l'integrazione continuaFonte: www.gazprom.com

3 / 14

Mantieni un repository del codice sorgente

● Basta usare un software per il controllo della versione

● Scegliere tra lock or merge o sistema distribuito

● Stanno prendendo piede i sistemi di controllo di versione distribuito come Git e Mercurial

● Sono ancora molto usati quelli a lock ottimistico come Subversion e CVS

Fonte: git-scm.com

4 / 14

Automatizza il build

● Per build intendiamo il processo che porta dal codice sorgente all'artefatto che può girare sul server o direttamente sul computer client

● Per buildare basterebbe solo Eclipse, anche se la configurazione in questo caso sarebbe molto complicata da gestire

● Opzione più diffusa è Maven, che permette anche di gestire le dipendenze da librerie open source

● Progetti legacy: Ant● Altre opzioni possibili sono Gradle,

Ivy e BuildrFonte: www.hdrinc.com

5 / 14

Rendi il build auto-testante

● Abbiamo sia i test unitari che i test di integrazione

● Solitamente i test unitari sono parecchio più veloci dei test di integrazione

● Se si è deciso di usare Maven come sistema di build, basterà mettere i test unitari nella sottocartella /src/test/java

● Per i test di integrazione ci sono varie librerie, tra cui Selenium, SoapUI, Jmeter, Arquillian

6 / 14

Tutti committano sulla baseline tutti i giorni

● È importante per limitare i conflitti e quindi l'inferno dell'integrazione

● Difficile convincere gli sviluppatori a fare commit tutti i giorni

● Ancora più difficile convincerli a testare il codice prima di committarlo

Fonte: quentinwatson.co.uk

7 / 14

Ogni commit fa partire una build

● Far partire unicamente i test unitari, postporre i test di integrazione a quando è possibile, comunque almeno una volta al giorno

● Ogni singolo commit potrebbe creare errori o fare fallire i test

● È importante che un eventuale commit che porta nuovi bug venga individuato immediatamente e vi sia posto rimedio

● Questo principio si basa sul principio “fail fast”

Fonte: benandcatherine.org

8 / 14

Fai in modo che la build sia veloce

● Se ogni commit fa partire una build, la build deve essere la più veloce possibile

● Suddividere build in due fasi● Prima fase: compilazione e test

unitari● Seconda fase: test di

integrazione● La seconda fase gira quando

possibile● Usare basi dati in memoria come

HSQLDB

Fonte: missingbite.com

9 / 14

Esegui i test in un clone dell'ambiente di produzione

● Anche la più piccola delle differenze tra l'ambiente di test e quello di produzione può rendere estremamente difficile riprodurre un bug

● Stesso sistema operativo● Stessa base dati ● Stessa JVM● Stesso application / web

server● Stessi browser

Fonte: softicons.com

10 / 14

Prendere le ultime versioni dei pacchetti deve essere facile

● Per le persone è più facile vedere ed eseguire le versioni intermedie del software e dire che cosa è che non va

● Fai in modo che ci sia un posto in cui tutte le persone possano prendere l'eseguibile e testarlo

● Sopratutto le persone che devono far girare delle demo dei prodotti per far vedere a potenziali clienti il funzionamento del software hanno bisogno di sapere dove trovare i pacchetti Fonte: bodecibody.blogspot.it

11 / 14

Ognuno deve poter vedere quello che sta succedendo

● Lo stato del progetto deve essere visibile e trasparente a tutte le parti coinvolte

● Questo permette di stabilire scadenze realistiche e allocare tempo per la risoluzione dei problemi attuali

● Inoltre, problemi di usabilità possono essere individuati più velocemente se è possibile vedere e testare facilmente l'applicativo

● È possibile stabilire un rapporto di fiducia con tutte le parti coinvolte nel processo di sviluppo

Fonte: jimbrooks.org

12 / 14

Automatizza il dispiegamento

● Per dispiegamento si intende il trasferimento degli artefatti sull'ambiente di destinazione e l'esecuzione di script di allineamento

● Per fare continous integration bisogna avere diversi ambienti che devono essere allineati più volte al giorno

● Per fare questo è buona norma avere dei meccanismi che permettano il rilascio dei risultati delle build sui vari ambienti, compreso quello di produzione

● Dopo il build è possibile trasferire il risultato del build in una cartella di un ambiente e far girare degli script di allineamento

Fonte: photo-dictionary.com

13 / 14

Jenkins

● Web application che gira in un servlet container

● Permette di lanciare delle build e dei dispiegamenti

● Permette di vedere i risultati dei test● Non ha bisogno di basi dati per

funzionare: salva le configurazioni in file XML

● Si integra con gli strumenti di controllo delle versioni e con gli strumenti di automazione dei build

● È in grado di scaricare autonomamente Maven e Ant

● Estensibile tramite plugin

14 / 14