Git strategia di ramificazione per codice in uscita di lunga durata

14

Nel nostro team, oltre alle singole unità di lavoro (Storie), abbiamo temi di lavoro più lunghi (Epics). Le storie multiple sono epiche.

Tradizionalmente, per ogni storia abbiamo avuto branch di funzionalità e li abbiamo uniti per diventare master quando passano a QA. Tuttavia, vorremmo iniziare a trattenere il rilascio di storie completate in un'epica finché l'Epic non sarà considerato "feature complete". Rilasceremo queste funzionalità solo quando l'intera Epic verrà chiusa. Inoltre, abbiamo un server notturno per la compilazione: vorremmo che tutte le storie chiuse (incluse quelle che fanno parte di Epics incompleti) venissero distribuite automaticamente su questo server notturno.

Ci sono suggerimenti su come gestire il nostro repo per raggiungere questo obiettivo? Ho preso in considerazione l'introduzione di "rami epici", in cui avremmo unito le storie chiuse al relativo ramo epico anziché diretto al master, ma le mie preoccupazioni sono:

  • Mi preoccupo dei conflitti di fusione che possono sorgere se i rami epici vengono tenuti aperti a lungo
  • Le build notturne richiedono la fusione di tutti i rami epici in un ramo "nightly build". Ancora una volta, potrebbero sorgere conflitti di unione, e questo deve essere fatto automaticamente
posta Sitati 12.01.2016 - 13:43
fonte

3 risposte

20

Suggerimento semplice: non farlo.

Le filiali git non sono per le forcelle a lungo funzionamento del codice, come discusso qui e link . Le filiali sono trattate al meglio come cose transitori utilizzate per organizzare le commit da parte di uno sviluppatore individuale a livello giornaliero. Quindi se hanno un nome che corrisponde a qualcosa di un project manager (figuriamoci l'utente finale) potrebbe preoccuparsi che tu stia facendo qualcosa di sbagliato.

La pratica consigliata è quella di utilizzare l'integrazione continua con attiva / disattiva o branch-by-astrstration per garantire che:

  • tutto il codice è sempre integrato (almeno ogni giorno, preferibilmente più spesso)
  • ciò che viene implementato è sotto il controllo esplicito.
risposta data 12.01.2016 - 14:24
fonte
1

Penso che questo sia un problema piuttosto comune e si riduce alla scelta delle funzionalità da includere in una versione dopo che le funzionalità sono state codificate piuttosto che prima.

ad es.

Ho le caratteristiche A, B e C per la v2 del mio prodotto. B e C sono correlati, non voglio rilasciare B a meno che C sia anche finito.

Ho tre sviluppatori che lavorano tutti contemporaneamente sulle funzionalità.

Ho una data di rilascio del set D

B è finito e unito, A è finito e unito. C è in ritardo ... cosa faccio?!

Non credo che ci sia una soluzione tecnica a questo problema. Si desidera rilasciare una versione non testata del prodotto con solo la caratteristica A inclusa. A meno che non si unisca e test tutte le possibili combinazioni di funzionalità, questa sarà sempre una possibilità.

La soluzione è più umana. Hai perso la tua data di rilascio e devi reinserirla.

    
risposta data 12.01.2016 - 14:51
fonte
1

Questo è un problema difficile ma che molte persone affrontano. Preferisco usare la configurazione di Gitflow come punto di partenza.

Sviluppo - > Nuove cose su cui si sta lavorando Master - > Roba finita che necessitano di test Produzione - > Cose che sono state pubblicate per la produzione.

In caso di funzionalità minori (più brevi) creo un ramo dallo sviluppo eseguo il lavoro e quindi uniamo il ramo allo sviluppo.

Alle funzioni principali (a lungo termine) creo un ramo dallo sviluppo, creo rami più piccoli da quel ramo, quindi unisci di nuovo al primo ramo. Una volta che la funzionalità principale è completa, torna nel ramo di sviluppo.

A intervalli regolari (dipende dal progetto) Unisco lo sviluppo al master e inizia un ciclo di test. Se si verificano delle correzioni durante il test, queste vengono eseguite nel ramo principale (sottoramo e quindi unione). E lo sviluppo può continuare sul ramo principale durante i test.

In qualsiasi momento, il master deve essere unito allo sviluppo e lo sviluppo deve essere unito a una qualsiasi delle sue sub filiali a lungo termine.

il maestro dovrebbe sempre (in teoria) essere pronto per la produzione. Lo sviluppo dovrebbe sempre (in teoria) essere pronto per la produzione. L'unica ragione per cui esiste una differenza consiste nel fornire un solido set di funzionalità per i tester da testare.

Quando è pronto, un commit nel master testato viene unito alla produzione e l'implementazione nella produzione avviene da quel ramo. Gli HOTFIX che devono essere eseguiti in caso di emergenza possono quindi avvenire sul ramo Produzione senza dover unire in master (che potrebbe avere molte modifiche non testate).

Il mio albero normale sembra

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production  

È la mia regola generale che nessun singolo cambiamento dovrebbe richiedere più di qualche ora. Se lo fa, deve essere trasformato in piccole modifiche. Se si tratta di una funzionalità enorme (come una riscrittura dell'interfaccia utente), ciò andrà a lungo termine in modo che lo sviluppo normale possa continuare allo stesso tempo. Le filiali LongTerm sono normalmente solo filiali locali mentre Sviluppo, Master e Produzione sono filiali remote. Eventuali sottogruppi sono anche solo locali. Ciò mantiene il repository pulito per gli altri, senza perdere l'utilità di git su un set di funzionalità a lungo termine.

Vorrei sottolineare, tuttavia, che l'esistenza di un ramo a lungo termine è una cosa rara. Normalmente, tutto il mio lavoro è in sviluppo. Solo quando ho una feature (set) che richiederà così tanto tempo che devo essere in grado di lavorare anche su normali risorse Dev, uso il ramo LongTerm. Se è solo un insieme di cambiamenti che dovrebbero stare insieme, allora non mi unisco a padroneggiare fino a quando tutto è finito.

    
risposta data 12.01.2016 - 19:12
fonte

Leggi altre domande sui tag