ingranaggi

Vediamo insieme i concetti di Continuous Integration, Delivery e Deployment, fondamentali per fare DevOps, SRE o lavoro Agile.

Produrre applicazioni, oggi, non è un processo univoco. Negli ultimi anni si è vista la nascita di diversi approcci e metodologie di lavoro che possono fare la differenza, trasformando i tradizionali processi manuali per migliorare non solo il time-to-market, ma anche la collaborazione tra team e la qualità generale del prodotto

Per potersi districare nella scelta di strategie e strumenti, però, è necessario capire a cosa si riferiscono i termini Continuous Integration, Continuous Delivery e Continuous Deployment, definendo i loro confini e le differenze tra essi. L’applicazione di questi concetti alle pipeline di lavoro aziendali, infatti, è fondamentale per lavorare in DevOps, in modo Agile o per un approccio SRE efficace (Site Reliability Engineering), in quanto introducono i necessari step di automazione per adottare queste moderne metodologie di lavoro.

Prima di entrare nel vivo vuoi leggere di più su CI/CD e DevOps? Ecco un paio di risorse utili:

Continuous Integration, Delivery e Deployment

 

Conosci già le potenzialità della Site Reliability Engineering?  Scarica la guida e dai una marcia in più alle tue applicazioni!

 

Continuous Integration

Per Continous Integration (CI) si intende una pratica di sviluppo software in cui tutti gli sviluppatori effettuano le modifiche al codice portandole in un repository centralizzato e condiviso come, per esempio, Git. Ogni modifica (commit o pull request) attiva una procedura automatica di build e test che fornisce un feedback immediato allo sviluppatore riguardo alla sua implementazione. 

In questo modo gli sviluppatori possono integrare piccole porzioni di codice finito nell’applicazione senza dover aspettare l’integrazione alla fine del progetto. Proprio a questo si riferisce il nome, alla possibilità di avere integrazioni rapide e frequenti grazie ad una rilevazione dei problemi rapida ed efficace.

continuous integration

Se portata in azienda, come per ogni cambiamento, questa pratica richiede un effort, soprattutto inizialmente. In particolare, il team dovrà scrivere test automatizzati per ogni nuova feature, bug fix o miglioramento e sarà necessario fornirsi di un tool di Continuous Integration capace di monitorare il repository e avviare automaticamente i test ad ogni commit pushato sul repository. Inoltre, perché l'approccio diventi davvero efficiente, è necessario che ci sia un'alta frequenza di commit nel repository: senza questo requisito, non si potrà davvero arrivare ai risultati sperati. 

Questo effort, però, viene ripagato prendendo in considerazione i benefici che la Continuous Integration può portare: la presenza dei un server di CI, infatti, permette di ridurre drasticamente i costi della fase di testing e lascia i team liberi di usare il loro tempo per concentrarsi sulla qualità del prodotto

Inoltre, l'automatizzazione del processo di testing è il primo stadio di automazione della QA (Quality Assurance) e riduce sensibilmente il numero di bug che raggiungono lo stadio di produzione captandoli per tempo. 

Continuous Delivery

La Continuous Delivery (CD) è lo step successivo alla CI, un approccio di ingegneria del software che predilige la produzione in cicli brevi, che garantiscano la possibilità di rilasciare il software in modo affidabile in qualsiasi momento

La Continuous Delivery, infatti, non vede le fasi di sviluppo, rilascio, feedback e gestione della qualità come irrimediabilmente separate, ma come un continuo ciclo applicabile ad ogni cambiamento che, come vuole la Continuous Integration, sarà piccolo, riceverà feedback istantaneo e verrà rilasciato spesso. 

Nella Continuous Delivery si prediligono quindi modifiche del software atomiche (piccole) e meno rischiose, rilasciate continuamente anziché aspettare un unico rilascio simultaneo. In breve, se la CI si occupa di automatizzare il processo di build, la Continuous Delivery automatizza il rilascio di codice già testato in uno staging environment, pronto per essere rilasciato in produzione: per questo è importante aver implementato la CI, prima di passare alla Continuous Delivery.

continuous delivery

Di cosa avrai bisogno per fare Continuous Delivery, quindi? 

Come già accennato, è importante implementare processi di Continuous Integration e che la tua codebase sia adeguatamente testata. Inoltre è necessario che il processo di rilascio sia automatizzato: il trigger rimarrà manuale, ma una volta avviato il processo non dovrebbe necessitare di intervento umano. Infine, per evitare che il cliente abbia problemi in produzione sarebbe bene che i team facciano uso di feature flag, una tecnica di sviluppo che permette di attivare e disattivare le funzioni durante il runtime senza dover rilasciare nuovo codice. 

Grazie a questa pratica, rilasciare software sarà molto più facile: rilasciando più spesso si eliminerà la complessità di preparare per giorni grossi rilasci e si otterrà feedback da parte del cliente molto più spesso e velocemente.

Continuous Deployment

La Continuous Deployment (CD) è l’ultimo passo verso la completa automazione dei processi di sviluppo, andando oltre la Continuous Delivery grazie al rilascio automatico di ogni modifica in produzione una volta che questa ha superato tutte le fasi di testing del codice. 

Questa pratica ovviamente si affida molto alla presenza di automazione di test di qualità, in quanto l’unico ostacolo che potrebbe esserci per il rilascio del codice in produzione è un test fallito. In questo modo il codice, potenzialmente, può essere rilasciato in produzione anche pochi minuti dopo che è stato scritto, togliendo dalle spalle degli sviluppatori tutti i task manuali di delivery e permettendo loro di concentrarsi solo sulla scrittura di codice di qualità.

continuous-deployment

Per poter sfruttare i benefici che la CD può portare in azienda, come detto in precedenza, dovrai assicurarti che le suite di testing siano all’altezza: ricorda sempre che dalla qualità dei test dipenderà la qualità del prodotto rilasciato

È importante ricordare anche che in un contesto di Continuous Deployment i tuoi processi di documentazione dovranno essere in grado di stare al passo con quelli di rilascio. Inoltre a questo stadio i feature flag diventano necessari al rilascio di cambiamenti significativi dell’applicazione, in modo da poter coordinare al meglio il team di sviluppo con gli altri dipartimenti.

Una volta integrato il Continuous Deployment nelle tue pipeline, però, sarai in grado di sviluppare più velocemente e rilasciare in produzione in modo meno rischioso; rilasciando un piccolo cambiamento alla volta, infatti, sarà più facile rimediare agli errori. Infine, ma non meno importante, questo modo di lavorare porterà al cliente un flusso continuo di migliorie e un prodotto la cui qualità aumenterà di giorno in giorno, senza necessità di aspettare settimane o mesi per un update.

Come arrivare dalla Continuous Integration al Continuous Deployment?

Introdurre novità nelle modalità di lavoro aziendali non è mai facile: il rischio di sovvertire gli equilibri di lavoro è sempre presente, ma con delle accortezze è possibile modernizzare gli approcci lavorativi in modo efficace.

Abbiamo in precedenza già parlato di come introdurre la cultura DevOps in azienda evitando frizioni, ma come applicare i fondamentali di questa metodologia di lavoro?

Il modo più semplice per introdurre le pipeline CI/CD in azienda sarebbe, ovviamente, partire da un progetto completamente nuovo. Iniziare automatizzando il rilascio della versione alpha dell’applicazione ad uno stage di produzione, senza utenti attivi, e rinvigorire la tua suite di test man mano che sviluppi la tua applicazione è infatti il modo più semplice di collaudare la pipeline CI/CD per intero. 

Nella realtà, però, è probabile che dovrai applicare le tecniche di CI/CD anche a progetti già avviati: in questo caso, è meglio non correre. Implementare fin da subito un complesso sistema di test automatizzati che vadano a rivoluzionare il processo end-to-end non solo non lascia tempo ai team di sviluppo di consolidare ogni fase prima di passare alla successiva, ma rischia anche di trovare gli altri dipartimenti impreparati ad un processo di rilascio con cadenze molto più veloci, a discapito del prodotto.

L’ideale sarebbe iniziare automatizzando i processi di build e il rilascio in un ambiente di staging, in modo da poter gestire i rilasci in produzione manualmente e, così, assicurarti che tutti i team siano coordinati. Già a questo step potrai cominciare a vedere i benefici che Continuous Integration e Delivery possono portare: l’automatizzazione dei processi permetterà al team di non doversi più fermare periodicamente per coordinare un rilascio, risparmiando tempo che potrà essere usato per focalizzarsi sulla qualità del prodotto e, in vista dello step successivo, affinare sempre di più la suite di test. 

Il passo finale è fare Continuous Deployment, ovvero automatizzare anche l’ultimo step della delivery rendendola completamente automatica. Così facendo si elimina ogni step manuale in carico al team DevOps e si può godere di tutti i benefici che l’adozione di queste pratiche può portare, per la tua azienda e per la soddisfazione dei tuoi clienti.

guida SRE