Flusso di lavoro Git con team di distribuzione continua

Tendo a trovarlo che funzioni bene per trattare develop come sandbox che vuoi mantenere in ordine. Sì, lo si desidera utilizzare per archiviare tutte le funzionalità unite da altri rami, ma si ha anche l'obiettivo di trasformarlo in un prodotto che il QA può accettare e spostare all'ingrosso nel ramo di produzione. Se una funzione non sta guadagnando, è probabile che tu voglia spostarla effettivamente da develop e nel suo stesso ramo, solo per mantenere develop abbastanza pulita da essere utilizzata all'ingrosso.

Tratta develop non come punto finale per le modifiche sviluppate, ma come punto di partenza per la vendita di tali modifiche al QA. Lavora con loro per scoprire che tipo di repository-fu accettabile per loro, e cosa no. Ad esempio, se hai una funzione che non dovrebbe andare in develop , ma vieni comunque lì, cerca di capire che cosa QA vuole vedere per essere convinto che la funzione sia stata rimossa (e inserita nella sua stessa diramazione).

A seconda di quanto sia rigoroso il QA, potresti aver bisogno del 2% didevelop di filiali. Una è la versione che è pronta per il QA da usare e quella che gli sviluppatori usano internamente. Si mantiene questa versione interna "chiusa" per lo sviluppo. L'idea dovrebbe essere che se il QA accetta le modifiche su develop , allora tu e QA progredite continuamente in lockstep. Tuttavia, se il QA ha bisogno di modifiche importanti (come il rifiuto di una funzionalità), è necessario essere pronti per forzare il ramo sviluppatore (che è ormai obsoleto) e ricrearlo dall'ultimo ramo QA accettato. Costoso, sì. Se sei in un'azienda in cui il controllo qualità è così rigido da rendere difficile lo sviluppo, probabilmente sei in un'azienda che è disposta a pagare il costo per integrare due volte le modifiche dai tuoi rami.

È necessario distribuire la stessa cosa nell'ambiente live che si è avuto nell'ambiente di test. Se inizi a scegliere e scegli il codice da distribuire per vivere, il test diventa privo di significato, dal momento che hai testato un pacchetto nel suo complesso e ora hai creato qualcosa di diverso da spingere per vivere.

Rinuncia all'idea di "controllare quali modifiche saranno distribuite alla produzione". Se non vuoi che qualcosa venga distribuito in produzione, non scrivere il codice per primo.

Ovviamente questo non significa che devi rinunciare al controllo di quali funzionalità vengono rilasciate alla produzione. Innanzitutto prova a scrivere solo le funzionalità che desideri rilasciare. In secondo luogo, ricorda che per molte funzionalità esiste una sola riga di codice che può essere cancellata o inserita all'interno di un'istruzione "if" per disattivare l'intera funzione. Nei casi peggiori potresti dover utilizzare un sistema di "attivazione / disattivazione della funzionalità" per disattivare tutte le funzioni che non sono pronte per il rilascio.