Continuous integration, continuous delivery e continuous deployment a confronto
Scopri le differenze tra queste pratiche continue
Sten Pittet
Scrittore collaboratore
CI e CD sono due acronimi usati di frequente nelle moderne pratiche di sviluppo e DevOps. CI sta per continuous integration, una best practice DevOps fondamentale in cui gli sviluppatori eseguono con frequenza il merge delle modifiche del codice in un repository centrale dove vengono eseguiti build e test automatizzati. Ma CD può significare sia continuous delivery che continuous deployment.
Quali sono le differenze tra continuous integration, continuous delivery e continuous deployment (CI/CD)?
Continuous integration
Gli sviluppatori che praticano la continuous integration eseguono il merge delle modifiche nel branch principale il più spesso possibile. Le modifiche degli sviluppatori vengono convalidate tramite la creazione di una build e l'esecuzione di test automatizzati su quest'ultima. Così facendo, si evitano le sfide di integrazione che possono verificarsi quando si attende il giorno del rilascio per eseguire il merge delle modifiche nel branch di rilascio.
La continuous integration pone grande enfasi sull'automazione dei test per verificare che l'applicazione non venga interrotta ogni volta che nuovi commit vengono integrati nel branch principale.
Produzione continua
La continuous delivery è un'estensione della continuous integration poiché distribuisce automaticamente tutte le modifiche al codice in un ambiente di test e/o produzione dopo la fase di compilazione.
Ciò significa che oltre ai test automatizzati, avrai a disposizione un processo di rilascio automatizzato e che potrai distribuire l'applicazione in qualsiasi momento con il semplice clic di un pulsante.
In teoria, con la continuous delivery, puoi decidere di rilasciare ogni giorno, ogni settimana, ogni due settimane o in base a una qualsiasi altra frequenza adatta alle tue esigenze aziendali. Tuttavia, per sfruttare davvero i vantaggi della continuous delivery, consiglio di eseguire la distribuzione nell'ambiente di produzione il prima possibile per fare in modo di rilasciare piccole batch facili da gestire in caso di problemi.
Scopri la soluzione
Creare e gestire software con Open DevOps
Materiale correlato
Cos'è la pipeline DevOps?
Continuous deployment
La continuous deployment fa un passo avanti rispetto alla continuous delivery. Con questa pratica, ogni modifica che attraversa tutte le fasi della pipeline di produzione viene rilasciata ai clienti. Non c'è nessun intervento umano e solo un test non superato impedirà la distribuzione di una nuova modifica nell'ambiente di produzione.
La continuous deployment è un ottimo modo per accelerare il ciclo di feedback con i clienti e alleviare la pressione sul team, poiché non c'è più un "giorno del rilascio". Gli sviluppatori possono concentrarsi sulla compilazione di software e vedono il loro lavoro distribuito già pochi minuti dopo aver finito di lavorarci.
In che modo le pratiche si relazionano tra loro
Per dirla semplicemente, la continuous integration fa parte sia della continuous delivery che della continuous deployment. E la continuous deployment è come la continuous delivery, tranne per il fatto che i rilasci avvengono automaticamente.
Quali sono i vantaggi di ogni pratica?
What are the benefits of each practice?
Abbiamo parlato della differenza tra continuous integration, continuous delivery e continuous deployment, ma non abbiamo ancora esaminato i motivi per cui è consigliabile adottare queste pratiche. L'implementazione di ogni pratica comporta costi evidenti che tuttavia sono ampiamente compensati dai vantaggi che ne derivano.
Continuous integration
Cosa occorre (costi)
- Il team dovrà scrivere test automatizzati per tutte le nuove funzioni, i miglioramenti o le correzioni di bug.
- È necessario un server di continuous integration in grado di monitorare il repository principale ed eseguire automaticamente i test per ogni nuovo commit inviato.
- Gli sviluppatori devono eseguire il merge delle modifiche il più spesso possibile, almeno una volta al giorno.
Cosa si ottiene
- Man mano che le regressioni vengono rilevate precocemente dai test automatizzati, all'ambiente di produzione viene inviato un numero inferiore di bug.
- Compilare il rilascio è facile poiché tutti i problemi di integrazione sono stati risolti in anticipo.
- Si verificano meno cambi di contesto in quanto gli sviluppatori vengono avvisati non appena vi sono danneggiamenti della build e possono occuparsi della risoluzione prima di passare a un altro task.
- I costi legati ai test sono ridotti drasticamente: il server di CI è in grado di eseguire centinaia di test in pochi secondi.
- Il team del controllo di qualità dedica meno tempo alle attività di test e può concentrarsi su miglioramenti significativi della cultura della qualità.
Produzione continua
Cosa occorre (costi)
- Occorre una solida base di continuous integration e la suite di test deve coprire una parte sufficiente della base di codice.
- Le distribuzioni devono essere automatizzate. L'attivazione è ancora manuale, ma una volta avviata la distribuzione, non dovrebbe essere necessario l'intervento umano.
- Molto probabilmente il team dovrà adottare i flag delle funzioni per evitare che le funzioni incomplete influiscano sui clienti nell'ambiente di produzione.
Cosa si ottiene
- La complessità della distribuzione di software è stata eliminata. Il team non deve più passare giorni a prepararsi per un rilascio.
- Puoi rilasciare con maggiore frequenza, accelerando così il ciclo di feedback con i clienti.
- C'è molta meno pressione sulle decisioni relative alle piccole modifiche a favore di iterazioni più veloci.
Continuous deployment
Cosa occorre (costi)
- La cultura dei test deve essere al suo meglio. La qualità della suite di test determinerà la qualità dei rilasci.
- Il processo di documentazione dovrà stare al passo con il ritmo delle distribuzioni.
- I flag delle funzioni diventano parte integrante del processo di rilascio delle modifiche significative per garantire il coordinamento con gli altri reparti (assistenza, marketing, pubbliche relazioni...).
Cosa si ottiene
- Puoi accelerare le attività di sviluppo in quanto non è necessario sospendere lo sviluppo dei rilasci. Le pipeline di distribuzione vengono attivate automaticamente per ogni modifica.
- I rilasci sono meno rischiosi e più facili da risolvere in caso di problemi poiché si procede distribuendo piccole batch di modifiche.
- I clienti vedono un flusso continuo di miglioramenti e incrementi della qualità ogni giorno, anziché ogni mese, trimestre o anno.
Uno dei costi tradizionali associati alla continuous integration è l'installazione e la manutenzione di un server di CI. Ma è possibile ridurre in modo significativo i costi legati all'adozione di queste pratiche utilizzando un servizio cloud come Bitbucket Pipelines che aggiunge le funzioni di automazione a ogni repository di Bitbucket. Aggiungendo semplicemente un file di configurazione alla radice del repository, sarai in grado di creare una pipeline di continuous deployment che viene eseguita per ogni nuova modifica inviata al branch principale.
Passaggio dalla continuous integration alla continuous deployment
Se sei all'inizio di un nuovo progetto senza utenti, potrebbe essere facile distribuire ogni commit nell'ambiente di produzione. Potresti persino iniziare automatizzando le distribuzioni e rilasciando la versione alfa nell'ambiente di produzione senza clienti. Quindi, puoi rafforzare la cultura dei test e fare in modo di aumentare la copertura del codice man mano che prosegui con la compilazione dell'applicazione. Quando sarà tutto pronto per l'onboarding degli utenti, avrai a disposizione un ottimo processo di continuous deployment in cui tutte le nuove modifiche vengono testate prima di essere rilasciate automaticamente nell'ambiente di produzione.
Ma se hai già un'applicazione esistente con i clienti, ti consiglio di procedere lentamente e iniziare con la continuous integration e la continuous delivery. Inizia implementando i test unitari di base che vengono eseguiti automaticamente: non è ancora necessario concentrarsi sull'esecuzione di test end-to-end complessi. Invece, prova ad automatizzare le distribuzioni il prima possibile e arrivare a una fase in cui le distribuzioni negli ambienti di staging vengono eseguite automaticamente. Il motivo è che, avendo a disposizione le distribuzioni automatiche, puoi concentrare le tue energie sul miglioramento dei test piuttosto che interrompere periodicamente le operazioni per coordinare un rilascio.
Una volta che puoi iniziare a rilasciare software su base giornaliera, puoi pensare alla continuous deployment. Ma assicurati che anche il resto dell'organizzazione (documentazione, assistenza, marketing ecc.) sia pronto per il passaggio. Questi reparti dovranno adattarsi alla nuova cadenza dei rilasci ed è importante che non perdano modifiche significative che possono avere un impatto sui clienti.
Leggi le nostre guide
Read our guides
Sono disponibili alcune guide più approfondite per iniziare a implementare queste pratiche.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Community DevOps
Leggi il blog
