Come sbarazzarsi del ramo di sviluppo per un flusso Git semplificato

In un progetto web continuamente sviluppato (non un prodotto) attualmente abbiamo la seguente strategia di branching, approssimativamente basata sul flusso git :

• sviluppare ramo: ultima versione funzionante
• ramo principale: versione da rilasciare / versione rilasciata
• rami delle caratteristiche: caratteristiche in sviluppo
• hotfix branch: correzioni di bug urgenti nella versione rilasciata

Il master è di sola lettura, aggiornato tramite richieste pull dai rami di sviluppo o hotfix . Ogni aggiornamento comporta la creazione e la distribuzione di un candidato al rilascio nel sistema di gestione temporanea. I candidati al rilascio vengono distribuiti in produzione dopo l'approvazione manuale.

I rami delle caratteristiche vengono creati in base allo sviluppo o dall'ultimo commit che è stato unito in master. Viene sviluppata una richiesta pull da un ramo di funzionalità da sviluppare, distribuita a un sistema di test gratuito in cui vengono eseguiti test di integrazione e test di accettazione (automatici e manuali). Una volta testato e rivisto con successo, il PR viene unito, in modo da diventare parte della prossima versione (ovvero unire dallo sviluppo al master).

Il mio obiettivo

Vorrei semplificare questo aspetto e liberarmi del ramo di sviluppo. Il ramo di sviluppo ha principalmente ragioni storiche e poiché è sempre una versione testata con successo, penso che non sia necessario tenerlo separato dal master. La sua rimozione semplificherà anche il processo di rilascio perché non è più presente alcuna unione aggiuntiva.

Ho i seguenti vincoli:

• le versioni sono programmate e non dovrebbero essere completamente automatizzate
• mentre i rami delle funzionalità hanno in genere una durata breve, alcuni rimangono immersi per diverse settimane (ad esempio una riprogettazione) ma devono essere testati (attualmente come richieste pull aperte per lo sviluppo)
• a volte una singola funzionalità dovrebbe essere rilasciata al di fuori della versione normale, trasformandola efficacemente in un aggiornamento rapido. Con la strategia attuale posso riformulare un ramo di funzionalità e unirlo direttamente al master
• succede anche che abbiamo bisogno di trattenere le funzionalità dopo che i test di accettazione con sistemi esterni in fase di gestione temporanea non sono riusciti

Dove non sono sicuro della transizione:

• attualmente sto creando richieste pull per i test e unendo commit per le versioni. Posso unificare questo?
• come gestire gli aggiornamenti rapidi quando il master è in vista dell'ultima versione. Devo compilare e distribuire le versioni direttamente dai rami hotfix?
• esiste un modo sensato per gestire le funzionalità che dovrebbero essere escluse da una versione dopo che sono già state unite? Un ramo di sviluppo separato è davvero un vantaggio per questi casi? La maggior parte delle volte finisco per ripristinare e ripristinare gli commit manualmente comunque.

IMHO i problemi che stai affrontando sono solo un effetto collaterale della povera strategia di filiale con cui hai iniziato: stai effettivamente portando avanti nuovi sviluppi develop(cioè ciò che converge verso il futuro codice di produzione) attraverso l' attuale codice di produzione master. Ciò porta a contraddire requisiti e problemi poiché in genere il codice futuro differisce da quello attuale:

• il nuovo sviluppo destabilizza produzione - regressioni visto dopo la fusione developinmaster
• stabilizzare la produzione rallenta lo sviluppo futuro - è necessario stabilizzarsi developper renderlo abbastanza buono per la fusionemaster

La caduta developnon aiuterà (molto) - non stai eliminando il problema, stai semplicemente trasferendo la developparte specifica del problema master.

Un approccio migliore sarebbe quello di spostare la produzione dietro lo sviluppo attuale / futuro, per evitare interferenze con lo sviluppo di versioni future, come illustrato in questa immagine da Qual è il tuo modello di diramazione? :

Si noti che mi riferisco solo ai rami di rilascio nell'immagine sopra, non a ciò che sta accadendo nel bagagliaio.

Come funzionerebbe per te:

• il developramo scompare, come volevi, assorbitomaster
• il masterramo è il tuo tronco, questo è dove lo sviluppo avviene senza limiti di velocità (non è mai unito alla produzione).
• la produzione è / sono uno o più releaserami estratti da masterun'etichetta / tag considerati abbastanza vicini alla qualità della produzione (un breve elenco di elementi rimanenti può essere indirizzato in quel ramo se necessario). Questi rami possono ricevere solo correzioni rapide dirette e / o correzioni selezionate dalla ciliegia master, non vengono mai uniti mastero altri rami
• gli hotfix sono commit diretti nei releaserami

Se un aggiornamento rapido si applica solo a una versione di produzione ma non a quella master, viene eseguito il commit diretto nel releaseramo. Se si applica a entrambi, è in genere impegnata per la masterprima volta e ciliegia selezionata / doppiamente impegnata anche per la releasefiliale.

Ora guardando ciò che accade master(che è passato il punto in cui releaseviene estratto il ramo corrente ), hai 2 opzioni:

• continuare con questi rami, proprio come si fa oggi, tranne che essi saranno in base al largo master, non è develop. La loro conversione in hotfix rimane possibile - dovresti semplicemente rifasarli nel releaseramo corrispondente anzichémaster
• passare all'integrazione continua e trarne i benefici (può essere fatto in qualsiasi momento in futuro), anche in modo progressivo - attirando gradualmente sempre meno rami delle caratteristiche.

Se ti piace questo approccio, ecco come arrivarci da dove ti trovi oggi:

• stabilire una strategia di denominazione delle versioni:
  • non puoi avere un ramo di rilascio in corso con lo stesso nome
  • non è possibile (in realtà non è necessario) riformulare o sincronizzare un ramo di rilascio di produzione
• estrarre immediatamente un releaseXramo master, seguendo quella strategia di denominazione
• smettere di commettere develop, entreranno presto master.
• fondersi developinmaster
• istruire gli sviluppatori a reimpostare le proprie aree di lavoro masteranziché develop.
• aperto masterper commit
• cancellare developse lo si desidera (o lasciarlo permanentemente bloccato / sola lettura per riferimento)

Supponiamo che tu elimini il ramo principale (puoi rinominare lo sviluppo in principale per confondere il tuo team se ti piace in seguito) e semplicemente usare i tag per le versioni sui rami sviluppo o hotfix. Hai eliminato un ramo, ma la differenza è solo un cambiamento nella sintassi. Cambia per cambiare.

Ora supponiamo che tu realizzi effettivamente lo sviluppo mantenendo il ramo master bloccato. Ciò che accadrà è che l'integrazione del codice rallenterà, vivrà più a lungo separata nei rami delle funzionalità, in particolare vicino alle date di rilascio. Ciò aumenterà la difficoltà di fusione ogni volta e rallenterà il processo.

All'interno dei vincoli che hai stabilito non vedo alcun effetto positivo nel fare questo cambiamento. Richiederebbe il rilassamento dei vincoli, in particolare il primo.

Stai già creando e testando il codice su ciascuno dei rami pull-request e hot-fix. Ciò significa che, in totale, la somma di tutti i rami in sospeso sulla richiesta pull è il tuo developramo virtuale .

È possibile creare un sistema quando in un ambiente di test, diverse richieste pull vengono raccolte in un ramo temporaneo che non viene pubblicato nel repository principale. Questo ramo viene utilizzato per integrare un ambiente di test che include mastere diverse richieste pull aggiuntive, ma una volta eseguito il test, questo ramo non è più disponibile da nessuna parte.

Quando crei una versione da master, di solito crei un tag su quella versione. Gli hotfix successivi possono utilizzare quel tag per creare un nuovo ramo di hotfix dal quale verrà effettuata una distribuzione, anche se il bordo di masterè già in anticipo. Su questo ramo di hotfix probabilmente si tag anche una versione minore e assicurarsi che le modifiche siano state unite master.

Rimuovere le funzionalità unite da una versione è abbastanza difficile da fare con git. Il miglior meccanismo per questo sarebbe usare git revertil commit di merge. Ma ciò rende quasi impossibile recuperare queste funzionalità / modifiche e la storia diventa confusa.

Un modo molto migliore per gestire la separazione per la distribuzione del codice e il rilascio di funzionalità è rappresentato dai flag delle funzionalità . Se i tuoi sviluppatori possono nascondere le loro funzionalità dietro alcune condizioni nel codice stesso, puoi distribuire il loro codice, ma disattivare la funzionalità. Questo è un argomento separato, ma esistono molte informazioni al riguardo (incluso un Q&A su devops.SE).

Bene, @ dan-cornilescu lo dice bene per il tuo problema specifico, ma il caso più generale per lo sviluppo basato su trunk (menzionato nel Continuous Delivery, Lean Enterprise e The DevOps Handbook) è qui: https://trunkbaseddevelopment.com/