Si parla dei principi del continuous integration secondo Martin Fowler. Si parte da un problema comune, che è quello di lavorare in tanti sugli stessi sorgenti e si vedono i principi che possono permetterci di lavorare nel modo più sereno possibile.

1. Integrazione continua e Jenkins
Vitalij Zadneprovskij
JUG Roma
5 Febbraio 2014
Infosons

2. 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

3. 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 continua
Fonte: www.gazprom.com
3 / 14

4. 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

5. 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 Buildr
Fonte: www.hdrinc.com
5 / 14

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

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