Come eseguire il rollback delle funzionalità rifiutate dal controllo qualità in uno scenario di consegna continua?

Question

Come eseguire il rollback delle funzionalità rifiutate dal controllo qualità in uno scenario di consegna continua?

#1 da (8 voti)
#2 da (4 voti)
#3 da (3 voti)

6

Dato che sto cercando sempre di più nella fornitura continua per la nostra organizzazione, faccio fatica a capire come possiamo integrare efficacemente i test di QA manuali prima che un rilascio venga trasferito in produzione.

Ho trovato diversi approcci, come branch-per-feature uno spiegato da Adam Dymitruk o git-flow e simili, che sembrano tutti includere un sacco di lavoro manuale per far sì che le cose configurino ogni sprint o eseguano operazioni di rollback.

Cercherò di spiegare il mio problema dando un esempio.

La maggior parte dei documenti CD delinea il flusso del percorso "felice" come segue:

develop -> CI build -> deploy to QA -> test on QA -> promote to Production

Questo è abbastanza facile da capire e funziona bene se non ci sono problemi. Ma supponiamo che il seguente flusso di lavoro richieda test manuali prima che una distribuzione alla produzione sia autorizzata: lo sviluppatore 1 lavora sulla funzione A, lo sviluppatore 2 lavora sulla funzione B. Io uso le funzionalità del nome, ma non lo dico necessariamente nella vasta gamma di una funzionalità che potrebbe essere contenuta utilizzando i pulsanti di selezione delle funzioni. Solo un po 'di lavoro.

lo sviluppatore 1 finisce il suo lavoro, unisce tutto in master - o il ramo di rilascio equivalente - innesca la build che viene distribuita in QA. Il controllo qualità inizia a testare. Durante i test di QA, lo sviluppatore 2 finisce il suo lavoro, si fonde in master, attiva la build. Il QA quindi rifiuta la caratteristica A. Pertanto, il rilascio dallo sviluppatore 1 non può continuare. A questo punto l'intero processo si ferma. Finché la funzione A non è pronta, la funzione B non può essere testata perché contiene anche il codice rifiutato dalla caratteristica A.

E questa è la parte che non capisco veramente come sistemare in modo semplice e automatico. Come possiamo ripristinare efficacemente la funzionalità A senza complessi interventi manuali? Come fanno le persone a fare questo? Sicuramente questo deve essere un problema che tutti affrontano, ma nessuno dei libri o degli schemi che ho letto finora sembra davvero affrontare questo problema.

Un passo in più. GitHub flow sembra suggerire di distribuire il ramo della caratteristica in produzione e il rollback se si verifica un problema di produzione. Potrebbe funzionare in uno scenario per singolo tester per sviluppatori, ma cosa succede se più funzioni sono firmate da più tester contemporaneamente?

lo sviluppatore 1 avvia la sua funzione, i rami del master, inizia a lavorare, spinge in master, i test del QA 1. Allo stesso tempo, lo sviluppatore 2 ha seguito lo stesso processo e QA 2 ha testato la sua funzionalità. Dato lo schema, la caratteristica A non contiene la caratteristica B e la caratteristica B non contiene la caratteristica A. Il QA 1 si disattiva, la caratteristica A entra in produzione. QA 2 firma, la funzionalità B entra in produzione. Ma la caratteristica A è persa. È in master, sì, dopo la distribuzione è stato unito, ma non tornerà in produzione fino a quando la caratteristica C non verrà schierata.

In che modo il flusso di GitHub funzionerebbe efficacemente in team più grandi? Qualcuno ha qualche esempio pratico su questo?

testing agile continuous-integration continuous-delivery

posta Jensen 01.06.2017 - 23:34

fonte

3 risposte

Leggi altre domande sui tag testing agile continuous-integration continuous-delivery

Gestione degli eventi, riproduzione e controllo delle versioni Va bene usare le classi statiche mentre si crea un wrapper per l'API REST?

score 8 · Answer 1

Quando un codice modificato A viene rifiutato, non pensare necessariamente in termini di "funzionalità di ripristino A annullando l'unione mediante SCCS". Pensa in termini di "aggiunta di una nuova modifica al codice che corregge i difetti riscontrati dal controllo qualità".

A seconda del problema, questo può significare:

correggendo immediatamente un bug, ma lasciando il codice di A nel master
disabilitazione della funzionalità aggiunta da A (disattivando un punto di ingresso della funzione, magari utilizzando un "interruttore di funzionalità"), finché i problemi non possono essere risolti, lasciando comunque il codice correlato nel master
aggiungendo modifiche al codice che rimuovono efficacemente le modifiche al codice di A dal master - ma in un modo che non interferisce con modifiche successive come B

Il terzo punto elenco può spesso, ma non necessariamente, far sì che lo sviluppatore (e non il team di QA da qualche automatismo magico) usi l'SCCS e ripristini le modifiche al codice di A. Se questo rollback non mostra collisione con B, bene, se c'è una collisione, potrebbe esserci qualche lavoro manuale coinvolto (paragonabile al lavoro manuale quando A e B sono stati integrati uno dopo l'altro).

E sì, scegliere la strategia giusta è una decisione manuale, e richiederà un po 'di tempo e lavoro manuale - questo non è un modo completamente "automatizzato", ma non richiede anche "un intervento manuale complesso" ogni volta che succede . In realtà, la gamma di un problema di correzione o di rollback va da "banale" a "complesso". Quando si mira alla consegna continua, tuttavia, si dovrebbe cercare di far sì che i piccoli rollback avvengano molto più frequentemente di quelli complessi.

L'approccio migliore per questo è probabilmente quello di selezionare funzionalità per lo sviluppo parallelo in modo tale che sia improbabile che debbano toccare la stessa parte del codice di base. Inoltre, ci dovrebbero essere quanti più test automatici possibili. Quindi gli sviluppatori possono eseguire questi test durante lo sviluppo delle funzionalità prima che il loro codice raggiunga il "master". Questo dovrebbe impedire frequenti stop-show durante il controllo qualità.

Ora, applichiamo questi consigli allo scenario:

As long as feature A is not ready, feature B cannot be tested because it also contains the rejected code from feature A.

Ma perché no? Quando A e B erano eleggibili per lo sviluppo parallelo, dovrebbero essere per lo più indipendenti l'uno dall'altro e quindi idonei per i test indipendenti, il che significa che nella maggior parte dei casi B può essere testato anche se i problemi con A non sono corretti. Diciamo che il QA riporta un bug serio di A che non è stato rilevato dai test automatici. Il fatto che i test automatici non abbiano fallito dovrebbe significare che almeno l'applicazione non dovrebbe essere completamente inutilizzabile, quindi possono iniziare con i test di B. Essi sanno che il master non può essere consegnato alla produzione finché il problema con A non è fisso, ma durante il test di B, ci dovrebbe essere abbastanza tempo per correggere o rollback A in uno dei 3 modi che ho menzionato sopra.

Naturalmente, è necessario prendere una decisione su quale sia il modo più rapido per rimuovere il problema con A e rendere nuovamente il codice "pronto per la produzione". Quindi, una volta terminato il test di B, una correzione per il problema con A dovrebbe essere già disponibile (o almeno presto), quindi il QA può approvare che il problema sia scomparso ora (o con la funzionalità di A ora o non).

Osservando la timeline, dopo ogni ciclo di test il tuo "master" può passare tra due stati principali: o ha "difetti noti" , o ci sono "nessun difetto noto più ". Ogni volta che raggiunge lo stato "nessun difetto noto", è possibile distribuire in produzione. Per rendere operativa la distribuzione continua, è necessario pianificare le feature slice in modo che lo stato "nessun difetto noto più" sia raggiunto il più frequentemente possibile. La chiave qui è

rende le singole sezioni di feature come "A" e "B" dall'alto come più piccole possibile
seleziona sezioni di feature per lo sviluppo parallelo il più possibile indipendenti
pianifica il ripristino o la disattivazione di una feature slice in modo molto rapido e fluido nel caso in cui contenga un bug che impedisce la consegna alla produzione

In una squadra più grande (forse una dozzina o più sviluppatori), quando noti che raggiungi lo stato "non noti difetti" troppo raramente a causa dei costanti controlli da controllare, puoi anche considerare di utilizzare una "pre-produzione" aggiuntiva "(o" staging ") ramo in cui sono integrate solo le funzionalità che sono state approvate dal QA sul ramo principale. Tuttavia, questo non viene fornito gratuitamente, è necessario che un'altra persona esegua le integrazioni in "pre-produzione", un altro passaggio QA in "pre-produzione" per verificare che le integrazioni non introducano un bug e un sovraccarico amministrativo aggiuntivo per la gestione del ambiente di pre-produzione.

score 4 · Answer 2

Non considerare questo come un problema di controllo del codice sorgente, considerarlo come un problema operativo e di distribuzione. Non dovresti aver bisogno di impegnare il codice per risolvere i problemi causati da una cattiva distribuzione. Come è possibile modificare la pipeline di distribuzione in modo da poter tornare a una versione precedente per risolvere il problema?

Puoi vedere come google e facebook eseguono le distribuzioni. Facebook, ad esempio, invia nuove funzionalità alla produzione una volta alla settimana ed è generalmente piuttosto stabile.

Se guardi come ottengono questo gli elementi chiave sono:

Revisioni del codice e test unitari per il controllo della qualità prima della spedizione
Avvio interno prima dell'avvio esternamente per rilevare gli errori prima
Implementazione graduale in modo che le nuove versioni non vengano visualizzate contemporaneamente da tutti i server / utenti
Feature flag per attivare e disattivare nuove funzionalità o nuove versioni di funzionalità esistenti in produzione, senza modificare il codice distribuito. I link di Facebook presentano flag nei profili, in modo che il profilo di un utente determini quale set di funzionalità vedono.
Avvio graduale, sfruttando il sistema di contrassegno delle funzioni per mostrare le nuove funzionalità solo a un sottoinsieme di utenti. Ciò consente modelli come le funzionalità di spedizione che non sono ancora localizzati per utilizzarli con un uso effettivo.
Dark launches, shadow production e doppie tecniche di scrittura / lettura per far funzionare parallelamente la vecchia e la nuova versione del codice e dello schema del database in produzione. Gli utenti vedono l'output delle vecchie versioni finché il vecchio e il nuovo non sono d'accordo, e poi vengono passati alla nuova versione.

score 3 · Answer 3

Se il QA manuale fa parte del processo, in realtà non dovrebbe far parte della pipeline di rilascio automatizzata. È comunque possibile eseguire build e implementazioni automatizzate in un ambiente di controllo qualità, ma in una pipeline separata. Quindi, non c'è nulla da ripristinare se il QA rifiuta qualcosa. Inviate materiale alla vostra pipeline di rilascio solo se è "terminato" e parte di quella definizione di "fatto" dovrebbe passare il QA.

Questo porta anche a un punto più ampio che se qualcosa viene rifiutato dal QA, c'è un difetto fondamentale nel processo. Le build automatizzate, i test, l'integrazione e la distribuzione dovrebbero cogliere tutti i maggiori problemi. Il QA dovrebbe davvero fare solo test di esplorazione, e qualsiasi cosa trovata da questo può essere aggiunta come elementi di backlog per una futura iterazione del prodotto. I bug di Showstopping dovrebbero essere stati catturati da dozzine di passaggi diversi prima del controllo qualità manuale.

Torna alla tua pipeline, avere una pipeline QA e una pipeline di rilascio significa avere più di un ramo del tuo codice. Tuttavia, con Git quel "ramo" può essere leggero come una richiesta di trazione. La tua pipeline di QA può quindi integrare le richieste di pull e avviare la costruzione e la distribuzione per ciascuna o qualsiasi combinazione di esse (rollup). Solo quando la richiesta pull passa al QA manuale, la si unirà effettivamente, il che causerebbe il passaggio alla pipeline di rilascio.

Se le cose continuano a spostarsi lateralmente, la soluzione migliore è roll-forward. In altre parole, se si desidera il controllo qualità come parte della pipeline di rilascio, è necessario impegnarsi in una strategia di non ripristino. Se qualcosa viene "rifiutato", deve essere corretto e integrato nuovamente per spingere un nuovo rilascio attraverso la pipeline. È un po 'più rischioso, ma se hai una buona configurazione, non dovresti aver bisogno di farlo spesso, e le correzioni dovrebbero essere semplici.