Il principale obiettivo delle pratiche Continuous Integration e Continuous Deployment (CI/CD), ossia integrazione continua e distribuzione/deployment continui del software, è consentire all’organizzazione IT di un’impresa di aumentare velocità e frequenza di pubblicazione e implementazione delle release, senza per questo scendere a compromessi in merito a sicurezza e qualità del codice sviluppato.
Le pratiche CI/CD rappresentano una componente fondamentale della moderna metodologia di sviluppo e distribuzione del codice nota come DevOps. Il paradigma DevOps ha lo scopo di innovare i tradizionali modelli e cicli di progettazione e distribuzione del codice, minimizzando il time-to-market con cui un’azienda riesce a pubblicare aggiornamenti, o nuove versioni, dei propri prodotti, applicazioni, servizi digitali. La riduzione del time-to-market è ottenibile, essenzialmente, eliminando il più possibile i processi manuali di manipolazione degli artefatti e del codice, instaurando nuovi metodi di lavoro, e adottando strumenti di razionalizzazione e automazione delle fasi di creazione, test, Deployment, deployment del software: i tool CI/CD appunto.
Nel modello DevOps, gli strumenti CI/CD vanno ad affiancarsi ad altri tool, come quelli di configuration management, già descritti in un precedente post, tra cui si possono citare Ansible e Chef.
All’interno della pipeline CI/CD, la fase di integrazione continua serve ad automatizzare il processo iterativo di creazione, test, controllo qualitativo della build software, quindi del codice applicativo eseguibile, completo di tutte le integrazioni, e modifiche, apportate dal team di sviluppo.
Allo scopo di rafforzare i meccanismi che verificano se il codice raggiunge determinati standard, nel processo di Continuous Integration vengono spesso inseriti quality gate, ossia ‘cancelli di qualità’, sbarramenti che il software supera soltanto se dimostra di soddisfare certe caratteristiche in termini, ad esempio, di buone pratiche di sviluppo e assenza di vulnerabilità.
Nella Continuous Integration, uno degli strumenti più utilizzati e versatili è Jenkins, un server CI installabile on-premise o in cloud e dotato di una vasta gamma di plug-in. Nulla però vieta di adottare altri tool CI (basati su cloud) come Azure DevOps o AWS CodeBuild.
Specie nei grandi progetti, per gestire la fase CI è anche possibile usare piattaforme di sviluppo collaborative come GitLab, che, oltre a supportare e presidiare la Continuous Integration, può funzionare anche come strumento di versionamento del codice.
Altri strumenti Open Source, come Rundeck, non sono dedicati in maniera specifica alla CI, ma sono molto utili per automatizzare la programmazione di varie operazioni e procedure. Sempre nella fase Continuous Integration, per controllare la qualità del codice, si può usare il tool SonarQube, gratuito nella versione Community Edition. Per eseguire controlli su eventuali vulnerabilità del codice esistono poi strumenti basati sul metodo OAST (out-of-band application security testing), introdotto per migliorare il modello DAST (dynamic application security testing).
Una volta superata la fase di Continuous Integration, la build software creata in automatico, che può essere un artefatto Java, un’immagine Docker, o un pacchetto RPM, viene depositata in un repository, in modo da essere subito disponibile per il successivo prelievo nella fase CD.
Il processo di distribuzione continua/deployment continuo del codice consiste infatti nella pubblicazione e implementazione del software in maniera automatizzata e rapida. In sostanza, l’artefatto viene prelevato da un repository e implementato su determinati carichi di lavoro (workload). Per pubblicare e distribuire il pacchetto in automatico su una molteplicità di server, nella fase CD è possibile utilizzare strumenti di configuration management come Ansible, o Chef.
In vari casi, le organizzazioni IT delle imprese tendono a gestire l’intera pipeline CI/CD con Jenkins, che quindi viene sfruttato sia per la creazione della build, sia per la distribuzione e implementazione dell’artefatto.
Tuttavia, chi desidera introdurre maggior innovazione nella fase CD, può utilizzare Argo CD, un moderno strumento di Continuous Deployment per la piattaforma di orchestrazione di container Kubernetes. Argo CD consente di eseguire il deployment di oggetti (manifesti) Kubernetes, o di Helm chart all’interno di cluster Kubernetes utilizzando il metodo dichiarativo, in cui va specificato soltanto quale dovrà essere lo stato finale dell’applicazione nel cluster stesso.
Tra l’altro, a dicembre 2022, il progetto Argo si è ufficialmente laureato, all’interno della Cloud Native Computing Foundation (CNCF), soddisfacendo rigorosi criteri e requisiti di sicurezza, governance, e adozione da parte degli utenti.
Riguardo ai tool per la gestione della fase di Continuous Deployment, non è possibile fornire indicazioni specifiche sulla selezione di strumenti particolari, in quanto la loro scelta dipende da numerose variabili. In primo luogo, dipende dalla tipologia di workload su cui si deve attuare la distribuzione del software: quindi, ad esempio, il tool da usare può essere differente, a seconda che si tratti di gestire workload tradizionali, oppure containerizzati, come quelli basati su immagini Docker.
In secondo luogo, un’altra variabile è rappresentata dall’ambiente IT in cui viene implementata l’applicazione, che può essere l’infrastruttura on-premise, oppure il cloud. In quest’ultimo caso, se i vincoli di budget lo consentono, si può optare per l’adozione di strumenti basati su servizi SaaS (software as a service) fornibili dal cloud provider.
Nel caso, invece, dell’ambiente on-premise, la scelta dello strumento CD più adatto va fatta anche sulla base dello stack software preesistente nella sede dell’azienda utente, e tenendo conto delle competenze tecniche di cui l’organizzazione si trova già in possesso internamente.