Perché CI stabilisce che dovremmo essere in grado di eseguire il rollback su qualsiasi versione di un software?

In breve:

1. Dato che non si sa se una build contiene un bug critico al momento della distribuzione, potrebbe essere necessario eseguire il rollback di più di una versione quando si distribuisce a una frequenza relativamente alta. Se la tua configurazione non ti consente di farlo, l'unica alternativa è quella di andare avanti il più velocemente possibile.

2. Non appena si dispone di un'applicazione con dipendenze di terze parti (ad esempio un'API) o di archiviazione (ad esempio un database con schema), il rollback potrebbe essere molto più difficile della semplice distribuzione di stessi bit. Il controllo del codice sorgente non è sufficiente, lo schema deve essere reselient. Potrebbe essere necessario creare compatibilità in avanti e all'indietro nella progettazione del codice e dello schema del database per poterlo rimuovere.

3. Code First Migrations ti permetterà di andare avanti facilmente, ma non aggiusta lo schema se elimini accidentalmente una colonna vitale, o popola un valore predefinito con il valore sbagliato o qualcos'altro che potrebbe accadere durante un migrazione. essere in grado di eseguire il rollback significherebbe essere in grado di ripristinare le modifiche accidentali, pur mantenendo importanti dati (aziendali). Pattern come CQRS ti forniscono una forma di registrazione e riproduzione delle modifiche, che ti permetterà di ricostruire i dati nella sua forma originale, se necessario.

La tua interpretazione è valida quando puoi rimuovere il sito / l'applicazione, eseguirne il backup, installare la nuova versione, testarla (puoi essere certo di non aver introdotto un bug critico?) e vederlo lavori. Se vuoi fare un passo in avanti, eseguire implementazioni a rotazione, build / rilasci canarini, lancio a cielo aperto, failover live e altre tecniche di implementazione avanzate, devi fare un passo indietro e prendere in considerazione l'intera immagine.

Supponendo di avere l'integrazione continua e di voler distribuire ogni build quando supera tutti i test, potresti già essere in 2 o 3 distribuzioni quando potresti trovare un difetto critico per il quale non stavi testando.

Se puoi tornare indietro di una distribuzione, sei bloccato e dovrai correggere il difetto e andare avanti. Ciò pone una serie di richieste sulla tua capacità di trovare, testare e distribuire una patch in breve tempo.

Se sei in grado di tornare all'ultima build conosciuta, sei in acqua molto più sicura.

Vedrai che i team che hanno la possibilità di eseguire il rollover in qualsiasi momento, saranno meno rigidi su questa regola, rispetto ai team che hanno bisogno della possibilità di eseguire il rollback.

Essere in grado di eseguire il rollback alla versione corrente è un modo diverso di dire "rollback alla versione precedente", ora per farlo hai 2 modi per farlo:

• Puoi semplicemente fare una copia della versione corrente prima della distribuzione, e se qualcosa va storto, basta sostituire la nuova versione con la copia di backup.
• È possibile creare un sistema in cui è possibile distribuire qualsiasi versione, quindi la distribuzione di un nuovo rilascio significa eseguire l'attività di distribuzione con la versione più recente e il rollback è solo lo stesso processo: solo si specifica la versione precedente.

Il secondo modo è ovviamente più lavoro, ma è di gran lunga superiore - è il modo "giusto" per farlo. Si sposta il problema del rollback su una distribuzione, quindi non è necessario un lavoro speciale per eseguire il backup e ridistribuire il backup. Salvare te stesso questo lavoro extra significa che puoi spenderlo per creare il meccanismo di distribuzione corretto, che devi comunque utilizzare come metodo per la distribuzione di nuove versioni!

Quindi, configurare il tuo sistema di CI per l'implementazione è più facile, migliore e consente anche di distribuire versioni molto vecchie gratuitamente. In alcune aziende questo è essenziale in quanto potresti essere chiamato a eseguire il debug di un problema che un cliente ha nella versione, quindi avrai bisogno di un modo per ricreare la versione che stanno utilizzando. Potresti non averne bisogno per il tuo sito web con un'unica implementazione, in modo da non vedere quale potrebbe essere il beneficio, ma fidati di me - è molto reale.

Imposta il tuo sistema CI in questo modo e sarai impostato per il futuro, e qualsiasi ruolo futuro che potresti avere dove hai bisogno di un sistema CI pienamente funzionante, avrai esperienza nell'impostarlo correttamente.

"Una volta implementato e funzionante, perché vorresti mai tornare a una versione precedente?" Le parole chiave qui sono "e funzionano". In un mondo perfetto, ogni nuova versione sarebbe stata accuratamente testata e completamente accurata prima di essere implementata. Ma nella vita reale, questo non sempre accade. Cosa succede se si scopre un bug critico che è stato introdotto, non nella versione corrente, ma nella versione precedente? Hai molti bisogno di ripristinare due versioni. Un sacco di applicazioni in questi giorni, in particolare i siti web, hanno un tasso di distribuzione abbastanza alto. Se pubblichi una nuova versione ogni giorno, non sarebbe scioccante se un bug introdotto tre giorni fa non fosse stato scoperto fino ad oggi.

Anche con un programma di rilascio relativamente lento, i bug potrebbero non essere rilevati per un lungo periodo di tempo. Come molte applicazioni hanno "report di fine anno". Se abbiamo rilasciato una nuova versione a gennaio che ha creato un bug nella segnalazione di fine anno, potrebbe passare inosservata per quasi un anno. (Il ripristino di un anno di rilasci è una soluzione pratica, beh, dipende dalla natura dell'app e da quanto sta cambiando. Presumibilmente ogni rollback è temporaneo, solo finché non viene corretta la versione corrente e può essere ridistribuita.)

Non importa la distribuzione corrente, se tu (o i tuoi clienti) esegui una versione precedente potresti aver bisogno di ottenere un'istantanea di quella versione per riprodurre un problema per un incidente o confrontare il comportamento indesiderato corrente con una build precedente. Ciò include non solo l'applicazione, ma anche i dati dei test e i dettagli del test.