La continuos integration: i concetti di Docker e container

Continuous Integration e il processo di build

Il processo di sviluppo del software avviene attraverso un sistema di controllo versione. Consiste nell'allineamento frequente degli ambienti di lavoro degli sviluppatori verso l'ambiente di lavoro condiviso (mainline). Una delle politiche principali della Continuous Integration è "building software at every change". Questo concetto è stato adottato come contromisura preventiva per il problema dell'"integration hell" (difficoltà dell'integrazione di porzioni di software sviluppati in modo indipendente su lunghi periodi di tempo e che potrebbero essere molto divergenti).

Quindi, la continuous integration consiste nell'integrare spesso, limitando le possibilità che si verifichi l'inferno dell'integrazione.

Molto spesso si pensa che con il termine build ci si riferisca solo al processo di compilazione, ma non è così. Infatti, il processo di build comprende: compilazione, testing, inspection, deployment e molto altro. I componenti

1. Version control repository;
2. CI Server: fa partire il processo di build quando una "change" (cambiamento) viene apportato "commit" nel repository;
3. Dashboard;
4. Build Scripts: script usati per effettuare la compilazione, il testing, il deployment e molto altro (Ant, Make, Maven, Gradle);
5. Feedback Mechanisms: utili ad informare gli sviluppatori circa l'esito del processo di build (email, messaggi).

La integration build machine è quindi presente un integration build machine responsabile dell'integrazione del software, tipicamente questa macchina ospita il CI Server che preleva il sorgente dal "version control repository".

Le attività svolte da questa macchina sono:

1. Source code compilation: compilazione del software che non va sempre fatta, ad esempio PHP e Python non richiedono compilazione.
2. Database integration: bisogna assicurarsi che il database si integri con la versione del software contenuta nel

“version software repository”, si usano script DDL e DML;

Testing: è una parte essenziale del processo di CI, vengono usati software come JUnit;

Inspection: processo automatizzato che prevede l’analisi statica e dinamica volta a migliorare la qualità del codice prodotto (assicurarsi che una classe non sia costituita da più di 500 LOC, oppure che il codice sia opportunamente commentato), viene effettuata da tool come Checkstile, FindBugs e PMD;

Deployment: l’obiettivo di questo processo è quello di generare software impacchettato e renderlo disponibile per il testing di sistema. Inoltre il processo di CI può dispiegare e installare il software nell’ambiente target;

Generating documentation: è necessario sviluppare documentazione del software tramite tool come JavaDoc, solitamente, questo processo è effettuato periodicamente e non continuamente.

Quindi, possiamo far riferimento ai seguenti concetti

• Build: un insieme di jobs;
• Job: processo che clona il repository in un ambiente virtuale e lancia processi di compilazione, testing e così via;
• Phase: uno step del job.

I vantaggi derivanti dall'applicazione della pratica della "continuous integration" sono i seguenti:

1. Riduzione dei rischi: I difetti vengono individuati e risolti subito poiché viene effettuato il testing e l'ispezione ad ogni build. Inoltre, si riduce la dipendenza del software dalla macchina locale e dalla sua configurazione;
2. Riduzione di processi manuali ripetitivi: il processo di build esplica le stesse fasi più volte, viene eseguito ad ogni commit;
3. Generazione di software "deployable": è il principale vantaggio, gli effetti di piccoli cambiamenti sono visibili immediatamente nel software in esecuzione;
4. Migliorare la visibilità del progetto: tramite i meccanismi di feedback.

• Vengono forniti agli sviluppatori informazioni circa i risultati delle build recenti;
• Evitare le problematiche dello "integration hell"

I principali svantaggi derivanti dalla CI potrebbero essere:

• Aumento dell'overhead dovuto alla manutenzione del processo di CI;
• La CI potrebbe introdurre molti cambiamenti nel processo di sviluppo;
• Necessità di software ed hardware addizionale;
• Task addizionali per gli sviluppatori.

Gli elementi chiave per far funzionare bene il processo di CI sono:

• Effettuare commit frequenti del codice cercando di modificare piccole porzioni dello stesso;
• Non effettuare commit con codice che genera errori e non compila;
• Aggiustare le "broken build" immediatamente in modo da evitare di generare una valanga di errori;
• Scrivere dei test tramite strumenti che li automatizzino, ad esempio JUnit o xUnit;
• Tutti i test e le ispezioni devono passare;
• Eseguire delle build private, poi build di integrazione.

infine build di release;

Riduzione dei rischi mediante software integration

L'utilizzo della pratica di continuous integration determina un abbassamento dei rischi relativi allo sviluppo software, tra cui:

• Mancanza di software distribuibile;
• Scoprire i difetti in ritardo;
• Mancanza di visibilità del progetto;
• Produrre software di bassa qualità.

Le build

Molto spesso le build sul server CI sono lanciate all'interno di un container (ad esempio un Docker container). Difatti si consiglia di lanciare le build in un ambiente il più simile possibile all'ambiente target.

Esistono diverse tipologie di build, tra cui:

• Private build: eseguite sulla macchina locale dello sviluppatore per valutare la qualità del segmento di codice generato;
• Integration build: eseguite per valutare la qualità del sistema software generale, viene valutata l'integrazione tra le diverse componenti;
• Release build: effettuate prima del deployment,

generano documentazione allegata al codice. Lo scopo è creare software distribuibile "deployable". Le build possono essere eseguite:

• On-demand: eseguite manualmente;
• Scheduled: ad intervallo di tempo prestabiliti, ad esempio ogni ora;
• Pool for changes: il server CI valuta in base ai cambiamenti quando effettuare il build;
• Event-driven: il versioneing system innesca la CI.

Conviene usare una macchina dedicata per il build, quindi ci si riferisce allaintegration build machine, per evitare le problematiche del tipo "ma gira sulla miamacchina". Ovviamente questo ha dei costi aggiuntivi.

Per valutare ciò che avviene durante il processo di build si possono valutare opportune metriche, tra cui:

• Compilation time;
• Number of source code lines;
• Number and types of inspections;
• Test execution time;
• Deployment time.

È possibile adottare delle strategie per migliorare queste metriche.