Hotfixing con un ramo di rilascio aperto mentre questa versione è attualmente testata

1

Stiamo utilizzando gitflow e attualmente abbiamo un ramo di rilascio aperto.

IlrilasciodiAèattualmentesulsistemaditestperesseretestatodagliutentichiave.Nelfrattempoabbiamobisognodirilasciareunhotfixurgente.Comunementeestraiamounramodelmaster(quindil'ultimaversionedelsistemalive)elouniamoallosviluppoealmaster.Selofaremoqui,nonavremmol'aggiornamentorapidonellaversioneattualmenteaperta.

Quindicosadevofarenelpuntocontrassegnatocome"?" nell'illustrazione? Si supponga che l'aggiornamento rapido sia pronto per essere unito.

    
posta OddDev 25.08.2016 - 08:38
fonte

2 risposte

1

Sì, il flusso di lavoro gitflow sembra mancare questo senario.

Un ramo di aggiornamento rapido viene unito nuovamente al master e si sviluppa una volta completato. Ma non il ramo di rilascio!

Una volta completato il tuo ramo di rilascio, questo verrà unito al master e potenzialmente avrà un conflitto o introdurrà un bug, quindi questa non è una buona cosa.

Suggerirei di unire il master nel rilascio dopo aver completato l'aggiornamento rapido. questo porterà il tuo ramo delle funzionalità aggiornato con il master e ti consentirà di testare l'aggiornamento rapido nella nuova versione.

Tuttavia, un'alternativa sarebbe quella di unire l'aggiornamento rapido in master, sviluppare AND il ramo di rilascio. puoi vedere che questo sarebbe difficile da automatizzare poiché il nome del ramo di rilascio cambierà ogni volta.

(molte persone preferiscono rebase per unire, ma non permettono di entrare in quello)

** modifica **

C'è un'altra possibilità se trovi che questo sta accadendo molto.

  • Ripristina la versione live a quella precedente.
  • Aggiungi la correzione alla prossima versione
  • Distribuisci la correzione con la prossima versione

Ovviamente questo ti lascia con una vecchia versione dal vivo, ma se fai costantemente delle correzioni rapide ti indica un problema nel tuo processo di test e rilascio.

Spingere per i rollback anziché le hot fix può essere una buona cosa. Tutti sono più felici quando le versioni vengono distribuite senza problemi e senza fretta per completare i rilasci delle correzioni rapide, ma la correzione rapida essenzialmente nasconde i problemi al business. Se si richiede un rollback, questo può focalizzare l'attività lasciando più tempo per i test e il completamento delle funzionalità. Nel lungo periodo questo può aumentare la velocità di sviluppo.

    
risposta data 25.08.2016 - 10:13
fonte
1

Trovato! In realtà Atlassian si sta riferendo al loro tutorial a un post sul blog di Vincent Driessen presso nvie . E indovina cosa? Lui è la risposta!

The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)

Dal capitolo Creazione del ramo dell'hotfix

    
risposta data 02.09.2016 - 13:48
fonte

Leggi altre domande sui tag