Modello di branching Git per team con fasi di sviluppo, test e distribuzione

0

Un pezzo di codice sviluppato fa parte di queste fasi nel nostro team:

  1. Gli sviluppatori scrivono il codice
  2. Quindi lo inviano ai tester
  3. Se i test passano, i tester inviano la modifica / nuova funzionalità / bugfix al team operativo per la distribuzione.

Attualmente abbiamo adottato il seguente approccio:  Abbiamo un ramo master da cui creiamo uno o più rami personalizzati per rendere i nostri nuovi commit. Quindi inviamo una richiesta pull al ramo release insieme all'attività per testare il codice appena sviluppato. Se i test superano i tester si uniscono al ramo release , creare una richiesta pull da release a master e aprire un'attività di distribuzione. Dopo la distribuzione, le modifiche vengono unite in master .

Ma c'è un problema qui. Non siamo mai sicuri che la produzione esegua il codice presente nel ramo master , perché è coinvolto un fattore umano. Quindi la prossima volta quando voglio creare un ramo da master dovrò verificare se tutte le modifiche precedenti si riflettono in esso.

Qualcuno può suggerire un flusso migliore? Quali sono le migliori pratiche per questo tipo di situazioni?

P.S. So che automatizzare l'intero ciclo di sviluppo della distribuzione del software risolverà probabilmente molti problemi, incluso questo, ma al momento siamo un po 'lontani dalla piena automazione.

    
posta Mikayil Abdullayev 16.11.2018 - 11:37
fonte

1 risposta

1

Non sono sicuro che Feature Flags, Toggles, Controls sia qualcosa che hai esaminato. Ma potrebbe essere utile conoscerli, poiché risolvono il problema della ramificazione / fusione in un modo completamente diverso!

C'è anche un bell'articolo Toggles (aka Feature Flags) , scritto da Martin Fowler.

    
risposta data 16.11.2018 - 15:53
fonte

Leggi altre domande sui tag