Come implementare il passaggio manuale al termine della consegna continua?

13

La risposta accettata alla mia domanda su "In che modo l'integrazione continua è correlata alla consegna / distribuzione continua? " Spiega anche la piccola differenza tra consegna continua e distribuzione continua . Sembra essere correlato alla risposta a una domanda come "Come si desidera distribuire alla produzione, mentre queste sono le opzioni (esclusive) tra cui scegliere:

Automatico).
Manuale.

Non riesco a immaginare che ci sarà un povero "operatore" dall'altra parte del muro DevOps, che dovrà fare qualcosa che corrisponde a qualunque cosa significhi "manuale" ... Le mie domande:

Il mio riferimento (nella mia domanda) a "distribuire" rispetto a "installa" è vicino a una possibile implementazione di tale "manuale"? Ecco una citazione pertinente della mia domanda correlata:

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. Ecco cosa 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?

Quali sono altre possibili implementazioni di esso?

continuous-delivery continuous-deployment

— Pierre.Vriens
fonte

Per le distribuzioni AWS, ho creato uno script di upload / deploy a cui solo il team manager ha accesso. Quindi, al fine di distribuire alla produzione, il team manager deve eseguire lo script.

— Turtle

Siamo spiacenti di infrangere i tuoi sogni, ma abbiamo ancora un team di "distribuzione", che Oek lancerà gli aggiornamenti del DB su Db2-iSeries con ARCAD, quindi cucinerà sui server Tomcart per distribuire le versioni in produzione ogni 2 giovedì dalle 20:00 a mezzanotte. Quindi, purtroppo, a volte c'è un operatore scadente (che si spera non sia il loro unico lavoro)

— Tensibai,

5

Personalmente considero il distributionsoftware come un obiettivo solo una fase intermedia di una distribuzione: l'installazione / l'attivazione di quel software sono necessarie per completare quella distribuzione.

Per me il delivery(come in continuos delivery) si interrompe quando il software da distribuire viene creato e reso disponibile per la distribuzione (ovvero per distribuzione, installazione e attivazione)

Quindi, per rispondere alla tua prima domanda, no, non considererei la distribuzione e l'installazione come un riflesso del passaggio manuale che differenzia la consegna continua dalla distribuzione continua.

Sì, in alcuni casi (si spera raramente) quel passaggio manuale è solo la decisione umana finale per l'implementazione nella produzione, che riflette la sfiducia culturale nell'automazione dei processi e il conforto mentale di avere un doppio controllo umano e approvare la decisione di spiegamento (assumendo così responsabilità per esso) anche se tale decisione è presa esclusivamente sulla base di un algoritmo che può essere automatizzato (come il conteggio dei risultati del test passa / non supera).

Ma in generale riflette semplicemente il fatto che la decisione di eseguire la distribuzione in produzione non è semplicemente il risultato di un algoritmo automatizzato. Ecco alcuni esempi di questi casi:

la decisione automatizzata viene sovrascritta
- l'implementazione può essere approvata anche se non tutti i criteri di qualità sono soddisfatti (sappiamo tutti che questo non è solo un caso teorico)
- l'implementazione viene mantenuta per qualsiasi motivo, anche se tutti i criteri sono soddisfatti (a causa, ad esempio, delle implicazioni sulla tempistica del mercato)
l'algoritmo automatizzato non è (ancora) implementato / distribuito
l'algoritmo include controlli per alcuni criteri a seconda delle decisioni umane (ad esempio risultati dei test manuali)
la distribuzione viene effettivamente eseguita in un ambiente cliente di terze parti, a seguito di ulteriori controlli da parte dei clienti

Quindi non vorrei considerare il passaggio manuale semplicemente come un problema di implementazione.

— Dan Cornilescu
fonte

Merci (oeps: grazie) per aver condiviso i tuoi punti di vista su questo. Sembra che abbiamo una diversa percezione della "distribuzione". Vorrei solo aggiungere uno scenario: hai una finestra di 1 ora, per un sistema bancario online, una domenica mattina presto, per "attivare" 150.000 eseguibili aggiornati. E se per qualsiasi motivo fosse necessario un rollback, allora non è possibile alcuna negoziazione per estendere quella finestra. Vorresti davvero perdere tempo a "distribuire", invece di usare il tempo necessario per quello "nel caso in cui sia necessario il rollback? Pensaci due volte: se impiega più di 1 ora ... sei licenziato ... Beh ???

— Pierre.Vriens

Questo è IMHO solo un dettaglio di ottimizzazione o implementazione della distribuzione stessa, applicabile nel tuo caso (ma questo non lo rende una regola). Solo perché stai eseguendo parte della tua distribuzione prima di chiudere effettivamente la vecchia esecuzione sw non significa che il rispettivo lavoro faccia parte della fase di consegna. Inoltre, ciò non significa necessariamente che una volta avviata la distribuzione, sia necessario completarla. Il software SW viene effettivamente distribuito (ovvero disponibile / pronto per la distribuzione) anche se non viene effettivamente distribuita.

— Dan Cornilescu,

2

Un'ulteriore considerazione se pubblichi qualcosa che ti aspetti che vengano consumati altri progetti, la distribuzione assume anche il significato di "pubblicare per gli altri"

Considerare un flusso di lavoro in cui si distribuisce una libreria in un repository di artefatti comune. Questa parte del processo potrebbe far parte della distribuzione di un altro componente che richiede quel manufatto al momento della creazione o potrebbe essere semplicemente un aggiornamento di una libreria comune. Ma a prescindere, per quel manufatto, il suo ciclo di vita non finisce necessariamente con la messa a disposizione per il consumo da parte di altri, ma la distribuzione di quel manufatto nel repository di manufatti potrebbe essere la fase finale del lavoro degli sviluppatori dopo che hanno deciso di tagliare un nuova versione di rilascio e prima che gli altri possano tranquillamente consumare la nuova versione.

— hvindin
fonte