Vediamo insieme i concetti di Continuous Integration, Delivery e Deployment, fondamentali per fare DevOps, SRE o lavorare secondo la metodologia 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.
Qual è la differenza tra Continuous Integration, Delivery e Deployment?
Per potersi districare nella scelta di strategie e strumenti è 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:
Cosa si intende per Continuous Integration?
Per Continous Integration (CI) - o integrazione continua - 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.
Questo approccio consente agli sviluppatori di 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.
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. Sarà inoltre necessario fornirsi di un tool di Continuous Integration capace di monitorare il repository ed eseguire i test automaticamente ad ogni commit pushato sul repository. Infine, 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.
Cos’è la Continuous Delivery?
La Continuous Delivery (CD) - o distribuzione continua - è 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.
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.
Cos’è 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 test di qualità che vengono eseguiti automaticamente, 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à.
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.
A questo punto dell’articolo, dovresti avere chiara la distinzione tra Continous Integration, Delivery e Deployment. Se ti interessa una definizione più sintetica, potresti trovare utile il Glossario della CNCF, un progetto della community al quale SparkFabrik partecipa. Ma ora andiamo avanti, nel prossimo paragrafo si parla di strumenti.
Come scegliere gli strumenti di CI/CD?
La scelta dei tool dipende da numerose variabili, soprattutto per quanto riguarda la fase di Continuous Delivery. La scelta di uno strumento piuttosto che un altro dipenderà dalla expertise che il team ha con i vari strumenti, dalle funzioni peculiari messe a disposizione da ognuno di essi, dall'ambiente di esecuzione dei processi di CI/CD e dalla strategia di deployment che si vuole mettere in atto.
In generale, per i team può essere utile considerare l'utilizzo di strumenti di CI/CD forniti da diversi provider. I principali fornitori di cloud pubblico offrono soluzioni CI/CD, così come Atlassian Bamboo, GitLab, CircleCI e molti altri.
Vediamo qualche esempio dei più noti strumenti open source per CI/CD:
- Argoflow: permette di eseguire pipeline CI/CD in modo nativo su Kubernetes.
- Jenkins: il server di automazione installabile on-premise o in cloud, progettato per gestire ogni aspetto CI, grazie alla vasta gamma di plug-in.
- Tekton Pipelines: un framework di CI/CD per piattaforme Kubernetes, che fornisce un'esperienza standard Cloud Native per CI/CD con container.
- GoCD: un server CI/CD focalizzato sulla modellazione e la visualizzazione.
- Spinnaker: una piattaforma di Continuous Deployment per ambienti multi cloud.
- Screwdriver: una piattaforma di creazione per il Continuous Deployment.
- Concourse: una risorsa continua open source.
Al di là dei tool specifici, bisogna considerare che anche altri strumenti, sebbene non siano strettamente strumenti CI/CD, sono spesso presenti in molti flussi di lavoro CI/CD, come ad esempio:
- strumenti DevOps;
- strumenti di CD per Kubernetes (Argo CD, Flux, Argo);
- strumenti di controllo del deployment (Keptn, OpenKruise);
- tool per l'automazione della configurazione (Puppet, Ansible e Chef);
- runtime dei container (Docker);
- tool per l'orchestrazione dei container (Kubernetes).
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.
Scritto daSparkFabrik Team
