Continuous integration

L'aggiornamento software negli anni ha passato forti cambiamenti concettuali dovuti soprattutto a evoluzioni tecnologiche ma anche a mutamenti nella società umana.

I cambiamenti tecnologici sono evidenti: prima di Internet effettuare aggiornamenti era estremamente difficoltoso quindi era vitale consegnare immediatamente programmi evoluti e stabili.

I cambiamenti nella società sono decisamente piu' difficili da vedere: viviamo in un periodo in cui le mode nascono rapidamente e tanto rapidamente svaliniscono,

Questi due fattori assieme hanno decretato la fine dei programmi 'sigillati' per sancire l'inizio dei software in costante evoluzione, mai terminati, mai definitivamente pronti. Oggi e' un bene considerare i software come essersi viventi il cui ciclo vitale non puo' mai considerarsi concluso fino alla morte.

La tecnologia Cloud ha ulteriormente estremizzzato questo fatto dando inizio ad una nuova generazione di software caratterizzati da aggiornamenti continui.

Non più aggiornamenti periodici ma aggiornamenti istantanei, costanti, no predeterminati ma decretati esclusivamente dal ciclo di vita: sviluppo->test->deploy.

Questa caratteristica prende il nome di continuous integration e prevede una serie di imprescindibili strumenti tecnologici per poterla attuare:

1- repository del codice sorgente con aggiornamenti costanti

fondamentale per gestire le versioni, mantenere uno storico del codice e gestire le differenze fra le versioni. Inoltre è fondamentale anche per tenere linee di codice separate (branch) fra gli ambienti di sviluppo, test e produzione.

perfetto per questo è il repository GIT

2- semantica di versionamento precisa

Il sistema di versionamento più versatile è sicuramente quello costituito da tre numeri sequenziali per indicare la versione. Es.: 1.2.12

in questo caso il primo numero è detto major release, incrementa quando la versione è significativamente differente rispetto alla precedente e spesso non retrocompatibile.

il secondo numero indica la minor release, viene incrementato ad ogni cambio non significativo del software ma che introduce comunque nuove funzionalità

il terzo numero è la micro release o patch release e viene incremento ad ogni variazione del software atta solo al bug fixing

3- gestione automatica delle dipendenze fra componenti

Ogni software si appoggia pesantemente su ulteriori componenti, spesso si tratta di una moltitudine di componenti in cui è necessario specificare in modo preciso la versione desiderata al fine di non incorrere in versioni non compatibili con quanto atteso.

In java è maven o gradle che si occupa di questo

In nodejs è NPM

In front-end si usa bower

4- controllo statico del codice automatico

ok, è vero, non è una componente fondamentale, ma ci permette di garantire un livello qualitativo piuttosto stabile in quanto effettua controlli semantici sul codice sorgente garantendo di poter evitare alcune strutture particolarmente poco pulite come il livello di ricorsività, la mancanza di documentazione, ecc...

5- compilazione automatica del codice sorgente e generazione dei compilati

Esistono applicativi capaci di monitorare eventuali commit sui repository al fine di compilare immediatamente il codice sorgente e notificare eventuali errori di compilazione.

La cosa migliore è quella di prevedere un sviluppo test driven e di far effettuare automaticamente i test a questi programmi.

In java i programmi di compilazione più usati sono Jenkins

Travis (per un ambiente fortemente orientato ai servizi) si adatta a qualasi tipo di codice sorgente

6- installazione automatica dei compilati nei vari ambienti

E' possibile utilizzare a seconda dei vari ambienti sistemi di installazione automatica del software in questo modo il codice che viene messo sul repository viene automaticamente compilato e installato nel server corretto a seconda del branch di appartenenza

Ad essere sincero questo rientra in un'altra prassi che viene definita continuous delivery, ma personalmente ritengo che la continuous integration privata di questa componente risulti eccessivamente castrata e non permetta la continuità desiderata

La normale vita lavorativa di uno sviluppatore risulterebbe così sconvolta dalla continuous integration:

- sviluppo il mio software e ad ogni situazione stabile lo committo sul repository GIT

- travis o chi per esso si accorge dell'avvenuto commit. Preleva i sorgenti, li compila e li testa.

- se la compilazione e i test hanno avuto successo il programma verrà automaticamente installato sui server di sviluppo (se il branch del repository era quello di sviluppo) o test (se il branch del repository era quello di test)

- viene inviata notifica al programmatore l'eventuale messa in sviluppo o in caso contrario le motivazioni del rifiuto: test non superati, codice sporco, errori di compilazione, ecc..

- il passaggio del codice sorgente da branch di test a quello di produzione dovrebbe essere esclusivo diritto del release manager e di chiunque abbia la responsabilità di approvare la messa in produzione del software