Sperimentare la CI con Jenkins

Jenkins può risultare un pò ostico da installare per un non sistemista. Ma niente paura, abbiamo rilasciato una buildout e anche qualcos'altro!

Voglia di sperimentare?

Hai voglia di sperimentare la Continuous Integration con Jenkins?
Abbiamo rilasciato un buildout che ne automatizza l'installazione, è disponibile qui: https://github.com/abstract-open-solutions/Jenkins-Buildout
 
Jenkins è lo strumento maggiormente diffuso nelle comunità (anche quelle Python, nonostante sia fatto/pensato per Java) per quanto riguarda la CI.
 
A questo link è possibile vedere l'istanza Jenkins in funzione per il progetto Plone
Jenkins è uno strumento altamente configurabile, permette di suddividere una "build" in step.
Ogni step può effettuare delle operazioni. 
Esistono plugin per integrarlo con IRC / Jabber / Twitter, inviare email, generare grafici, ecc...
 
Per semplificare la creazione di un job per un nuovo progetto (avviamo diversi progetti al mese!) abbiamo creato inoltre una recipe per zc.buildout (che presto rilasceremo su pypi!) che automatizza il processo di creazione e pubblicazione di un job direttamente da buildout.

Cos'è la CI

Continuous Integration è un termine sempre più spesso usato, specialmente nell'ambito dell'OSS.

Iniziamo con una definizione da Wikipedia:

In software engineeringcontinuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently

E' chiaramente qualcosa che ha a che fare con la qualità del codice, si innesta nelle pratiche di sviluppo agile, ma in che modo? 

CI è una "metodologia" che prevede che il software venga testato in automatico via via che i commit arrivano sul repository.

Il sistema di CI non sa nulla di cosa e come testare il software. Affinchè un software possa essere testato c'è bisogno di avere... i "test" appunto.

E questo è un fatto. Per trarre beneficio dalla CI c'è bisogno di scrivere ( e saper scrivere ) dei test.

Il sistema di CI si occupa tipicamente di:

  • collezionare il codice dai repository remoti
  • lanciare i test automatici
  • effettuare eventualmente delle misurazioni o dei test statici sul codice
  • generare dei report più o meno completi / complessi
  • notificare chi di dovere
In realtà può fare anche qualcos'altro di più complicato ma lo vedremo in futuro.
Interessanti sono le misurazioni o i test statici: è possibile setacciare il codice con pylint, contare le righe di codice, validare rispetto alla PEP8, controllare pezzi di codice ripetuto (si, avete capito bene... mollate il copy&paste ;D ), ecc.

CI Hosted Service

Se il vostro progetto è open e cercate una soluzione hosted potete provare Travis.
Il progetto è ospitato su GitHub (https://github.com/travis-ci) e, sebbene sconsigliato e non ancora pronto, potete anche provare ad installarvi un Travis in casa.

Next Step?

La CI è fondamentale per garantire qualità del codice (a patto di scrivere test buoni).
Se usate il buildout per il deploy dei vostri progetti siete già uno step avanti; mettetela in questo modo: se solo avete un sistema che periodicamente colleziona il vostro codice, aggiorna i pacchetti, lancia il buildout e controlla che termini con successo avete già aggiunto un step di controllo di qualità al vostro codice. Non è sufficiente certo, ma è un passo avanti.
Ma non è tutto. 
La CI è un pezzo fondamentale di una strategia ancora più ampia che prende il nome di Continuous Deployment (o Delivery) (CD).
Sistemi come Heroku ad esempio applicano questa metodologia.
Ne parleremo in un prossimo articolo ma vi lascio con qualche stimolo: dopo che una build di Jenkins è terminata con successo, potete istruire il sistema a fare qualcosa di meglio del semplice inviare una mail... eh? cosa?
  • Potrebbe notificarvi su Jabber o su Skype
  • Potrebbe fare il merge di una branch su GIT
  • Potrebbe impacchettare tutto e pubblicare l'artefatto via FTP
  • Potrebbe taggare una revisione e pushare
  • ...
Pensate ad un sistema dove la sviluppatore fa il commit delle sue modifiche, Jenkins lo controlla e finito il controllo "aggiorna automaticamente in produzione" (qualsiasi cosa questo significhi per voi) il nuovo codice... i sistemisti vi ringrazieranno e i clienti pure :D
 

TDD e CI ad EuroPython 2012

Quest'anno ad #EP2012 si parlerà spesso di TDD (Test Driven Development) e CI, vi segnalo qualche talk:
 
Ci incontriamo li!
 

Share this on

Share |

On same topics

Commenti

comments powered by Disqus