Cos'è CI / CD? Spiegazione dell'integrazione continua e della consegna continua

L'integrazione continua (CI) e la consegna continua (CD) incarnano una cultura, una serie di principi operativi e una raccolta di pratiche che consentono ai team di sviluppo delle applicazioni di fornire modifiche al codice più frequentemente e in modo affidabile. L'implementazione è nota anche come pipeline CI / CD

CI / CD è una delle migliori pratiche da implementare per i team devops. È anche una best practice per la metodologia agile, in quanto consente ai team di sviluppo software di concentrarsi sulla soddisfazione dei requisiti aziendali, sulla qualità del codice e sulla sicurezza poiché i passaggi di distribuzione sono automatizzati.

Definito CI / CD

L'integrazione continua  è una filosofia di codifica e un insieme di pratiche che guidano i team di sviluppo a implementare piccole modifiche e archiviare frequentemente il codice nei repository di controllo delle versioni. Poiché la maggior parte delle applicazioni moderne richiede lo sviluppo di codice in piattaforme e strumenti diversi, il team necessita di un meccanismo per integrare e convalidare le modifiche.

L'obiettivo tecnico di CI è stabilire un modo coerente e automatizzato per creare, creare pacchetti e testare le applicazioni. Con la coerenza nel processo di integrazione in atto, i team hanno maggiori probabilità di eseguire modifiche al codice più frequentemente, il che porta a una migliore collaborazione e qualità del software.

La consegna continua  riprende dove finisce l'integrazione continua. Il CD automatizza la consegna delle applicazioni agli ambienti infrastrutturali selezionati. La maggior parte dei team lavora con più ambienti diversi dalla produzione, come ambienti di sviluppo e test, e il CD garantisce che esista un modo automatizzato per inviare loro le modifiche al codice.

Gli strumenti CI / CD aiutano a memorizzare i parametri specifici dell'ambiente che devono essere impacchettati con ogni consegna. L'automazione CI / CD esegue quindi tutte le chiamate di servizio necessarie a server Web, database e altri servizi che potrebbero dover essere riavviati o seguire altre procedure quando le applicazioni vengono distribuite.

L'integrazione continua e la distribuzione continua richiedono  test continui  perché l'obiettivo è fornire applicazioni e codice di qualità agli utenti. Il test continuo viene spesso implementato come un insieme di regressione automatizzata, prestazioni e altri test eseguiti nella pipeline CI / CD.

Una pratica devops CI / CD matura ha la possibilità di implementare la distribuzione continua in cui le modifiche alle applicazioni vengono eseguite attraverso la pipeline CI / CD e le build in transito vengono distribuite direttamente negli ambienti di produzione. I team che praticano la consegna continua scelgono di distribuire alla produzione su una pianificazione giornaliera o addirittura oraria, sebbene la consegna continua non sia sempre ottimale per ogni applicazione aziendale.  

Video correlato: come distribuire il codice più velocemente con CI / CD

In che modo l'integrazione continua migliora la collaborazione e la qualità

L'integrazione continua è una filosofia di sviluppo supportata dalla meccanica di processo e da un po 'di automazione. Quando si pratica CI, gli sviluppatori inseriscono frequentemente il loro codice nel repository di controllo della versione e la maggior parte dei team ha uno standard minimo di commit del codice almeno ogni giorno. La logica alla base di questo è che è più facile identificare i difetti e altri problemi di qualità del software su differenziali di codice più piccoli piuttosto che su quelli più grandi sviluppati per lunghi periodi di tempo. Inoltre, quando gli sviluppatori lavorano su cicli di commit più brevi, è meno probabile che più sviluppatori modifichino lo stesso codice e richiedano un'unione durante il commit.

I team che implementano l'integrazione continua spesso iniziano con la configurazione del controllo della versione e le definizioni pratiche. Anche se il controllo del codice viene eseguito frequentemente, le funzionalità e le correzioni vengono implementate su intervalli di tempo brevi e più lunghi. I team di sviluppo che praticano l'integrazione continua utilizzano tecniche diverse per controllare quali funzionalità e codice sono pronti per la produzione.

Molti team utilizzano flag di funzionalità , un meccanismo di configurazione per attivare o disattivare funzionalità e codice in fase di esecuzione. Le funzionalità ancora in fase di sviluppo vengono incluse nel codice con flag di funzionalità, distribuite con il ramo master in produzione e disattivate fino a quando non sono pronte per essere utilizzate. Secondo un recente sondaggio, il 63% dei team che utilizzano i flag di funzionalità segnala test migliori e software di qualità superiore. Gli strumenti di segnalazione delle funzionalità come CloudBees Rollout, Optimizely Rollouts 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à è la  ramificazione del controllo della versione . Viene selezionata una strategia di ramificazione come Gitflow per definire i protocolli su come il nuovo codice viene unito ai rami standard per lo sviluppo, il test e la produzione. Vengono creati rami di funzionalità aggiuntivi per quelli che richiederanno cicli di sviluppo più lunghi. Quando la funzionalità è completa, gli sviluppatori possono unire le modifiche dai rami delle funzionalità al ramo di sviluppo principale. Questo approccio funziona bene, ma può diventare difficile da gestire se ci sono molte funzionalità sviluppate contemporaneamente.

Il processo di compilazione stesso viene quindi automatizzato impacchettando tutto il software, il database e altri componenti. Ad esempio, se si sta sviluppando un'applicazione Java, CI creerebbe un pacchetto di tutti i file del server Web statico come HTML, CSS e JavaScript insieme all'applicazione Java e agli script di database.

CI non solo impacchetta tutto il software ei componenti del database, ma l'automazione eseguirà anche unit test e altri test. Questo test fornisce feedback agli sviluppatori sul fatto che le modifiche al codice non hanno interrotto alcun test unitario esistente.

La maggior parte degli strumenti CI / CD consente agli sviluppatori di avviare build su richiesta, attivate da commit del codice nel repository di controllo della versione o in base a una pianificazione definita. I team devono discutere la pianificazione della compilazione che funziona meglio per le dimensioni del team, il numero di commit giornalieri previsti e altre considerazioni sull'applicazione. Una best practice per garantire che i commit e le build siano veloci, altrimenti potrebbe impedire il progresso dei team che tentano di codificare velocemente e si impegnano frequentemente.

I test continui vanno oltre l'automazione dei test

I framework di test 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 una build software riesce o non riesce. 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 quindi il team se una modifica del codice non ha superato uno o più test sviluppati in tutte le aree funzionali dell'applicazione in cui è presente la copertura dei test.

Una best practice consiste nell'abilitare e richiedere agli sviluppatori di eseguire tutti o un sottoinsieme di test di regressione nei loro ambienti locali. Questo passaggio garantisce che gli sviluppatori inviino il codice al controllo della versione solo dopo che i test di regressione hanno trasmesso le modifiche al codice.

I test di regressione sono solo l'inizio. Anche il test delle prestazioni, il test API, l'analisi statica del codice, il test della sicurezza e altri moduli di test possono essere automatizzati. La chiave è essere in grado di attivare questi test tramite riga di comando, webhook o servizio Web e che rispondano con codici di stato positivi o negativi.

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 segnala i problemi prima o durante il processo di integrazione. I test che richiedono un ambiente di consegna completo come i test di prestazioni e sicurezza sono spesso integrati nel CD ed eseguiti dopo che le build sono state consegnate agli ambienti di destinazione.

La pipeline CD automatizza le modifiche a più ambienti

La distribuzione continua è l'automazione che spinge le applicazioni negli ambienti di distribuzione. La maggior parte dei team di sviluppo in genere dispone di uno o più ambienti di sviluppo e test in cui le modifiche alle applicazioni vengono organizzate per il test e la revisione. Uno strumento CI / CD come Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo o Travis CI viene utilizzato per automatizzare i passaggi e fornire rapporti.

Una tipica pipeline CD ha fasi di compilazione, test e distribuzione. Le pipeline più sofisticate includono molti di questi passaggi:

  • Estrazione del codice dal controllo della versione ed esecuzione di una build.
  • Esecuzione di tutti i passaggi dell'infrastruttura richiesti che sono automatizzati come codice per alzarsi o abbattere l'infrastruttura cloud.
  • Spostamento del codice nell'ambiente di elaborazione di destinazione.
  • Gestire le variabili d'ambiente e configurarle per l'ambiente di destinazione.
  • Invio di componenti dell'applicazione ai servizi appropriati, come server Web, servizi API e servizi di database.
  • Esecuzione dei passaggi necessari per riavviare i servizi o chiamare gli endpoint del servizio necessari per i nuovi push di codice.
  • Esecuzione di test continui e ambienti di rollback se i test falliscono.
  • Fornire dati di registro e avvisi sullo stato della consegna.

Ad esempio, gli utenti di Jenkins definiscono le proprie pipeline in un file Jenkins che descrive diverse fasi come compilazione, test e distribuzione. Variabili d'ambiente, opzioni, chiavi segrete, certificazioni e altri parametri vengono dichiarati nel file e quindi referenziati in più fasi. La sezione post gestisce le condizioni di errore e le notifiche.  

Un CD più sofisticato può avere altri passaggi come eseguire la sincronizzazione dei dati, archiviare le risorse di informazioni o eseguire l'applicazione di patch e la libreria. Gli strumenti CI / CD in genere supportano un mercato di plug-in. Ad esempio, Jenkins elenca più di 1.500 plug-in che supportano l'integrazione con piattaforme di terze parti, interfaccia utente, amministrazione, gestione del codice sorgente e gestione build.

Una volta selezionato uno strumento CI / CD, i team di sviluppo devono assicurarsi che tutte le variabili di ambiente siano configurate all'esterno dell'applicazione. Gli strumenti CI / CD consentono di impostare queste variabili, mascherare variabili come password e chiavi account e configurarle al momento della distribuzione per l'ambiente di destinazione.

Gli strumenti CD forniscono anche funzioni di dashboard e reporting. Se le build o le consegne falliscono, avvisano gli sviluppatori con informazioni sui guasti. Si integrano con il controllo della versione e gli strumenti agili, quindi possono essere utilizzati per cercare quali modifiche al codice e storie utente hanno costituito una build.

Implementazione di pipeline CI / CD con Kubernetes e architetture serverless 

Molti team che gestiscono pipeline CI / CD in ambienti cloud utilizzano anche contenitori come Docker e sistemi di orchestrazione come Kubernetes. I contenitori consentono l'imballaggio e le applicazioni di spedizione in modi standard e portatili. I contenitori semplificano la scalabilità verticale o l'abbattimento degli ambienti con carichi di lavoro variabili.

Esistono molti approcci per utilizzare contemporaneamente contenitori, infrastruttura come codice e pipeline CI / CD. Puoi esplorare le opzioni lavorando attraverso esercitazioni come Kubernetes con Jenkins o Kubernetes con Azure DevOps.

Le architetture di elaborazione serverless rappresentano un'altra strada per la distribuzione e la scalabilità delle applicazioni. In un ambiente serverless, l'infrastruttura è completamente gestita dal provider di servizi cloud e l'applicazione consuma le risorse secondo necessità in base alla sua configurazione. Su AWS, ad esempio, le applicazioni serverless vengono eseguite come funzioni Lambda e le distribuzioni possono essere integrate in una pipeline CI / CD di Jenkins con un plug-in. 

CI / CD consente distribuzioni di codice più frequenti

Per ricapitolare, CI confeziona e testa le build del software e avvisa gli sviluppatori se le loro modifiche non hanno superato gli unit test. CD è l'automazione che fornisce modifiche all'infrastruttura ed esegue test aggiuntivi. 

Le pipeline CI / CD sono progettate per le aziende che desiderano migliorare frequentemente le applicazioni e richiedono un processo di consegna affidabile. Lo sforzo aggiuntivo per standardizzare le build, sviluppare test e automatizzare le distribuzioni è il processo di produzione per la distribuzione delle modifiche al codice. Una volta installato, consente ai team di concentrarsi sul processo di miglioramento delle applicazioni e meno sui dettagli del sistema per fornirle agli ambienti di elaborazione.

CI / CD è una best practice devops perché affronta il disallineamento tra gli sviluppatori che desiderano eseguire il push delle modifiche frequentemente, con operazioni che desiderano applicazioni stabili. Con l'automazione in atto, gli sviluppatori possono inviare modifiche più frequentemente. I team operativi vedono una maggiore stabilità perché gli ambienti hanno configurazioni standard, ci sono test continui nel processo di consegna, le variabili di ambiente sono separate dall'applicazione e le procedure di rollback sono automatizzate.

L'impatto dell'implementazione di pipeline CI / CD può essere misurato come un indicatore di prestazioni chiave (KPI) devops. I KPI come la frequenza di distribuzione, il lead time di modifica e il tempo medio di ripristino (MTTR) da un incidente sono spesso migliorati quando viene implementato CI / CD con test continui. Tuttavia, CI / CD è solo un processo che può guidare questi miglioramenti e ci sono altri prerequisiti per migliorare le frequenze di distribuzione.

Iniziare con CI / CD richiede che i team di sviluppo ei team operativi collaborino su tecnologie, pratiche e priorità. I team devono sviluppare il consenso sui giusti approcci per la loro attività e le loro tecnologie in modo che una volta che CI / CD è in atto, il team è a bordo con le seguenti pratiche in modo coerente.