Flusso di lavoro Git (flusso) per lo sviluppo web

Questo è molto simile a un modello di branching git riuscito che abbiamo impiegato in il mio posto di lavoro: funziona a meraviglia per noi (anche se differiamo leggermente dalla ramificazione e inseriamo il git tag sul server di produzione in modo che gli sviluppatori non tocchino live e aggiorni git tramite il server di produzione (e possibilmente fubar i rami)).

Durante lo sviluppo

Il tuo metodo proposto è fantastico. Ogni sviluppatore ha il proprio posto di lavoro (sul server) e ha le proprie [funzioni] filiali - questo sarà di grande aiuto in quanto sarai in grado di tenere traccia di quali funzioni sono in sviluppo, dove sono nel ciclo di sviluppo e chi è è responsabile per loro (sebbene tu adotti un flusso di lavoro agile, lo saprai, è bello sapere quando guardi indietro nel passato).

Gli sviluppatori che hanno il proprio ramo [caratteristica] durante lo sviluppo ti permetteranno di lavorare su diverse funzionalità senza sovrascrivere il lavoro altrui.

Questo stage va bene, nessun avvertimento

Durante il test

I test possono diventare confusi, perché cosa succede se trovi un bug importante che necessita di patch ma X è pronto per essere pubblicato? Chi è responsabile per i test?

Correzione di un bug durante il test

Quando hai il tuo ramo testing sul server di test e trovi un bug che necessita di patch, può essere risolto in 2 modi;

• Estrazione del ramo testing in un bug fix (bf- ) branch. Quando si verifica un bug, solitamente I crea un problema che specifica cosa deve essere applicato alle patch e assegna un nome al bug fix branch (ad es. : numero aperto 293, il ramo sarà bf-293 ). Ciò ti aiuterà molto a tenere traccia di ciò che è stato corretto.
• Applica direttamente il ramo testing .

Test di più funzioni

Di nuovo, molto facile da fare con il tuo modello di ramificazione proposto. Assicurati di creare una richiesta di pull / merge per documentare quale codice è stato modificato (questo mi ha salvato bacon molti volte in passato) e in quale fase del ciclo di vita dei prodotti è stata sottoposta a test e produzione una particolare caratteristica.

Una volta che tutte le funzioni sono state unite nel ramo development , assicurati di creare un nuovo ramo testing (di solito chiamo questi candidati al rilascio. Vale a dire: stiamo testando la v2.42, chiamerò questo ramo test rc-2.42 ) e spingere fino al server di prova.

Questo stage va bene, nessun avvertimento

Vai in diretta

Il live con git è fantastico. Quando sei soddisfatto dei risultati del test e sei pronto a fare push, assicurati di aprire una richiesta di pull / merge in modo che sia documentato cosa sta succedendo quando (come accennato in precedenza).

! Se hai corretto alcuni bug durante i test, assicurati di unire nuovamente il ramo testing in development . Non vuoi le cose che sono in master e non in development - le cose diventeranno disordinate e confusionano molto rapidamente.

Una volta uniti in master , assicurati di taggalo per creare un punto in tempo per tornare a (spiegherò più tardi). Quando vai in diretta, assicurati di effettuare il checkout nel nuovo tag in modo da non poter applicare patch live senza passare attraverso la procedura git.

Quando sei andato in diretta, mi piace creare un post nella wiki per documentare la nuova versione e collega la richiesta di pull / merge . Sarà molto più facile rintracciare ciò che è andato in diretta.

Perché utilizzare il tag?

Il tagging crea un punto nel tempo che è molto facile da ripristinare su dovrebbe qualcosa di terribilmente sbagliato sul server di produzione. Gestisce anche la tua visione e bello guardare indietro nel tempo per vedere cosa è andato in diretta quando.

Conclusione;

• Il tuo modello di ramificazione va bene
• Assicurati di aprire inserire / unire richieste prima di unire
• Assicurati di taggare il tuo master ramo
• Assicurati di documentare la spinta alla produzione (nella wiki)
• Durante l'applicazione di patch (correzione rapida o correzione di bug), assicurati di creare un problema per documentare il bug.

Il modello standard di git flow dovrebbe funzionare correttamente in base a ciò che hai detto. Ecco come lo usiamo:

1. Tutto il lavoro viene svolto sullo sviluppo (o su un ramo di funzione se vogliamo eseguire una versione prima che una determinata funzione sia completata).
2. Quando siamo pronti a chiamare qualcosa di un rilascio, creiamo un ramo di rilascio da sviluppare e distribuire questo per testare.
3. Tutti i bug che vengono generati durante il test vengono triagicati e fissati sul ramo di rilascio o - se possiamo vivere senza risolverli - nascosti per una versione successiva. Durante questo periodo, può essere avviato un ulteriore lavoro per lo sviluppo (con eventuali correzioni del rilascio che vengono reinserite regolarmente per evitare una mega-fusione successiva).
4. Il ramo di rilascio viene distribuito nel nostro ambiente di accettazione: lo stesso ciclo si verifica, ad eccezione dei test eseguiti dai clienti.
5. Quando tutti sono soddisfatti del ramo di rilascio, vengono uniti per essere masterizzati / sviluppati e distribuiti per la produzione.

Questo è abbastanza flessibile - è anche molto robusto perché la tua versione - > master merge è sempre un avanzamento rapido (quindi nessuna regressione o conflitto quando si va in produzione) e ti costringe a testare solo una versione alla volta, il che significa che non si finisce con le modifiche su un ramo di release precedente che danneggia il test validità su una successiva. Significa anche che il test è stabile in qualsiasi momento e non soggetto a un flusso di distribuzioni che rischia di compromettere i test.

Le cose diventerebbero piuttosto complicate se avessi iniziato a fare correzioni di bug sulle feature branch - hai quindi dovuto fondere quei rami nella release tramite lo sviluppo che potrebbe avere altro lavoro su di esso ... Una volta che le tue feature branch saranno unite, esse sono effettivamente "completati" e qualsiasi ulteriore lavoro, anche su quella caratteristica, dovrebbe essere fatto sullo sviluppo, su un nuovo ramo di funzionalità o direttamente in un ramo di rilascio prima di andare in diretta.