L'integrazione continua dovrebbe consentire la distribuzione del codice in un ambiente?

2

Mi sono ispirato a una domanda simile su Stackoverflow.com e dopo aver letto ciò che Martin Fowler ha scritto (e Jez Humble, ovviamente al link ), faccio ancora fatica a capire la differenza, o la linea di confine, tra integrazione continua e consegna continua.

Supponiamo che esista un semplice sistema con un'interfaccia front-end. Ogni commit su Git fa in modo che la macchina di integrazione costruisca il progetto, esegua sia i test di unità e di integrazione che la notifica del risultato.
E ora: l'app viene distribuita in un ambiente di test in modo da eseguire attività di controllo qualità da parte di ragazzi del QA. È quella consegna continua? Se no, perché? Riesco a vedere molte informazioni contraddittorie in letteratura.

    
posta Melioer 10.05.2016 - 19:19
fonte

2 risposte

1

Consegna continua ( CD da ora in poi)

Each commit to GIT causes the integration machine to build the project, run both unit and integration tests and notify about the result. And now - the app gets deployed to a test environment so as to perform QA activities by QA guys. Is that continuous delivery?

Il caso che esponi potrebbe non essere considerato CD

Aziende come la mia usano Jenkins (tool CI) per automatizzare il processo di esecuzione dei test unitari, del packaging e della distribuzione nei server test dopo il commit di Git. Ma è piuttosto lontano CD . Ci serve solo per risparmiare tempo e mantenere la ruota (QA o altri team di sviluppo) in movimento.

CD è una strategia applicata al ciclo di vita del software. Al intero ciclo di vita

L'obiettivo principale è ridurre i costi e i rischi. Come? Produzione di software in cicli brevi, esecuzione di test, build e rilasci frequenti.

Le frequenti implementazioni sulla produzione (rilascio) richiedono flessibilità in gestione della consegna . Quello che è inteso è di rilasciare bug correzioni / aggiornamenti / aggiornamenti in qualsiasi momento. Il più semplice possibile. Inoltre, da qualsiasi membro del team.

Altre ragioni alla base del CD : è necessaria un'elevata disponibilità (tramite sistemi critici) o un feedback continuo da parte degli utenti (o del cliente).

Torna alla domanda: L'integrazione continua deve essere implementata negli ambienti?

Risposta : stiamo mescolando concetti.

CI è correlato a rendere periodico il processo di compilazione e test, al fine di garantire la stabilità del codice durante la sua vita. Succede qui che gli strumenti CI sono anche in grado di eseguire implementazioni. Ma tale "capacità" (essendo dogmatica) non è correlata a CI.

Tuttavia, è un buon modo per dire: "Posso essere usato come strumento per le distribuzioni se è necessario automatizzare le distribuzioni" .

and why?

Come abbiamo indicato CD mira a creare e testare frequentemente. Qui è dove CI shinnes. Automatizza tale attività. . Ma il compito stesso è solo una parte del ciclo di vita.

    
risposta data 10.05.2016 - 19:44
fonte
0

Is that continuous delivery?

No. La consegna continua è una pratica. È un modo di sviluppare software. Non è qualcosa che può essere automatizzato anche se ci sono strumenti automatici progettati per supportarlo.

Il CD riguarda il modo in cui il software è scritto - nel CD ogni commit è destinato a produrre una versione consegnabile del software.

    
risposta data 17.12.2016 - 00:03
fonte