Che cos'è l'integrazione continua e la consegna/implementazione continua?
Questa sezione illustra le pratiche di integrazione e consegna continua e spiega la differenza tra la consegna continua e l'implementazione continua.
Integrazione continua
Integrazione continua (CI): si tratta di una pratica di sviluppo software in cui gli sviluppatori uniscono regolarmente le modifiche al codice in un repository centrale, su cui vengono applicati test automatici e build. La CI molto spesso si riferisce alla fase di compilazione o integrazione del processo di rilascio di software e richiede sia una componente di automazione (ad esempio un servizio di CI o di compilazione) che una componente culturale (ad esempio abituarsi a integrare in modo frequente). Gli obiettivi principali della CI sono individuare e risolvere i bug con maggiore tempestività, migliorare la qualità del software e ridurre il tempo richiesto per convalidare e pubblicare nuovi aggiornamenti.
L'integrazione continua si concentra su commit più piccoli e modifiche al codice di minore entità da integrare. Uno sviluppatore esegue il commit del codice a intervalli regolari, almeno una volta al giorno. Lo sviluppatore estrae il codice dal repository del codice per assicurarsi che tale codice venga unito sull'host locale prima di eseguire il push sul server di sviluppo. In questa fase, il server di sviluppo esegue i vari test e accetta o rifiuta il commit del codice.
Le sfide di base dell'implementazione della CI includono commit più frequenti nella base di codice comune, il mantenimento di un unico repository di codice sorgente, l'automazione delle build e l'automazione dei test. Altre sfide includono l'esecuzione di in ambienti simili a quello di produzione, per fornire al team visibilità sul processo e consentire agli sviluppatori di ottenere facilmente qualsiasi versione dell'applicazione.
Consegna e implementazione continue
La consegna continua (CD) è un metodo di sviluppo software in cui le modifiche al codice vengono compilate, testate e preparate per il rilascio nell'ambiente di produzione in modo automatico. Espande il processo di integrazione continua implementando tutte le modifiche al codice nell'ambiente di test e di produzione (o in entrambi) dopo la fase di compilazione. La consegna continua può essere completamente automatizzata con un processo del flusso di lavoro o parzialmente automatizzata con passaggi manuali nei punti critici. Se la consegna continua viene implementata correttamente, gli sviluppatori hanno sempre a disposizione un artefatto della build pronto per l'implementazione che ha già passato un processo di test standardizzato.
Con l'implementazione continua, le revisioni vengono implementate automaticamente nell'ambiente di produzione senza alcuna approvazione esplicita da parte di uno sviluppatore, automatizzando di fatto l'intero processo di rilascio del software. Questo, a sua volta, consente un circuito continuo di feedback dei clienti nelle prime fasi del ciclo di vita del prodotto.
La consegna continua è diversa dall'implementazione continua
Un pensiero errato sulla consegna continua è la convinzione che tale processo implichi che ogni modifica sottoposta a commit venga applicata all'ambiente di produzione immediatamente dopo aver superato i test automatici. Tuttavia, il punto della consegna continua non è applicare immediatamente ogni modifica all'ambiente di produzione, ma garantire che ogni modifica sia pronta per essere inserita nell'ambiente di produzione.
Prima di implementare una modifica nell'ambiente di produzione, è possibile implementare un processo decisionale per garantire che l'implementazione nell'ambiente di produzione sia autorizzata e sottoposta a verifica. Questa decisione può essere presa da una persona e quindi eseguita dagli strumenti.
Utilizzando la consegna continua, la decisione di procedere al lancio diventa una decisione aziendale e non tecnica. La convalida tecnica avviene su ogni commit.
L'introduzione di una modifica nell'ambiente di produzione non è un evento di disturbo. L'implementazione non richiede che il team tecnico smetta di lavorare sul successivo set di modifiche e non necessita di un piano del progetto, di una documentazione di consegna o di un intervallo di tempo dedicato alla manutenzione. L'implementazione diventa un processo ripetibile che è stato eseguito e collaudato più volte negli ambienti di test.
