In che modo l'integrazione continua è correlata alla consegna / implementazione continue?

Ecco una citazione dal contenuto attuale di integrazione continua :

... processo di fusione frequente delle copie del codice di lavoro dello sviluppatore in una base di codice condivisa per prevenire o ridurre al minimo i problemi di integrazione.

OK, ho capito. Ma poi c'è anche la consegna continua e la distribuzione continua , ed è lì che mi perdo continuamente un po ':

• In che modo l' integrazione continua si riferisce alla consegna continua e / o alla distribuzione continua , supponendo che da qualche parte lungo la linea (e) attraverso di integrationvoi finisca deliveringin un ambiente target in cui tutto sarà deployed.
• Qual è la differenza tra consegna continua e distribuzione continua ?

Ai giorni nostri, prima che DevOps fosse chiamato DevOps, usavamo una terminologia che potrebbe aiutare a comprendere questi nuovi termini DevOps, come:

• promuovere a (o retrocedere da) un target pre-prodotto, facoltativamente combinato con un qualche tipo di processo di rigenerazione (compilazioni, legami, ecc.) per impacchettare tutti i componenti correlati in cose eseguibili. Ecco cosa dovrebbe essere simile / vicino all'integrazione continua o no?
• distribuire in un ambiente di destinazione, usando qualcosa come FTP (se le copie standard non possono colmare il divario), ma non attivarlo ancora nella destinazione. È quello che dovrebbe essere simile / vicino alla consegna continua o no?
• installare (o attivare ) in alcuni ambienti di destinazione, combinato con cose come collegamenti, operazioni di arresto / avvio, ecc. Ecco cosa dovrebbe essere simile / vicino alla distribuzione continua o no?

La consegna continua e l'implementazione continua fanno un ulteriore passo avanti nell'integrazione continua, aggiungendo al processo una fase di "implementazione nella produzione". La differenza tra consegna continua e distribuzione è che per la consegna questo passaggio viene eseguito manualmente e per la distribuzione è automatico.

Differenza tra integrazione continua, consegna continua e distribuzione continua. Immagine copiata da codeproject.com

Sia che si effettui la consegna continua o la distribuzione continua è sicuramente una scelta di implementazione. Se si esegue una distribuzione continua, le modifiche al codice verranno distribuite automaticamente dopo il superamento dei test di accettazione. Questo può o meno essere desiderabile per il tuo prodotto. Con la consegna continua, le persone possono scegliere se distribuire o meno una determinata modifica del codice (e possibilmente dove esattamente viene distribuita).

Poiché la differenza tra consegna continua e distribuzione è piccola e molte persone non sono consapevoli della differenza esatta, i due termini sono talvolta usati in modo intercambiabile.

La consegna continua e la distribuzione continua (CD) sono più o meno la stessa cosa *. Ogni volta che un cambiamento è considerato "buono per partire" (testato / verificato), dovrebbe essere rilasciato immediatamente. Puoi farlo tante volte al giorno quanti sono i lavori completati.

L'integrazione continua (CI) si riferisce solo alla fusione del codice spesso per garantire che i rami delle caratteristiche non si allontanino troppo dal ramo principale "principale" e anche in modo da sapere molto rapidamente se ci sono problemi con il codice da un prospettiva di integrazione - vale a dire hai rotto qualsiasi funzionalità durante il cambio di roba.

Per quanto riguarda il modo in cui si relazionano tra loro, CI aiuta notevolmente a verificare il codice in modo che possa essere rilasciato rapidamente (CD). Puoi ancora ottenere CD senza CI (e viceversa), ma scoprirai che spesso rende la vita molto più facile integrare il codice in anticipo e spesso trovare i problemi più velocemente, il che a sua volta ti consentirà di risolvere tali problemi più velocemente, e infine consegna le tue funzionalità più velocemente!

* Modifica: ecco un articolo che discute della differenza. https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff La consegna continua non significa sempre distribuire effettivamente alla produzione in ogni momento, piuttosto significa distribuire costantemente in un ambiente simile alla produzione , con la certezza che tali cambiamenti potrebbero andare in produzione in qualsiasi momento una volta che l'azienda è pronta. In pratica, molte persone confondono questi termini.

Una determinata versione di un prodotto software deve prima completare la fase di integrazione prima di poter essere consegnata o distribuita.

Per continuo consegna / distribuzione continua integrazione è un must. Altrimenti, se gli eventi di integrazione completata sono troppo distanti per qualificarsi per l'attributo "continuo", lo sono anche le possibili consegne / distribuzioni (solo un sottoinsieme delle versioni integrate in genere si qualifica per consegne / distribuzione).

Aggiornamento: la mia risposta sottolinea solo la dipendenza (relazione) tra CI e (entrambi) i CD, la terminologia è piuttosto ben coperta dalla risposta di THelper.

L'unico commento che dovrei fare riguarda l'uso (sovraccarico) di deployment. Le distribuzioni in ambienti non produttivi sono reali. Possono anche accadere abbastanza spesso, ad esempio nell'ambito di varie fasi di test durante la consegna continua. Ma ciò non consente tali implementazioni continuous deployments. Le distribuzioni continue si riferiscono specificamente alle distribuzioni nell'ambiente di produzione.

Fondamentalmente, l'integrazione continua fa parte sia della distribuzione continua che della distribuzione continua, tranne per il fatto che le versioni avvengono automaticamente. Puoi anche pensare alla consegna continua come un logico prossimo passo di integrazione continua e funziona in tutti gli ambienti. L'integrazione continua aiuta anche con la verifica degli artefatti in modo che possa essere implementata più rapidamente. Sebbene non sia possibile disporre di una distribuzione continua senza integrazione continua ed è molto più facile rilevare i bug con l'integrazione continua. Tutte queste "cose ​​continue" riguardano in definitiva la rimozione di azioni non necessarie nel flusso di lavoro di sviluppo. Ancora più importante, CI / CD sono importanti sia dal punto di vista tecnico che commerciale. Le aziende che non adottano questi principi DevOps rischiano di seguire la strada dei dinosauri. Neanche nell'ambiente IT di oggi è freneticoDevops o die.