Che cos'è l'integrazione continua/fornitura continua (CI/CD)?

Una caratteristica fondamentale della pipeline CI/CD è l'uso dell'automazione per contribuire garantire la qualità del codice. Man mano che i cambiamenti software avanzano nella pipeline, i test automatizzati identificano prima dipendenze e altri problemi, inviano modifiche al codice a diversi ambienti e consegnano applicazioni agli ambienti di produzione.

In questo caso, il ruolo dell'automazione è quello di eseguire il controllo qualità, valutando tutto, dalle prestazioni all'utilizzo dell'application programming interface (API) e alla sicurezza. Questo processo aiuta a garantire che le modifiche apportate da tutti i membri del team siano integrate in modo completo ed eseguite come previsto.

La capacità di automatizzare diverse fasi della pipeline CI/CD aiuta i team di sviluppo a migliorare la qualità, lavorare più velocemente e migliorare altre metriche DevOps.

Mentre la pipeline CI/CD si riferisce ai workflow DevOps Agile, CI/CD rappresenta le pratiche combinate di integrazione continua e consegna continua.

CI/CD crea un modo più veloce e preciso di combinare il lavoro di persone diverse in un unico prodotto coeso. Negli ambienti DevOps, CI/CD semplifica i processi di codifica, test e distribuzione delle applicazioni. Questo approccio offre ai team un unico repository per memorizzare il lavoro e strumenti di automazione per combinare e testare il codice, contribuendo a garantirne il funzionamento coerente.

La pipeline CI/CD consente ai team DevOps di scrivere codice, integrarlo, eseguire test, fornire versioni e implementare modifiche al software in modo collaborativo e in tempo reale. Sebbene l'automazione delle versioni software, dai test iniziali fino alla distribuzione finale, sia un beneficio significativo della pipeline CI/CD, altri benefici includono:

• Tempi di implementazione ridotti: i test automatizzati rendono il processo di sviluppo più efficiente, riducendo la durata del processo di consegna del software. Inoltre, la distribuzione continua e il provisioning automatizzato fanno sì che le modifiche di uno sviluppatore a un'applicazione cloud siano attive entro pochi minuti dalla scrittura.

• Costi ridotti: sviluppo, test e produzione rapidi (facilitati dall'automazione) significano meno tempo dedicato allo sviluppo. Questo processo comporta costi ridotti rispetto allo sviluppo software tradizionale.

• Cicli di feedback continui: la pipeline CI/CD rappresenta un ciclo continuo: build, test, distribuzione. I cicli di feedback permettono agli sviluppatori di agire rapidamente e migliorare il codice ogni volta che tale codice viene testato.

• Rilevamento precoce degli errori: nell'integrazione continua, i test sono automatizzati per ogni versione del codice creata per cercare problemi di integrazione. Questi problemi sono più facili da risolvere quanto prima si presentano nella pipeline.

• Tempi di inattività ridotti e maggiore affidabilità: in caso di fallimenti di distribuzione, bug o problemi di prestazioni, caratteristiche come i rollback automatici riportano un sistema software o un'app a uno stato stabile precedente. Questa funzione riduce al minimo i tempi di inattività e migliora l'affidabilità del servizio.

• Miglioramento della collaborazione tra team e integrazione dei sistemi: tutti nel team possono cambiare codice, rispondere ai feedback e dare una risposta rapida a qualsiasi problema.

La pipeline CI/CD è composta da 3 metodologie connesse:

• Integrazione continua
• Fornitura continua
• Distribuzione continua

Il processo CI/CD inizia con l'integrazione continua (CI), in cui gli sviluppatori inviano il loro codice a repository centrali gestiti dai sistemi di controllo versione (VCS). La CI consente agli sviluppatori di lavorare autonomamente, creando il proprio "ramo" di codifica per implementare piccole modifiche.

Mentre lo sviluppatore lavora, può scattare istantanee del codice sorgente, normalmente all'interno di uno strumento di versioning come Git. Lo sviluppatore è quindi libero di lavorare su nuove caratteristiche; se si verifica un problema, Git può riportare rapidamente la base di codice allo stato precedente.

Il lavoro degli individui viene poi trasferito in un sistema automatizzato che utilizza script per sviluppare e testare le modifiche al codice. Dopo la fase di compilazione automatizzata, un server CI compila le modifiche al codice sorgente nel codice del ramo principale o "trunk" del repository del codice sorgente condiviso.

Invece di scrivere il codice autonomamente e inviarlo al ramo principale del codice una volta al mese, il che può portare a un lavoro gravoso per la correzione dei bug e a uno scarso controllo delle versioni, il processo di sviluppo CI/CD consente ai team di inviare modifiche al codice più frequentemente. Questo test continuo consente correzioni di bug più rapide, aiuta a garantire la funzionalità e, in ultima analisi, porta a una migliore collaborazione e qualità del software.

Il passaggio successivo della pipeline è la consegna continua (CD), che inserisce le modifiche convalidate al codice apportate in un'integrazione continua in ambienti o repository di codice selezionati, come GitHub. Qui, il team delle operazioni può distribuirli in un ambiente di produzione live.

Il software e le API vengono testati e gli errori risolti grazie a un processo automatizzato. Nell'ultimo passaggio del processo di CD, il team DevOps riceve una notifica sull'ultima build e la invia manualmente alla fase di distribuzione.

L'obiettivo della fase della pipeline di consegna continua è quello di implementare nuovo codice con il minimo impegno, ma consentendo comunque un livello di supervisione umana.

Il CD nel processo CI/CD indica anche la distribuzione continua. La distribuzione continua implementa automaticamente le modifiche del codice agli utenti finali dopo aver superato una serie di test predefiniti, come i test di integrazione che testano il codice in un ambiente di emulazione per contribuire a garantire l'integrità del codice.

La consegna continua e la distribuzione continua si occupano di automatizzare ulteriormente la pipeline rispetto alla CI e sono spesso usate in modo intercambiabile.

La differenza tra consegna e implementazione continui risiede nel livello di automazione utilizzato nelle versioni del software o dell'app. Nella distribuzione continua, il codice si sposta automaticamente in ambienti simili a quelli di produzione per ulteriori test e controlli della qualità, come la valutazione dei rischi e l'identificazione delle vulnerabilità del codice sorgente. Dopo il superamento dei test, è necessario l'intervento umano per spostare il codice in produzione.

Nella distribuzione continua, l'automazione ha un ruolo ancora maggiore. Dopo che il codice supera i test, la distribuzione in produzione avviene automaticamente e l'approvazione umana non è necessaria.

Il modo in cui un'organizzazione applica la pipeline CI/CD e decide se utilizzare la consegna continua o la distribuzione continua dipende dalle sue esigenze aziendali. La distribuzione continua è ideale per i team DevOps con un ciclo di sviluppo veloce, come quelli che sviluppano siti di e-commerce e piattaforme software come servizio (SaaS).

La distribuzione continua supporta il processo di rilascio del software permettendo ai team di rilasciare software nuovo o aggiornato spesso e il più rapidamente possibile. In genere, poiché le modifiche vengono distribuite automaticamente al pubblico, questo tipo di pipeline di distribuzione continua è utilizzato solo dai team DevOps che hanno un processo comprovato.

Per i team che non devono necessariamente rilasciare aggiornamenti in modo molto frequente nel loro workflow, come per chi sviluppa applicazioni sanitarie, normalmente la consegna continua è l'opzione preferita. È più lento, ma offre un ulteriore livello di supervisione per garantire la funzionalità agli utenti finali.

Per un'analisi più approfondita delle differenze tra consegna continua e distribuzione continua guarda questo video.

Una pipeline di machine learning è una serie di passaggi di trattamento e modellazione dei dati interconnessi progettata per automatizzare, standardizzare e semplificare il processo di costruzione, addestramento, valutazione e implementazione di modelli di machine learning.

Le pipeline di machine learning sono una componente essenziale nello sviluppo e nella produzione di sistemi di  apprendimento automatico (ML). Inoltre, sono diventati sempre più importanti grazie alla crescita dei big data e dell'intelligenza artificiale (AI).

Secondo Kings Research, la dimensione del mercato globale del machine learning è stata valutata 26,06 miliardi di USD nel 2023 e si prevede che crescerà da 35,44 miliardi di USD nel 2024 a 328,89 miliardi di USD entro il 2031, con un CAGR del 37,47% durante il periodo di previsione.¹

Le pipeline di machine learning si integrano con le pratiche DevOps per abilitare CI/CD dei modelli di machine learning. Questa integrazione è denominata operazioni di machine learning (MLOps) e aiuta i team di data science a gestire efficacemente la complessità della gestione dell'orchestrazione ML.

Dal codice sorgente alla produzione, queste fasi comprendono il ciclo di vita e il workflow della pipeline CI/CD:

• Creazione
• Prova
• Distribuzione
• Implementazione

Questa fase fa parte del processo di integrazione continua e prevede la creazione e la compilazione di codice. I team si basano sul codice sorgente in modo collaborativo e integrano il nuovo codice determinando rapidamente eventuali problemi o conflitti.

In questa fase, i team testano il codice. I test automatizzati avvengono sia nella consegna continua che nella distribuzione continua. Questi ambienti di test possono includere test di integrazione, test unitari e test di regressione.

In questo caso, un codice approvato viene inviato a un ambiente di produzione. Questa fase è automatizzata nella distribuzione continua ed è automatizzata nella consegna continua solo dopo l'approvazione dello sviluppatore.

Infine, le modifiche vengono distribuite e il prodotto finale passa in produzione. Nella consegna continua, prodotti o codici vengono inviati a depositi e passano in produzione o distribuzione con approvazione umana. Nella distribuzione continua, questo passaggio è automatizzato.

Nella selezione degli strumenti CI/CD, l'attenzione deve essere rivolta all'ottimizzazione e all'automazione del processo di sviluppo del software. Una pipeline CI/CD efficace utilizza strumenti open source per l'integrazione, il test e la distribuzione. La corretta configurazione del processo CI/CD incide anche sul successo della pipeline di sviluppo del software.

Lo strumento CI/CD open source più comune è Jenkins. Jenkins è un server CI automatizzato scritto in Java utilizzato per automatizzare i passaggi CI/CD e la reportistica. Altri strumenti open source per l'integrazione includono Travis CI e CircleCI.

Oltre agli strumenti open source, tutti i principali fornitori di servizi cloud, Google Cloud, IBM® Cloud, Microsoft Azure e Amazon Web Services (AWS), offrono toolchain, pipeline e integrazioni di strumenti CI/CD basati su cloud.

Gli ambienti di sviluppo integrati (IDE), come GitHub o AWS CodeCommit, aiutano gli sviluppatori a creare, mantenere e tenere traccia dei pacchetti software. Al contempo, piattaforme come GitLab cercano di fornire l'IDE all'interno di una piattaforma completa che includa altri strumenti.

Quando operano in un ambiente cloud, i team DevOps cloud-native utilizzano container come Docker per applicazioni di packaging e spedizione e strumenti di orchestrazione container come Kubernetes. Sebbene Kubernetes non sia specificamente pensato per le pipeline CI/CD, viene utilizzato in molti workflow CI/CD.

La sicurezza CI/CD si concentra su pratiche, processi e tecnologie che implementano e gestiscono misure di sicurezza e conformità lungo tutta la pipeline CI/CD.

In passato, la sicurezza veniva "agganciata" al software alla fine del ciclo di sviluppo. Il progresso delle piattaforme cloud, dei microservizi e dei container è finita per diventare un ostacolo per l'approccio tradizionale allo sviluppo.

La sicurezza potrebbe non tenere il passo con i rilasci rapidi poiché gli sviluppatori hanno adottato pratiche agili e DevOps, stimolando l'evoluzione di DevSecOps, che sta per sviluppo, sicurezza e operazioni. DevSecOps automatizza le pratiche di integrazione degli strumenti di sicurezza man mano che emergono all'interno delle pipeline di integrazione continua (CI) e consegna continua (CD).

Le pratiche DevSecOps includevano i test shift-left e shift-right. Il test shift-left prevede l'integrazione di test di sicurezza e di altre pratiche critiche di sviluppo nelle prime fasi del ciclo di vita dello sviluppo software (SDLC). Il test shift-right prevede il test in fasi successive dello sviluppo, di solito in ambienti di produzione. Questi metodi si completano a vicenda distribuendo la responsabilità dei test all'interno dell'SDLC.