CI/CD Cosa sono continuous integration e continuous delivery?

Share post

Tempo di lettura: 5 min.
Continuous Integration (CI) e continuous delivery (CD) integrano una cultura, un set di principi e un insieme di pratiche che permettono ai team di sviluppo di rilasciare nuovo codice più frequentemente e in modo sicuro. L’implementazione di questi principi è conosciuta come CI/CD pipeline.

CI/CD è una delle best practices dei gruppi devops per le implementazioni. Fa parte anche della metodologia agile; permette agli sviluppatori di concentrarsi sul raggiungimento degli obiettivi di business, qualità del codice e sicurezza in quanto gli step del deployment sono automatizzati.

Definizione di CI/CD

Continuous integration è una filosofia di coding. È un insieme di pratiche che guidano i team di sviluppo nell’implementazione di piccoli cambiamenti e controlli di codice per il versionamento frequente dei repository. La maggior parte delle applicazioni moderne richiede uno sviluppo su differenti piattaforme; il team ha bisogno di un meccanismo per integrare e validare i cambiamenti.
L’obiettivo della CI è stabilire un metodo consistente e automatico per costruire, “impacchettare” e testare le applicazioni. Se c’è consistenza nel processo di integrazione, i team sono più propensi a rilasciare codice più frequentemente; il che porta a una maggior collaborazione e a una superiore qualità del codice.

Continuous delivery interviene nel momento in cui termina la continuous integration. CD automatizza il delivery delle applicazioni in ambienti e infrastrutture definite. La maggior parte dei team lavora in una molteplicità di ambienti oltre a quello di produzione, come ad esempio l’ambiente di sviluppo o di test; la CD assicura un metodo di aggiornamento automatico di ciascuno di questi ambienti

I tool di CI/CD aiutano lo store di parametri legati all’ambiente in cui si opera. L’automazione CI/CD esegue quindi ogni chiamata a web-server, database, o altri servizi che necessitano di restart o di seguire particolari procedure una volta deployato il nuovo codice.

Continuous integration e continuous delivery richiedono test continui in quanto l’obiettivo è quello di consegnare all’utente finale applicazioni e codice di qualità. Testing continuo è spesso implementato come set di regressioni automatiche, performance, e altri test che sono eseguiti nella pipeline CI/CD.

Una buona pratica di CI/CD ha l’opzione di implementare deployment continuo laddove gli aggiornamenti alle applicazioni attraversano la pipeline CI/CD e vengono deployati direttamente in ambienti di produzione. I team che praticano continuous delivery solitamente rilasciano in produzione giornalmente, o addirittura su schedulazione oraria; ma nonostante ciò la continuous delivery non è sempre la soluzione ottimale per ogni applicazione di business.

In che modo la continuous integration migliora la collaborazione e la qualità

La continuous integration è una filosofia di sviluppo supportata da processi meccanici e da alcune automazioni. Quando si lavora in CI, gli sviluppatori inseriscono frequentemente il proprio codice nel repository di versioning; la maggior parte dei team ha uno standard minimo di commit del codice almeno giornaliero. La logica alla base di ciò è che è più facile identificare difetti e altri problemi di qualità del software su differenziali di codice più piccoli piuttosto che su quelli più grandi sviluppati in un lungo periodo di tempo. Inoltre, quando gli sviluppatori lavorano su cicli di commit più brevi, è meno probabile che più sviluppatori modifichino lo stesso codice e richiedano merge durante il commit.

I team che implementano continuous integration spesso iniziano con la configurazione del controllo di versione e le definizioni di pratica. Anche se il check-in del codice si esegue frequentemente, le funzionalità e le correzioni si implementano su intervalli di tempo sia brevi che lunghi. I team di sviluppo che praticano CI utilizzano diverse tecniche per controllare quali funzioni e codice sono pronti per la produzione.

Flag di funzionalità

Molti team utilizzano flag di funzionalità, un meccanismo di configurazione per attivare o disattivare funzionalità e codice in fase di esecuzione. Le funzionalità che sono ancora in fase di sviluppo sono raggruppate da flag di funzionalità nel codice, distribuite con il master branch in produzione e disattivate fino a quando non sono pronte per l’uso. Secondo un recente sondaggio, il 63% dei team che utilizzano flag di funzionalità riporta test migliori e software di qualità superiore. Gli strumenti di segnalazione delle funzionalità come CloudBees Rollout, Optimizely Rollout e LaunchDarkly si integrano con gli strumenti CI/CD e abilitano le configurazioni a livello di funzionalità.

Un’altra tecnica per la gestione delle funzionalità è il branching del controllo versione. Una strategia di branching come Gitflow è selezionata per definire i protocolli su come il nuovo codice viene unito in branch standard per sviluppo, test e produzione. Vengono creati branch di funzionalità aggiuntivi per quelli che richiedono cicli di sviluppo più lunghi. Al termine della funzionalità, gli sviluppatori possono quindi unire le modifiche dai rami delle funzionalità al branch di sviluppo primario. Questo approccio funziona bene, ma può diventare difficile da gestire se ci sono molte funzioni sviluppate contemporaneamente.

Il packaging

Il processo di costruzione si automatizza poi confezionando tutto il software, il database e gli altri componenti. Per esempio, se si sta sviluppando un’applicazione Java, CI impacchetta tutti i file statici del web server come HTML, CSS e JavaScript insieme all’applicazione Java e a qualsiasi script del database.

CI non solo impacchetta tutti i componenti del software e del database, ma l’automazione eseguirà anche test unitari e altri test. Questi test forniscono agli sviluppatori il feedback che le loro modifiche al codice non hanno interrotto nessun test unitario esistente.

La maggior parte degli strumenti CI/CD permettono agli sviluppatori di avviare build on demand, innescati da commit di codice nel repository di controllo di versione, o su una pianificazione definita. I team devono discutere il programma di compilazione che funziona meglio per le dimensioni del team, il numero di commit giornalieri previsti e altre considerazioni applicative. Una buona pratica per assicurare che i commit e le build siano veloci; altrimenti può ostacolare il progresso dei team che cercano di codificare velocemente e di fare commit frequenti.

I test continui vanno oltre l’automazione dei test

I framework di prova automatizzati aiutano gli ingegneri del controllo qualità a definire, eseguire e automatizzare vari tipi di test che possono aiutare i team di sviluppo a sapere se la build di un software passa o fallisce. Essi includono test di funzionalità che vengono sviluppati alla fine di ogni sprint e aggregati in un test di regressione per l’intera applicazione. Questi test di regressione informano poi il team se un cambiamento di codice non ha superato uno o più dei test sviluppati in tutte le aree funzionali dell’applicazione dove c’è copertura di test.

Una buona pratica è quella di consentire e richiedere agli sviluppatori di eseguire tutti o un sottoinsieme di test di regressione nei loro ambienti locali. Questo passo assicura che gli sviluppatori committino il codice al controllo di versione solo dopo che i test di regressione hanno superato i cambiamenti di codice.

I test di regressione sono solo l’inizio. Anche i test delle prestazioni, i test API, l’analisi statica del codice, i test di sicurezza e altre forme di test possono essere automatizzati. La chiave è essere in grado di far scattare questi test sia attraverso la riga di comando, il webhook, o il web service e che essi rispondano con codici di stato di successo o di errore.

Una volta che il test è automatizzato, il test continuo implica che l’automazione sia integrata nella pipeline CI/CD. Alcuni test di unità e funzionalità possono essere integrati in CI che segnalano problemi prima o durante il processo di integrazione. I test che richiedono un ambiente di consegna completo, come i test di prestazione e di sicurezza, sono spesso integrati nel CD ed eseguiti dopo che le costruzioni sono state consegnate agli ambienti di destinazione.