Continous integration e jenkins

1,403 views

Published on

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.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,403
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
22
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Continous integration e jenkins

  1. 1. Integrazione continua e Jenkins Vitalij Zadneprovskij JUG Roma 5 Febbraio 2014 Infosons
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×