Strategia di rilascio per più rami di feature Git testati simultaneamente

Ahh. Congratulazioni! Hai distrutto un collo di bottiglia e scoperto il prossimo! Ora è il momento di guardare in realtà in modo continuo per integrare il tuo codice. Come hai scoperto, è difficile fornire continuamente quando il tuo codice sotto dev non viene continuamente integrato, ma come fai questo lavoro?

Nessun altro ramo di funzionalità.

No. Sul serio. Niente più rami di funzionalità.

È giunto il momento di introdurre funzione attiva / disattiva nel tuo sistema. Invece di fornire nuove funzionalità distribuendo il codice, è necessario avere il controllo completo su quando una funzionalità viene attivata per un determinato ambiente. In altre parole, si desidera avere una configurazione specifica per l'ambiente che attiva e disattiva le funzionalità. Questo disaccoppia le versioni di codice dalle versioni di funzionalità.

Prova le funzionalità separatamente e in ordine, questo è davvero il modo migliore per farlo. Di solito, prima si esegue prima il test, ma le esigenze aziendali potrebbero cambiare questa priorità. Quando viene accettato FeatureA , viene unito al ramo principale ( dev , UAT o master nel tuo caso, a seconda del caso), quel ramo viene fuso in FeatureB e quindi viene testata la caratteristica B. A viene prima testato, poi B, poi C, ecc., Con l'aggiornamento di ogni ramo di funzionalità man mano che vengono testate e accettate altre funzionalità.

Testando separatamente le funzionalità, tieni l'attenzione su una funzione e un team è responsabile della risoluzione di eventuali problemi. Esiste una chiara responsabilità per mantenere il codice in buono stato quando si gestiscono conflitti di unione (in questo caso, il team featureB deve unire dev e gestire eventuali conflitti di unione, assicurandosi che il codice da featureA sia mantenuto ). Funzionalità separate facilitano anche l'assegnazione della "colpa" quando viene scoperto un problema - non il "perché hai rotto questo" tipo di colpa, ma "questa funzione sta causando un problema, rimuovila da dev finché non riusciamo a ordinare "tipo di colpa

Se stai riscontrando che un sacco di FeatureX di filiali vengono spese in attesa del test o più rami vengono completati allo stesso tempo, puoi suddividerli in funzionalità più piccole o allocare più risorse per il test. Entrambi gli approcci dovrebbero ridurre il tempo di testare un singolo ramo.

Le funzionalità simili che saranno completate nello stesso momento potrebbero essere sviluppate al meglio su un singolo ramo. Questo è un po 'quello che proponi con il ramo FeatureAandB , ma in questo caso vengono accettati o rifiutati come uno. Se le funzionalità non sono simili / correlate, tuttavia, testarle separatamente.

Infine, assicurati di utilizzare qualsiasi automazione disponibile, in modo che i team non stiano aspettando un altro team per qualcosa. La maggior parte dei server di build può essere impostata per creare rami Richiesta di pull, producendo una build FeatureA+dev che può andare a QA per i test di accettazione e integrazione. Lo sviluppatore apre semplicemente il PR (che funge anche da revisione del codice, se lo desidera, e serve anche a segnalare che la funzione è pronta per il test), e una volta che il QA ha firmato, lo completa. Questo quindi unisce automaticamente il ramo in dev . Può fare lo stesso per UAT e master , creando PR per unire dev in UAT e UAT in master .

Potresti quindi essere in grado di ridurre il numero di rami e restare con dev e master , più featureX . Sbarazzati di UAT , dato che quel ruolo è essenzialmente servito da dev . Lo sviluppo effettivo avviene su featureX e la produzione è in master . Distribuisci il nuovo codice ogni volta che master viene aggiornato, o distribuisci ciò che è in master ogni volta che vuoi rilasciare.