Qual è la differenza tra questi tre termini? La mia università fornisce le seguenti definizioni:

L'integrazione continua significa sostanzialmente che le copie di lavoro dello sviluppatore sono sincronizzate con una linea principale condivisa più volte al giorno.

La consegna continua è descritta come l'evoluzione logica dell'integrazione continua: essere sempre in grado di mettere in produzione un prodotto!

La distribuzione continua è descritta come il passo logico successivo dopo la consegna continua: Distribuire automaticamente il prodotto in produzione ogni volta che passa il QA!

Forniscono inoltre un avviso: a volte il termine "Distribuzione continua" viene utilizzato anche se si è in grado di distribuire continuamente nel sistema di test.

Tutto ciò mi lascia confuso. Ogni spiegazione che è un po 'più dettagliata (o viene fornita con un esempio) è apprezzata!

Integrazione continua

Sono d'accordo con la definizione della tua università. L'integrazione continua è una strategia per il modo in cui uno sviluppatore può integrare continuamente il codice sulla linea principale, anziché frequentemente.

Potresti affermare che è semplicemente una strategia di ramificazione nel tuo sistema di controllo della versione.

Ha a che fare con la dimensione delle attività assegnate a uno sviluppatore; Se si stima che un'attività richieda 4-5 giorni-uomo, lo sviluppatore non avrà alcun incitamento a consegnare qualcosa per i prossimi 4-5 giorni, perché non ha ancora finito nulla.

Quindi le dimensioni contano:

small task = continuous integration
big task   = frequent integration

La dimensione del compito ideale non è più grande di una giornata di lavoro. In questo modo uno sviluppatore avrà naturalmente almeno un'integrazione al giorno.

Consegna continua

Ci sono fondamentalmente tre scuole nella consegna continua:

La consegna continua è un'estensione naturale dell'integrazione continua

Questa scuola, guarda la serie di firme "Martin Fowler" di Addison-Wesley e fa l'ipotesi che dalla pubblicazione del 2007 si chiamasse "Integrazione continua" e quella che seguì nel 2011 fu chiamata "Consegna continua" , probabilmente sono volume 1 + 2 della stessa idea concettuale che ha a che fare con qualcosa di continuo .

La consegna continua ha a che fare con lo sviluppo di software Agile

Questa scuola decolla nell'idea che la consegna continua si basa sulla capacità di supportare i principi del movimento agile, non solo come un'idea concettuale o una lettera di intenti ma per davvero - nella vita reale.

Scostamento nel primo principio nel Manifesto Agile in cui il termine "consegna continua" viene effettivamente utilizzato per la prima volta:

La nostra massima priorità è soddisfare il cliente attraverso la consegna anticipata e continua di software prezioso.

Questa scuola sostiene che la "consegna continua" è un paradigma che abbraccia tutto il necessario per implementare una verifica automatizzata della tua "definizione di fatto" .

Questa scuola accetta che "Continuous Delivery" e la parola d'ordine o megatrend "DevOps" sono facce rovesciate della stessa medaglia, nel senso che entrambi cercano di abbracciare o incapsulare questo nuovo paradigma o approccio e non solo una tecnica.

La consegna continua è sinonimo di distribuzione continua

La terza scuola sostiene che la distribuzione continua e la consegna continua possono essere usate in modo intercambiabile per significare la stessa cosa.

Quando qualcosa è pronto nelle mani degli sviluppatori, viene immediatamente consegnato agli utenti finali, il che nella maggior parte dei casi significa che dovrebbe essere distribuito nell'ambiente di produzione. Quindi "Distribuisci" e "Distribuisci" significano lo stesso.

A quale scuola iscriversi

La tua università si è chiaramente unita alla prima scuola e afferma che ci stiamo riferendo al volume 1 + 2 della stessa serie di pubblicazioni. La mia opinione è che si tratta di un uso improprio del termine consegna continua.

Sostengo personalmente la comprensione che la consegna continua è legata all'implementazione di un supporto nella vita reale per le idee e i concetti dichiarati dal movimento agile. Così mi sono unito alla scuola che dice che il termine abbraccia un intero paradigma - come "DevOps".

La scuola che utilizza la consegna come sinonimo di distribuzione è per lo più sostenuta dai fornitori di strumenti che creano console di distribuzione, cercando di ottenere un po 'di clamore dall'uso più diffuso del termine consegna continua .

Distribuzione continua

L'attenzione alla distribuzione continua è principalmente rilevante nei domini in cui l'accesso dell'utente finale agli aggiornamenti del software si basa sull'aggiornamento di una fonte centralizzata per queste informazioni e in cui questa fonte centralizzata non è sempre facile da aggiornare perché è monolitica o ha (troppo) alta coerenza per natura (web, SOA, database ecc.).

Per molti domini che producono software in cui non esiste una fonte centralizzata di informazioni (dispositivi, prodotti di consumo, installazioni client ecc.) O in cui la fonte centralizzata di informazioni è facile da aggiornare (app store sistemi di gestione degli artefatti, repository Open Source ecc. ), non esiste quasi alcun clamore sul termine distribuzione continua. Si schierano e basta; non è una grande cosa - non è un dolore che richiede particolare attenzione.

Il fatto che la distribuzione continua non sia qualcosa di genericamente interessante per tutti è anche un argomento secondo cui la scuola che afferma che "consegna" e "distribuzione" sono sinonimi ha sbagliato tutto. Perché la consegna continua in realtà ha perfettamente senso per tutti, anche se si sta eseguendo software incorporato nei dispositivi o rilasciando plugin Open Source per un framework.

La definizione della tua università secondo cui la distribuzione continua è un passaggio naturale naturale della consegna continua presuppone implicitamente che ogni consegna che viene QA dovrebbe diventare immediatamente disponibile per gli utenti finali, è più vicina alla definizione che la mia tribù usa per descrivere il termine "continuo Rilascio ", che, a sua volta, è un altro concetto che non ha nemmeno un senso generico per tutti.

Un rilascio può essere una cosa molto strategica o politica e non c'è motivo di presumere che tutti vorrebbero farlo tutto il tempo (a meno che non si tratti di una libreria online un tipo di società di servizi di streaming). Tuttavia, le aziende che non rilasciano tutto alla cieca tutto il tempo possono avere un numero qualsiasi di motivi per cui vorrebbero comunque essere padrone della distribuzione, quindi anche la distribuzione continua . Non di rilascio alla produzione, ma di candidati alla liberazione simili alla produzione ambienti .

Ancora una volta credo che la tua università abbia sbagliato. Stanno scambiando "Implementazione continua" per "Rilascio continuo".

L'implementazione continua è semplicemente la disciplina di poter continuamente spostare il risultato di un processo di sviluppo in un ambiente simile alla produzione in cui i test funzionali possono essere eseguiti su vasta scala.

La trama della consegna continua

Nella foto tutto prende vita:

Il processo di integrazione continua sono le prime due azioni nel diagramma di transizione di stato. che, se ha esito positivo, dà il via alla pipeline di consegna continua che implementa la definizione di done . La distribuzione è solo una delle molte azioni che dovranno essere eseguite in modo continuo in questa pipeline. Idealmente, il processo è automatizzato dal punto in cui lo sviluppatore si impegna nel VCS al punto in cui la pipeline ha confermato che abbiamo un candidato al rilascio valido.

Né la domanda né le risposte si adattano davvero al mio modo semplice di pensarci. Sono un consulente e ho sincronizzato queste definizioni con un numero di team Dev e DevOps, ma sono curioso di sapere come si adatta al settore in generale:

Fondamentalmente penso alla pratica agile della consegna continua come un continuum:

Non continuo (tutto manuale) 0% ----> 100% Consegna continua del valore (tutto automatizzato)

Passi per la consegna continua:

Zero. Nulla è automatizzato quando il codice di check-in degli sviluppatori ... Sei fortunato se hanno compilato, eseguito o eseguito test prima del check-in.

1. Build continuo: build automatizzato su ogni check-in, che è il primo passo, ma non fa nulla per dimostrare l'integrazione funzionale del nuovo codice.

2. Integrazione continua (CI): generazione ed esecuzione automatizzate di almeno unit test per dimostrare l'integrazione di nuovo codice con il codice esistente, ma preferibilmente test di integrazione (end-to-end).

3. Implementazione continua (CD): distribuzione automatizzata quando il codice passa CI almeno in un ambiente di test, preferibilmente in ambienti più elevati quando la qualità è provata tramite CI o contrassegnando un ambiente inferiore come PASSATO dopo il test manuale. IE, i test possono essere manuali in alcuni casi, ma la promozione nell'ambiente successivo è automatica.

4. Consegna continua: pubblicazione automatizzata e rilascio del sistema in produzione. Questo è il CD in produzione più eventuali altre modifiche alla configurazione come l'installazione per il test A / B, la notifica agli utenti di nuove funzionalità, la notifica del supporto per la nuova versione e le note di modifica, ecc.

EDIT: vorrei sottolineare che esiste una differenza tra il concetto di "consegna continua", come indicato nel primo principio del Manifesto Agile ( http://agilemanifesto.org/principles.html ) e la pratica della consegna continua, come sembra essere referenziato dal contesto della domanda. Il principio della consegna continua è quello di cercare di ridurre gli sprechi di inventario come descritto nel pensiero Lean ( http://www.miconleansixsigma.com/8-wastes.html ). La pratica della consegna continua (CD) da parte di team agili è emersa nei molti anni trascorsi dalla stesura del Manifesto Agile nel 2001. Questa pratica agile affronta direttamente il principio, sebbene siano cose diverse e apparentemente facilmente confuse.

Penso alla definizione di Amazon sia diretta e semplice da capire.

" Consegna continua è una metodologia di sviluppo software in cui il processo di rilascio è automatizzato. Ogni modifica del software viene automaticamente costruita, testata e distribuita alla produzione. Prima che la spinta finale alla produzione, una persona, un test automatizzato o una regola aziendale decidano quando si dovrebbe verificare la spinta finale. Sebbene ogni modifica riuscita del software possa essere immediatamente rilasciata in produzione con consegna continua, non tutte le modifiche devono essere rilasciate immediatamente.

L'integrazione continua è una pratica di sviluppo software in cui i membri di un team utilizzano un sistema di controllo della versione e integrano il loro lavoro frequentemente nella stessa posizione, come un ramo principale. Ogni modifica viene creata e verificata da test e altre verifiche al fine di rilevare eventuali errori di integrazione il più rapidamente possibile. L'integrazione continua si concentra sulla creazione e il test automatici del codice, rispetto alla consegna continua, che automatizza l'intero processo di rilascio del software fino alla produzione . "

Consulta http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

Atlassian ha pubblicato una buona spiegazione sull'integrazione continua vs. consegna continua vs. implementazione continua .

In breve:

Integrazione continua - è un'automazione per creare e testare applicazioni ogni volta che nuovi commit vengono inseriti nella filiale.

Continuo di consegna - è continuo Integrazione + applicazione Deploy alla produzione "cliccando su un pulsante" (uscita per i clienti è spesso, ma a richiesta).

Continuous Deployment - è erogazione continua , ma senza l'intervento umano (uscita ai clienti è in corso).

L'integrazione continua significa sostanzialmente che le copie di lavoro dello sviluppatore sono sincronizzate con una linea principale condivisa più volte al giorno.

O più volte al giorno. Ogni volta che un dato compito discreto viene completato, in pratica. Si consideri ad esempio un team di sviluppatori che lavorano su una singola applicazione aziendale. In molti ambienti, può accadere quanto segue:

• Uno o due sviluppatori mantengono le modifiche locali per alcuni giorni perché "non è ancora pronto".
• Uno o due sviluppatori creano filiali nel controllo del codice sorgente in modo che possano lavorare sulle loro funzionalità "senza essere disturbati dai cambiamenti di altre persone".

Questi possono portare a problemi. Una cattiva organizzazione di codice / attività porta alla ramificazione, la ramificazione porta alla fusione, alla fusione ... alla sofferenza. L'integrazione continua come pratica affronta questo problema incoraggiando tutti a lavorare dalla stessa fonte condivisa. I singoli elementi di lavoro dovrebbero essere abbastanza discreti da essere completati in un breve lasso di tempo (al massimo ore).

Fondamentalmente l'idea generale è quella di integrare un piccolo cambiamento in una piccola quantità di lavoro. L'integrazione di un grande cambiamento è una quantità sproporzionatamente elevata di lavoro. L'aggregato del lavoro di integrazione è più piccolo se fatto in piccoli passi costanti. Ciò consente agli sviluppatori di dedicare più tempo a lavorare su funzionalità business-visibile anziché spese generali del processo di sviluppo.

La consegna continua è descritta come l'evoluzione logica dell'integrazione continua: essere sempre in grado di mettere in produzione un prodotto!

Questo segue la stessa idea di oggetti di lavoro discreti e ben definiti. Se esiste un unico codebase master che viene sempre e solo regolato in piccoli incrementi da funzionalità di lavoro complete, testate e conosciute, quel codebase è sempre stabile. I test automatizzati sono la chiave qui per essere in grado di dimostrare quella stabilità con la semplice pressione di un pulsante.

Meno lavoro di stabilizzazione deve essere svolto (che, di nuovo, è un sovraccarico del processo di sviluppo e dovrebbe essere eliminato), più spesso tale base di codice può essere trasferita in un determinato ambiente. In molte aziende una distribuzione può essere un processo piuttosto estenuante. Anche un'operazione di una sola mano sul ponte di una settimana. Questo è costoso e non produce alcun valore commerciale. Impiegando buone definizioni degli oggetti di lavoro, efficaci test automatizzati e integrazione continua, un team può essere in grado di automatizzare la consegna della base di codice in un determinato ambiente.

La distribuzione continua è descritta come il passo logico successivo dopo la consegna continua: Distribuire automaticamente il prodotto in produzione ogni volta che passa il QA!

Raramente lo vedrai accadere in un ambiente aziendale, ed è una vera gioia quando viene incontrato. Se la base di codice può essere testata e distribuita automaticamente in un determinato ambiente, allora la produzione è un ambiente come un altro. Quindi, se il team si è sviluppato fino a questo punto, allora c'è un potenziale per un valore significativo per l'azienda essendo sempre in grado di distribuire gli aggiornamenti alla produzione.

Le correzioni di errori vengono inviate ai clienti più rapidamente, le nuove funzionalità raggiungono il mercato più rapidamente, le nuove idee vengono testate sul mercato in incrementi più piccoli per consentire il reindirizzamento delle priorità, ecc.

Ad esempio, supponiamo che un'azienda abbia una grande idea per una nuova funzionalità nel suo prodotto o servizio basato su software. Hanno fatto qualche ricerca, conoscono il mercato e credono che questa idea porterà a una nuova linea di entrate forte. Ora considera due opzioni per offrire quella funzione:

1. Trascorri mesi a sviluppare il tutto in un ramo unico. Trascorrere settimane integrandolo nuovamente nella base di codice principale. Trascorrere giorni a testarlo. Trascorri un giorno distribuendolo. E solo allora inizia a monitorare le entrate effettive nel sistema di produzione.
2. Implementa piccole parti della funzione, una alla volta. Ogni settimana rilascia un nuovo pezzo di esso. Ogni settimana ottieni più dati sulle entrate effettive.

Nel primo scenario, se la funzione non ha l'effetto desiderato sul mercato, molti soldi vengono sprecati per qualcosa che i clienti in realtà non vogliono. Nel secondo scenario, il fatto che i clienti non lo desiderino è determinato molto, molto prima e il resto del lavoro ha la priorità.

In definitiva, queste "cose ​​continue" riguardano la rimozione delle spese generali del processo di sviluppo. Se una linea di entrate di un'azienda è un'offerta di servizi particolare, idealmente tutti i loro costi dovrebbero andare in quell'offerta. Le spese generali del processo di sviluppo (unione del codice, riprovare le stesse funzionalità dopo un'unione, attività di distribuzione manuale, ecc.) Non contribuiscono effettivamente al valore del servizio, quindi questi concetti cercano di rimuovere tali costi dal processo.

Un grafico può sostituire molte parole:

Godere! :-)

# Ho aggiornato l'immagine corretta ...

Differenza tra integrazione continua, consegna continua e implementazione continua

Penso che stiamo analizzando e forse complicando un po 'la serie di parole "continue". In questo contesto continuo significa automazione. Per le altre parole associate a "continuo" usa la lingua inglese come guida alla traduzione e per favore non cercare di complicare le cose! In "build continua" costruiamo automaticamente (write / compile / link / etc) la nostra applicazione in qualcosa che è eseguibile per una specifica piattaforma / container / runtime / etc. "Integrazione continua" significa che le nuove funzionalità testano e si comportano come previsto quando interagiscono con un'altra entità. Ovviamente, prima che avvenga l'integrazione, la creazione deve avvenire e verrebbero anche utilizzati test approfonditi per convalidare l'integrazione. Quindi, in "integrazione continua" si usa l'automazione per aggiungere valore a un secchio esistente di funzionalità in un modo che non interrompe negativamente la funzionalità esistente ma si integra piuttosto bene con essa, aggiungendo un valore percepito al tutto. L'integrazione implica, con la sua mera definizione inglese, che le cose si integrano armoniosamente in modo che il mio codice compili, collegamenti, test e funzioni perfettamente all'interno del tutto. Non chiameresti qualcosa di integrato se fallisse il prodotto finale, vero ?! Nel nostro contesto "implementazione continua" è sinonimo di "consegna continua" poiché alla fine della giornata abbiamo fornito funzionalità ai nostri clienti. Tuttavia, analizzando oltre questo, potrei sostenere che la distribuzione è un sottoinsieme della consegna perché distribuire qualcosa non significa necessariamente che abbiamo consegnato. Abbiamo distribuito il codice ma perché non abbiamo " t comunicato efficacemente ai nostri stakeholder, non siamo riusciti a consegnare dal punto di vista aziendale! Abbiamo schierato le truppe ma non abbiamo consegnato l'acqua e il cibo promessi alla città vicina. E se dovessi aggiungere il termine "transizione continua", avrebbe il suo merito? Dopotutto, forse è più adatto per descrivere il movimento del codice attraverso gli ambienti poiché ha la connotazione di "da / a" più che di distribuzione o consegna che potrebbe implicare una sola posizione, per sempre! Questo è ciò che otteniamo se non applichiamo il buon senso. avrebbe il suo merito? Dopotutto, forse è più adatto per descrivere il movimento del codice attraverso gli ambienti poiché ha la connotazione di "da / a" più che di distribuzione o consegna che potrebbe implicare una sola posizione, per sempre! Questo è ciò che otteniamo se non applichiamo il buon senso. avrebbe il suo merito? Dopotutto, forse è più adatto per descrivere il movimento del codice attraverso gli ambienti poiché ha la connotazione di "da / a" più che di distribuzione o consegna che potrebbe implicare una sola posizione, per sempre! Questo è ciò che otteniamo se non applichiamo il buon senso.

In conclusione, questa è roba semplice da descrivere (farlo è un po 'più ... complicato!), Basta usare il buon senso, la lingua inglese e andrà tutto bene.

Integrazione continua: la pratica di fondere costantemente il lavoro di sviluppo con il ramo principale in modo che il codice sia stato testato il più spesso possibile per rilevare tempestivamente i problemi.

Consegna continua: consegna continua del codice in un ambiente una volta che il codice è pronto per la spedizione. Potrebbe trattarsi di messa in scena o produzione. L'idea è che il prodotto viene consegnato a una base di utenti, che può essere QA o clienti per la revisione e l'ispezione.

Il test unitario durante la fase di integrazione continua non è in grado di rilevare tutti i bug e la logica aziendale, in particolare i problemi di progettazione, motivo per cui abbiamo bisogno del QA o dell'ambiente di gestione temporanea per i test.

Distribuzione continua: la distribuzione o il rilascio di codice non appena è pronto. La distribuzione continua richiede l'integrazione continua e la consegna continua, altrimenti la qualità del codice non sarà garantita in una versione.

Distribuzione continua ~~ Integrazione continua + Consegna continua

Integrazione continua

• Automatizzato (creazione di check in + unit test)

Consegna continua

• Integrazione continua
• Automatizzato (distribuzione nell'ambiente di test + test di carico + test di integrazione)
• Manuale (distribuzione in produzione)

Distribuzione continua

• Consegna continua ma automatizzata (distribuzione in produzione)

CI / CD è un viaggio. Non una destinazione.

Queste fasi sono suggerimenti. È possibile adattare le fasi in base alle proprie esigenze aziendali. Alcune fasi possono essere ripetute per più tipi di test, sicurezza e prestazioni. A seconda della complessità del progetto e della struttura dei team, alcune fasi possono essere ripetute più volte a diversi livelli. Ad esempio, il prodotto finale di una squadra può diventare una dipendenza nel progetto della squadra successiva. Ciò significa che il prodotto finale del primo team viene successivamente messo in scena come artefatto nel progetto del team successivo.

Nota in calce:

Pratica di integrazione continua e consegna continua su AWS

Fonte: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

Che cos'è l'integrazione continua L'integrazione continua è un processo o una pratica di sviluppo di build automatizzata e test automatizzati, ovvero uno sviluppatore è tenuto a trasferire il proprio codice più volte in un repository condiviso in cui ogni integrazione è verificata da build e test automatizzati.

Se la compilazione fallisce / ha esito positivo, viene notificata a uno sviluppatore e quindi può intraprendere azioni pertinenti.

Che cos'è la consegna continua La consegna continua è la pratica in cui manteniamo il nostro codice distribuibile in qualsiasi momento che ha superato tutti i test e ha tutta la configurazione richiesta per inviare il codice alla produzione ma non è stato ancora distribuito.

Che cos'è la distribuzione continua Con l'aiuto di CI abbiamo creato la build per la nostra applicazione ed è pronto per la produzione. In questo passaggio la nostra build è pronta e con il CD possiamo distribuire la nostra applicazione direttamente nell'ambiente QA e se tutto va bene possiamo distribuire la stessa build alla produzione.

Quindi, in sostanza, la distribuzione continua è un passo avanti rispetto alla consegna continua. Con questa pratica, ogni modifica che passa attraverso tutte le fasi della pipeline di produzione viene rilasciata ai tuoi clienti.

La distribuzione continua è una combinazione di gestione della configurazione e containerizzazione.

Gestione della configurazione: CM si occupa di mantenere la configurazione del server che sarà compatibile con i requisiti dell'applicazione.

Containerizzazione : la containerizzazione è un insieme di pedaggi che manterrà la coerenza in tutto l'ambiente.

Fonte img: https://www.atlassian.com/

DevOps è una combinazione di 3C: continua , comunicazione , collaborazione e questo porta a un focus primario in vari settori.

In un mondo di dispositivi connessi all'IoT, più funzioni di mischia come il proprietario del prodotto, il Web, i dispositivi mobili e il QA lavorano in modo agile in una mischia del ciclo di scrum per consegnare un prodotto al cliente finale.

Integrazione continua: funzionalità di Scrum multiplo che funziona simultaneamente in più endpoint

Consegna continua: con l'integrazione e la distribuzione, la consegna del prodotto a più clienti deve essere gestita contemporaneamente.

Implementazione continua: più prodotti distribuiti a più clienti su più piattaforme.

Guarda questo per sapere come DevOps abilita il mondo connesso IoT: https://youtu.be/nAfZt2t4HqA

Da quello che ho imparato con Alex Cowan nel corso Continuous Delivery & DevOps , CI e CD fanno parte di una pipeline di prodotti che consiste nel tempo che passa dalle osservazioni a un prodotto rilasciato.

Dall'osservazione ai disegni l'obiettivo è quello di ottenere idee verificabili di alta qualità. Questa parte del processo è considerata Progettazione continua .

Cosa succede dopo, quando passiamo dal Codice in poi, è considerata una capacità di consegna continua il cui scopo è quello di eseguire le idee e rilasciare al cliente molto velocemente (puoi leggere il libro di Jez Humble Consegna continua: Rilasci di software affidabili attraverso Build, Test, e Deployment Automation per maggiori dettagli). La seguente pipeline spiega in che cosa consistono i passaggi di integrazione continua (CI) e consegna continua (CD).

Integrazione continua , come spiega Mattias Petter Johansson ,

è quando un team di software ha l'abitudine di effettuare più fusioni al giorno e dispone di un sistema di verifica automatizzato per verificare la presenza di tali fusioni.

(puoi guardare i seguenti due video per una panoramica più pratica usando CircleCI - Introduzione a CircleCI - Integrazione continua P2 ed esecuzione di CircleCI su richiesta pull ).

È possibile specificare la pipeline CI / CD come segue, che va dal nuovo codice a un prodotto rilasciato.

I primi tre passaggi riguardano i test, estendendo il confine di ciò che viene testato.

La distribuzione continua , d'altra parte, è gestire la distribuzione automaticamente. Pertanto, qualsiasi commit di codice che supera la fase di test automatizzato viene automaticamente rilasciato nella produzione.

Nota : questo non è necessariamente l'aspetto delle pipeline, ma possono fungere da riferimento.

lasciamo breve:

CI: una pratica di sviluppo software in cui i membri di un team integrano il loro lavoro almeno quotidianamente. Ogni integrazione è verificata da build automatizzata (include i test) per rilevare l'errore il più rapidamente possibile. CD: CD Si basa su CI, in cui si crea software in modo tale che il software possa essere rilasciato in produzione in qualsiasi momento.