Introduzione

Nella gestione dei progetti di sviluppo software, sempre più spesso si adottano metodologie consolidate, che consentono di massimizzare la produttività del team non tralasciando la qualità del prodotto finale. La visione ad oggi generalmente condivisa nell’ingegneria del software è che lo sviluppo sia un processo industriale piuttosto che un processo artigianale, e che pertanto venga caratterizzato da diverse linee guida e procedure a cui doversi attenere durante le varie fasi del progetto. I software sono sempre più complessi da gestire rispetto alla complessità che può avere la gestione di un prodotto tangibile, poiché è richiesta una evoluzione costante e continua nel tempo (a titolo esemplificativo si può osservare come la frequenza di rilascio di un nuovo modello di smartphone è minore rispetto alla quantità di aggiornamenti che viene rilasciata nel suo ciclo di vita). Nonostante in un progetto di sviluppo software questo fenomeno sia in parte giustificato dalla mancanza di fasi specifiche della produzione industriale, che hanno un impatto diretto sul costo di produzione e sui tempi è vero che la complessità che fa parte di qualunque prodotto ingegneristico, software compreso, può portare ad avere un software che presenta dei bug, minando di fatto la stabilità del software stesso.

Continuous Integration e Continuous Delivery

Una delle pratiche di sviluppo più importanti è sicuramente la Continuous Integration (CI). La CI prescrive di effettuare integrazioni frequenti relativamente alle modifiche effettuate dagli sviluppatori, per ridurre al minimo i potenziali problemi causati da una fase di integrazione più cospicua. Gli sviluppatori quindi mantengono una copia condivisa del codice sorgente e la aggiornano ogni qualvolta viene apportata una modifica. Indubbiamente applicare tale metodologia implica la necessità di adottare un sistema di controllo di versione distribuito (DVCS), tra i più noti spicca Git. Nonostante integrare una piccola modifica sia in genere un compito meno oneroso rispetto all’integrazione di un intero modulo, una frequenza di integrazione troppo elevata può portare ad un cattivo uso delle risorse, soprattutto se questa operazione viene effettuata manualmente. Da questa prospettiva risulta evidente l’esigenza di automatizzare il processo di CI, fornendo al team di sviluppo gli strumenti necessari che consentono una veloce integrazione ed una verifica automatica del codice sorgente, al fine di poter individuare immediatamente eventuali problemi. Similmente alla CI, la Continuous Delivery (CD), prescrive cicli di rilascio brevi. Anziché rilasciare il software ad ogni major release, si distribuisce una copia aggiornata frequentemente, per garantire una migliore esperienza utente ed una più veloce capacità di adattamento degli stessi. Per attuare una corretta implementazione della CD è necessario utilizzare opportuni strumenti di automazione. Questo garantisce una maggiore qualità del software che viene rilasciato riducendo gli errori causati da interventi manuali.

GitLab

GitLab è una piattaforma web open source che permette la gestione di repository Git e di funzioni trouble ticket. Integra diversi servizi nati proprio per coprire l’intero ciclo di sviluppo del software, dall’analisi al rilascio, ponendo sempre il codice sorgente al centro di ogni attività. Il modulo CI/CD presente in GitLab viene usato sempre più frequentemente, grazie alla semplicità d’uso, alla possibilità di personalizzazione ed al fatto che si adatta facilmente a qualunque progetto.

GitLab automatizza le operazioni di CI e CD attraverso la definizione di Pipeline. Una pipeline è una sequenza di operazioni, o Jobs, che viene eseguita ogni qualvolta uno sviluppatore trasferisce le modifiche effettuate sul codice sorgente al server GitLab (in git, questa operazione è detta push). L’esecuzione di un job nella pipeline avviene solo se il job precedente è terminato con successo. In caso contrario, l’esecuzione della pipeline si interrompe e GitLab notifica allo sviluppatore che un suo push ha generato un errore. La descrizione delle pipeline e dei job viene effettuata direttamente sul repository, creando un il file gitlab-ci.yml, come si evince dall’estensione .yml, il file utilizza la sintassi YAML. Si tratta quindi di un semplice file di testo nel quale descrivere le pipeline con un linguaggio apposito.

GitLab Runner 

L’esecuzione dei comandi descritti nel file gitlab-ci.yml non avviene direttamente sul server GitLab, ma attraverso dei servizi ad esso connessi: i Runner. Questo consente di rendere le pipeline CI/CD di GitLab compatibili con qualsiasi linguaggio e piattaforma di sviluppo, poiché i comandi verranno eseguiti in un ambiente opportunamente configurato per questo scopo. I runner possono essere macchine (fisiche o virtuali) o container Docker. Gli stessi eseguono un servizio, GitLab Runner, in grado di ricevere comandi dal server GitLab al quale è associato. Quando GitLab richiede l’esecuzione di un job, il runner effettua il fetch del repository ed esegue i comandi indicati per quel particolare job. Al termine dell’esecuzione, il runner riporta il risultato dell’operazione al server GitLab, il quale si occuperà di richiedere l’esecuzione di un altro job nella pipeline e di registrare lo stato di avanzamento dell’esecuzione. E’ anche possibile eseguire più job in parallelo se si dispone di più runner della stessa classe. Ogni esecuzione di una pipeline viene registrata, ed accompagnata da importanti informazioni quali l’identificativo del commit che ha generato l’operazione, il nome dello sviluppatore che ha effettuato il commit, la data e la durata dell’esecuzione, ed infine se la pipeline è stata eseguita con successo o si sono verificati degli errori.

IES Solutions & CI / CD

Noi di IES Solutions applichiamo la Continuous Integration e Continuous Delivery nello sviluppo dei nostri software come ad esempio la suite di prodotti Jixel, utilizzando gli strumenti offerti da GitLab. Ciò garantisce di mantenere elevati standard di qualità e ridurre al minimo il numero di bug.