Oggi, per avere successo, le aziende devono ridefinire, e portare a nuovi livelli, l’esperienza d’uso di applicazioni o servizi, migliorandone di continuo la qualità, in termini di prestazioni, connettività, integrazione di nuove funzionalità. A questo proposito è importante fare CI/CD.
Qual è il significato di CI/CD (continuous integration, e continuous delivery)
Con il termine CI/CD ci si riferisce a una pratica di sviluppo software che ha l’obiettivo di accelerare la velocità e frequenza di distribuzione di prodotti e applicazioni digitali, attraverso l’adozione di meccanismi di automazione. Soprattutto in piena trasformazione digitale, come di questi tempi si suol dire, ogni organizzazione diventa una ‘software company’. Ciò significa che per continuare a competere sul mercato e innovare prodotti, applicazioni, servizi, è importante adottare metodologie e strumenti di sviluppo allo stato dell’arte, e sfruttare la tecnologia digitale per costruire, differenziare e personalizzare la propria offerta rispetto a quella della concorrenza.
Il fatto che fornire e distribuire il software rapidamente, in maniera affidabile e sicura, sia una strategia al cuore della trasformazione tecnologica e dell’efficienza organizzativa è una conclusione chiave emergente anche dal rapporto State of DevOps 2019: la ricerca registra infatti continue evidenze che la velocità, la stabilità e la disponibilità del software contribuiscono alle prestazioni organizzative, in cui vengono incluse profittabilità, produttività e soddisfazione dei clienti.
Continuos integration, cos’è e dove si applica
L’integrazione continua è una pratica che serve in contesti nei quali lo sviluppo software avviene mediante un sistema di controllo versione. In ingegneria software la definizione di continuous integration rimanda al concetto di allineamento frequente degli ambienti di lavoro degli sviluppatori con l’ambiente condiviso.
Continuos delivery, cos’è la distribuzione continua
Il concetto di distribuzione continua è relativo al processo che permette che le modifiche al software effettuate da uno sviluppatore vengano testate automaticamente per individuare bug e, quindi, caricate in un repository da cui sono poi distribuite. Questo consente una maggiore comunicazione tra i team di sviluppatori e quelli operativi.
Continuos deployment, la fase conclusiva
Un flusso CI/CD maturo si conclude con il deployment continuo. Il continuos deployment automatizza il rilascio dell’app in produzione. In pratica, grazie a questa fase conclusiva del processo è possibile che le modifiche apportate da uno sviluppatore a un’applicazione diventino attive in pochi miniti, naturalmente dopo aver superato la fase di test automatizzata.
Problemi d’integrazione: cos’è la tecnica CI/CD e perché serve
Spacchettando ed esplicitando l’acronimo CI/CD nei suoi significati, ci si accorge innanzitutto che esso contiene una certa ambiguità, nel senso che “CI” sta per “integrazione continua” (continuous integration) del software, ma “CD” può assumere due distinti significati: uno è “distribuzione continua” e l’altro è “implementazione continua” o, se si preferisce, “deployment continuo” (continuous deployment). Dunque, il termine CI/CD può essere usato per indicare anche momenti e stadi differenti del processo di automazione, all’interno del ciclo di sviluppo software, in un contesto in cui il SDLC (software development life cycle) si configura come un processo sistematico di costruzione e aggiornamento del codice, che punta ad assicurare sempre la massima qualità e correttezza del software sviluppato.
Il modello di sviluppo e distribuzione del software imperniato su CI/CD si propone, in sostanza, di superare i grossi inconvenienti d’integrazione che tipicamente si presentano quando nello sviluppo software si applica un approccio tradizionale, e che vengono spesso evocati come “inferno dell’integrazione” (“integration hell”).
Provando a immaginare lo scenario tradizionale in cui si svolge lo sviluppo software, si può pensare a contesti lavorativi dove ciascuno sviluppatore sta costruendo determinate funzionalità del prodotto o dell’applicazione software, in modo indipendente dagli altri colleghi. Dopo varie settimane il ciclo di sviluppo si conclude, e solo allora le singole build, derivanti dai vari rami di sviluppo, vengono unite e collaudate per funzionare assieme. Succede però che, specie quando l’esigenza è accelerare il processo di rilascio del software in produzione, l’integrazione di tutti questi “feature branches”, ossia rami di nuove funzionalità, finisce per generare bug, difetti, malfunzionamenti, che non erano stati testati ed emersi precedentemente, e ciò, naturalmente, obbliga ad eseguire nuovi test e a prevedere un ulteriore effort d’integrazione.
Come scrive in un articolo l’esperto di sviluppo software Martin Fowler, i feature branch sono una tecnica popolare, utilizzata per isolare tutto il lavoro svolto su una nuova funzionalità, e impedire di fonderla con la base di codice comune dei team fino a quando non è stata completata. Tuttavia, chiarisce Fowler, questo isolamento impedisce di individuare in anticipo i problemi.
Cos’è una pipeline CI/CD
La tecnica di sviluppo CI/CD, come accennato, consente ai team di sviluppo di evitare di avventurarsi in complessi processi d’integrazione del codice, che possono anche protrarsi in maniera indefinita. Attraverso CI/CD tale processo d’integrazione viene infatti automatizzato, tramite la pratica di integrazione continua (CI), e questa automazione viene poi estesa, dall’ambiente di sviluppo e test, a quello di produzione, implementando nel SDLC gli stadi di distribuzione continua e deployment continuo (CD). Questo flusso di operazioni automatizzate prende il nome di pipeline CI/CD.
Una pipeline CI/CD costituisce la struttura portante di un moderno ambiente DevOps, perché, automatizza le fasi di creazione (build), testing e deployment del codice di cui sono fatti prodotti, applicazioni e servizi digitali, e colma il tradizionale divario esistente tra i team del reparto sviluppo (Dev) e del reparto operation (Ops), facendoli lavorare come squadre sinergiche, allineate sulla condivisione di metodi, principi e responsabilità di sviluppo. In tal modo, la pratica CI/CD, all’interno del paradigma DevOps, consente di aumentare la velocità e frequenza di rilascio del software, contenendo i costi, e al contempo mantenendo gli imprescindibili requisiti di qualità e affidabilità del software che oggi il mercato richiede.
Per realizzare una pipeline CI/CD si possono adottare, installare e utilizzare varie tipologie di strumenti d’automazione, controllo, monitoraggio, in molti casi di natura open source, in grado di presidiare tutte le fasi fondamentali del ciclo di sviluppo (build, test, deploy).
Integrare e distribuire frequentemente
Il termine integrazione continua (CI), ricorda Fowler, è un concetto originato con l’ideazione della metodologia di sviluppo software nota come ‘Extreme Programming’ (XP), che è stata creata principalmente dal programmatore Kent Beck, e ha rappresentato uno dei primi metodi di sviluppo Agile, imperniato quindi su processi iterativi, cicli brevi e rilasci frequenti.
Partendo da questi criteri, nella pratica di integrazione continua, i membri di una squadra di sviluppo del progetto condividono e integrano il proprio lavoro frequentemente: in altre parole, tutte le varie modifiche apportate dal team di sviluppatori al codice di un’applicazione vengono riunite e integrate, anche più di una volta al giorno, all’interno di un singolo repository, condiviso e centralizzato, che contiene la base di codice.
Ciascuna integrazione viene verificata attraverso la creazione automatica di una build (fase di build), quindi una versione del programma contenente tutte le modifiche, che passa poi al collaudo mediante l’esecuzione di una serie di test automatizzati, che permettono subito d’individuare eventuali errori d’integrazione e malfunzionamenti, evitando che si propaghino negli stadi successivi del ciclo di sviluppo. Nella metodologia di integrazione continua, tutti gli sviluppatori sono responsabilizzati fin dal principio, a livello individuale e collettivo, nel far in modo che i differenti feature branch integrati nella build possano funzionare senza problemi.
La fase di distribuzione continua (CD) estende il concetto di integrazione continua, automatizzando la preparazione del codice per il rilascio in produzione. In sostanza, il codice applicativo, con tutte le integrazioni e aggiornamenti, dopo aver superato lo stadio di build passa automaticamente in un ambiente di staging, in cui viene replicato lo stack di produzione, e dove il codice è sottoposto in automatico a ulteriori test d’integrazione, test funzionali e test di carico. Il risultato della fase di CD è l’ottenimento di una build sempre pronta per il deployment in produzione, chiamata release candidate (RC).
La fase finale, nella pipeline CI/CD, è il continuous deployment, in cui viene automatizzato anche il processo decisionale umano che controlla la release candidate, la convalida e ne autorizza il rilascio in produzione.
Strumenti di automazione CI/CD
Per ottenere i massimi benefici in termini di accelerazione del ciclo di sviluppo, una pipeline CI/CD, come accennato, può essere automatizzata attraverso l’implementazione nell’ambiente IT di svariati tool, indirizzati a creare automazione nei differenti stadi della pipeline. Ad esempio, per tenere sotto controllo tutti i cambiamenti apportati dai diversi sviluppatori alla base di codice condivisa nel repository centralizzato si può usare uno strumento di controllo versione come il software Git, ideato per essere in grado di gestire sia piccoli progetti, sia iniziative di sviluppo di grandi dimensioni.
Quando, invece, l’esigenza è automatizzare tutte le operazioni che concorrono a costruzione delle build, testing, distribuzione e deployment del codice, lo strumento principe solitamente utilizzato è il server di automazione open source Jenkins. Per gestire il testing automatizzato esistono framework come Selenium, mentre per automatizzare e standardizzare il deployment delle configurazioni dei vari ambienti secondo il paradigma IaC (infrastructure as code) sono disponibili vari tool open source, tra cui Terraform, Ansible, Puppet, Chef, Salt.
