Quali sono i rischi di avere un ramo di rilascio?

...often there are untested changes waiting in the test branch which delays delivery of hot fixes for critical bugs in production.

Is there a method that allows for easy hot fixes and not introduce the risk of untested differences when having a separate release branch?

Sì, c'è. Il problema che hai riscontrato è causato da un bug nel flusso di lavoro:

feature1 \
feature2 --> test --> release
hotfix1  /

Come hai visto, se le funzionalità impiegano tempo per testare accuratamente, fungono da barriera per ottenere la correzione a caldo attraverso la pipeline. Il takeaway è che se hai bisogno di ottenere un rilascio in fretta, non ci dovrebbe essere nulla nella pipeline di rilascio che non è molto vicino a essere pronto.

Puoi evitarlo spostando la barriera davanti alla parte di rilascio della pipeline in modo che eventuali ritardi nel test di una modifica rimangano con la modifica:

feature1 --> feature1-test \
feature2 --> feature2-test --> release-test --> release
hotfix1  --> hotfix1-test  /

Quando un cambiamento è finito, entra in un ramo separato dove viene testato. Finché i test sono in corso, tutto il lavoro su quel cambiamento avviene tra i due rami. Dopo che il test lo ha approvato, il codice testato viene fuso in un ramo di test pre-release in cui la batteria di test completa viene eseguita ancora una volta prima del rilascio. (In teoria, questa dovrebbe essere una formalità e un non-evento, spiegherò perché più tardi.) Ciò significa che puoi impiegare un tempo lungo per testare feature1 senza ritardare feature2 o hotfix .

Una cosa importante che viene spesso trascurata è il feedback. Ogni volta che avviene un rilascio, quel codice deve essere unito a tutte le filiali in cui vengono effettuati lo sviluppo e i test. Se hotfix1 rompe feature1 , vuoi scoprirlo in feature1-test in modo che possa essere corretto lì e non ostacolerà il rilascio di un rilascio contenente hotfix2 . Se la funzione integra le modifiche rilasciate in anticipo, ci dovrebbero essere meno sorprese in release-test . Questa disposizione consente di trattare gli hotfix e le funzionalità allo stesso modo da una prospettiva di sviluppo e lascia la decisione se sottoporre un hotfix alla batteria piena di test o sottoporre a una rapida procedura una questione di politica QA. Il flusso di lavoro è lo stesso, non importa cosa, e non c'è un ramo / fusione veloce da / verso il ramo release .

NB: Ciò che viene descritto qui è un po 'troppo semplicistico perché non tiene conto di qualcosa in feature1 che spezza qualcosa in feature2 . Questa disposizione può essere utilizzata in strutture più complesse dove release-test diventa integration-test e che alimenta release-test .

In un ambiente come il tuo, con la tua strategia di ramificazione, gli hotfix di produzione dovrebbero avvenire sui rami hotfix fuori dal ramo di rilascio. Una volta testati e approvati, tali modifiche dovrebbero essere riunite nei rami di sviluppo e test a monte. Questa è una strategia di ramificazione altamente conservativa. E la fusione extra è uno dei compromessi che fai per avere quel livello di sicurezza nelle tue uscite.

La causa principale dei tuoi problemi è l'uso di feature branch (alcune persone, me incluso, li considerano "malvagi"). Unirli insieme per ottenere il tuo singolo ramo di rilascio è il collo di bottiglia: le fusioni di filiali sono punti di discontinuità nei livelli di qualità che non possono essere evitati, richiedono quantità sconosciute di lavoro / risorse, devono essere serializzati, non possono essere pianificati correttamente, ecc. quel backlog di funzionalità non testate / in corso che diventa un ostacolo tra le tue correzioni rapide e il tuo ramo di rilascio.

Spesso le persone dimenticano che un cambiamento che funziona correttamente in un ramo non è garantito che funziona altrettanto bene (o del tutto!) in un altro ramo. Un'intera funzionalità può funzionare perfettamente nel proprio ramo di sviluppo, ma può essere completamente rovinata quando viene unita a tutte le altre funzionalità che devono essere rilasciate. E non puoi nemmeno individuare quale cambiamento individuale sta causando il problema: devi adottare un approccio tutto o niente: o annulli l'unione (cioè non integrando nessuna delle modifiche del ramo) o accetti l'unione (con tutti i suoi cambiamenti), prendendo il colpo nel livello di qualità che è necessario affrontare, sempre senza alcun potenziale sospetto in mente.

In un approccio di integrazione continua non ci sono rami di caratteristiche da unire: nessun arretrato, nessun ostacolo di questo tipo. Tutte le modifiche vengono mantenute ridotte e possono essere inserite nel ramo singolo in qualsiasi momento, indipendentemente dal fatto che si tratti di un aggiornamento rapido o di una parte di una nuova funzionalità. Le unità difettose vengono immediatamente identificate e indirizzate, l'automazione può aiutare immensamente (sì, in CI c'è sempre un molto breve ma mai vuoto elenco sospetto). Non ci sono punti di discontinuità a livello di qualità, la qualità viene costantemente misurata / monitorata e può persino essere applicata automaticamente, tramite strumenti.

Anche se non è possibile utilizzare la singola direttrice principale / principale come veicolo di rilascio effettivo e sono necessari rami di rilascio (perfettamente normale quando la distribuzione continua non è un'opzione, ad esempio nei casi di sviluppo del software o del sistema operativo integrato) può ancora utilizzare l'integrazione continua a livello di release. Ciò significa che mai rebase / reparent un ramo di rilascio, o unire in esso qualche altro ramo di funzionalità / integrazione per introdurre una serie di modifiche che sembrano funzionare correttamente (nel contesto di quell'altro ramo).

Ogni modifica, hotfix o parte di uno sviluppo di "funzionalità tardiva", sviluppato specificamente per un ramo di release o ported / double commit da qualche altro ramo, passa attraverso gli stessi controlli applicati nel particolare contesto del ramo di rilascio ricevente . Ciò garantisce in definitiva il livello minimo di qualità per tale versione. Ecco perché credo che CI / CD sia il modo più veloce per rilasciare software in modo affidabile.