Strategia di ramificazione per rilasci frequenti [duplicato]

Question

Strategia di ramificazione per rilasci frequenti [duplicato]

#1 da (4 voti)
#2 da (0 voti)

0

Abbiamo rilasci molto frequenti e usiamo Git per il controllo della versione. Quando parlo della frequenza, si supponga di includere anche correzioni di bug e rilascio di funzionalità. Tutte le versioni vengono infine incorporate in "mainline". Quando un rilascio viene distribuito in produzione e se viene identificato un bug, le persone iniziano a correggere il bug sullo stesso ramo da cui è stata distribuita l'ultima versione in produzione. Non creano un nuovo ramo di bug-fix per lo stesso. Sento che non è il modo giusto per andare. Ci sono diversi componenti e ogni componente ha un proprietario diverso, e quindi una prospettiva diversa. Anche se non ho avviato colloqui con loro, sono sicuro che ci sarà molta resistenza. Il problema principale che potrebbero citare sarebbe: "C'è un sacco di lavoro nel creare e tenere traccia delle filiali, specialmente quando ci sono dispiegamenti così frequenti sulla produzione. Ciò consumerà molto impegno. "

Pensi che correggere bug sullo stesso ramo da cui è stata rilasciata, sia una buona idea? Se sì, come lo gestisci? Utilizzo dei tag?

So che le migliori pratiche potrebbero non essere sempre applicabili a causa di diversi fattori, ma vorrei comunque sapere quale potrebbe essere un buon approccio per la ramificazione in uno scenario in cui rilasci / correzioni di errori si verificano quasi quotidianamente.

Modifica: ringrazia tutti per aver condiviso le tue visualizzazioni e i link utili. Penso che la preoccupazione principale che ho qui è questa: Pensi che correggere bug nello stesso ramo da cui è stata rilasciata, sia una buona idea? Questo approccio va bene nel lungo periodo o stiamo facendo scherzi? le cose solo per rendersene conto più tardi?

git version-control branching release merging

posta Technext 13.06.2014 - 16:38

fonte

2 risposte

Leggi altre domande sui tag git version-control branching release merging

Web server dormiente? Dati statici e dinamici: dovrei usare diversi database?

score 4 · Answer 1

La cosa importante qui è avere un flusso di lavoro coerente che possa essere facilmente seguito sia dai neofiti che dai veterani nelle vostre organizzazioni. Scegli un processo che soddisfi le tue esigenze e assicurati che il flusso di lavoro abbia senso per modifiche sia banali che più complesse.

Detto questo, ci sono alcuni flussi di lavoro standard là fuori. Eccone alcuni:

GitHub Flow

GitHub Flow è un flusso di lavoro leggero e basato su filiali che supporta team e progetti in cui le implementazioni vengono eseguite regolarmente. Scott Chacon spiega le differenze da Git Flow qui .

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day – often several times a day.

Questo sito offre una straordinaria panoramica visiva per GitHub Flow.

Git Flow

GitFlowdefinisceunrigidomodellodiramificazioneprogettatoattornoalrilasciodelprogetto.Ciòfornisceunastrutturasolidaperlagestionediprogettipiùgrandi.Definisceramispecificiperrilascio,sviluppo,hot-fix,ecc.Eletransizionitraloro.

Esistononumeroseestensioniestrumentigitdisponibilionlinepersupportarequestoflussodilavoro.Daiun'occhiataall'estensione nvie / gitflow per un punto di partenza.

Puoi ottenere una spiegazione dettagliata delle varie fasi e ruoli nel flusso di lavoro qui e < a href="http://nvie.com/posts/a-successful-git-branching-model/"> qui .

score 0 · Answer 2

Il reintegro più volte al giorno nella linea principale è una strategia pienamente valida - ha effettivamente un nome, si chiama continua integrazione . Se questa è una buona strategia per la tua squadra o meno dipende principalmente da quanto bene sono gli strumenti automatici per la garanzia della qualità, e se il tuo team è abituato a fornire "piccoli passi". Per applicare CI con successo, si dovrebbe avere un server di build automatico in esecuzione, un sacco di test automatici di integrazione e unità e idealmente qualcosa come un modo (semi) automatico di distribuzione (che include il controllo delle versioni e dei tag).

Se non è così, probabilmente è meglio applicare un modello più conservativo e lavorare con diversi rami, offrendoti la possibilità di raccogliere funzionalità e correzioni di bug in luoghi separati prima che venga presa la decisione finale se un cambiamento specifico sarà integrato nella linea principale (o meno).

Naturalmente è possibile combinare queste strategie. Ad esempio, lascia che il server CI gestisca la linea principale da cui viene consegnato il software. Sviluppa ogni "nuova funzionalità" in un ramo di sviluppo o rami di funzionalità separati. Questi ultimi vengono reintegrati nella linea principale quando hanno raggiunto una certa qualità. Bugfix urgenti vanno direttamente nella linea principale (e presto consegnati da lì) - perché sono urgenti. I rami di funzionalità impediscono al tuo team di introdurre funzionalità semi-cotte nella linea principale (e quindi involontariamente in produzione a causa di una consegna urgente di correzioni di errori). Le modifiche dalla linea principale dovrebbero essere almeno una volta al giorno essere reintegrate in tutti i rami delle funzionalità.

Sono possibili altri modelli più sofisticati, a seconda del numero di stakeholder coinvolti (ad esempio, hai un team di QA? Come funzionano? Quale stato del software testeranno?). Quello che devi fare è pensare al tuo ambiente e quale modello ti si addice meglio: quali obiettivi hai, quali problemi vedi con il modello attuale e cosa vuoi migliorare.