Come passare da una realtà ramificata complessa a un modello a ramo singolo?

Nelle organizzazioni di grandi dimensioni, l'utilizzo della metodologia a cascata si traduce in genere in strutture di ramificazione molto complesse (aka branch spagetti ).

Quali strategie di ramificazione possono essere utilizzate per passare da una realtà di ramificazione complessa a un modello a singolo ramo come lo sviluppo basato sul tronco?

Aggiornare:

Per chiarire, la domanda riguarda la migrazione / transizione stessa , non le metodologie prima e dopo, che sono piuttosto chiare.

Non può davvero essere "all'EOB oggi siamo ancora a cascata con gazillion di rami ma domani 1 ° cosa passeremo al CI basato su trunk e single-branch".

Dato che menzioni la cascata, capisco che i numerosi rami a cui alludi sono rami delle caratteristiche piuttosto che rami della manutenzione.

In questa configurazione, presumo anche che questi rami siano creati secondo un piano a cascata che tenta di minimizzare i conflitti. Ciò implica che l'obiettivo dello sviluppo è quello di produrre diversi prodotti distinti. Quando si utilizza un modello di sviluppo a ramo singolo, è importante lavorare anche su un singolo prodotto. Se più prodotti vengono sviluppati contemporaneamente in un modello di sviluppo a ramo singolo, "incolla" efficacemente insieme le versioni di questi prodotti, in modo che nella versione a del repository sia possibile avere un prodotto X sano e un prodotto Y difettoso , mentre nella versione b il prodotto X ha una regressione e Y una correzione di bug, ma non abbiamo una versione in cui sia X cheY sono in salute. Una situazione del genere ci costringerebbe a considerare X e Y come sviluppati in repository distinti, il che suggerisce che dovrebbero essere.

Pertanto, i primi passaggi dovrebbero eseguire una suddivisione del repository :

1. Disporre il repository in modo che sia facile suddividerlo in diversi piccoli repository. Ad esempio, riorganizzare il repository corrente in modo che ogni directory di livello superiore corrisponda a un repository che si desidera creare in futuro. In questo modo, puoi continuare a utilizzare la disciplina degli spaghetti di ramo che tutti conoscono.

2. Al termine del passaggio 1, perfezionare la disciplina branch-spaghetti richiedendo che ogni singolo ramo possa toccare solo i file in una directory di livello superiore.

3. Quando ogni ramo è conforme al passaggio 2, eseguire la divisione. Gli sviluppatori possono facilmente convertire le loro modifiche in sospeso per correggere un singolo repository, semplicemente rimuovendo il primo livello del percorso.

Ora che la divisione è stata eseguita, puoi iniziare a lavorare sulla disciplina del ramo stessa.

4. Introdurre tecniche di programmazione per lo sviluppo di rami di breve durata. I rami di breve durata sono un aspetto cruciale di tutte le metodologie a ramo singolo. Uno dei loro obiettivi è ridurre il tempo impiegato per la fusione e il debug di rami di lunga durata. Una tecnica popolare è l'introduzione di "feature flag" in cui una "fabbrica" ​​utilizza un flag di configurazione per produrre la versione storica di un oggetto o la nuova versione, inizialmente parzialmente sviluppata, di quell'oggetto.

5. Ormai, hai miliardi di repository con solo pochi rami in ciascuno, e puoi girare il pulsante “Adottiamo globalmente la disciplina dello sviluppo basata sul tronco”, senza vedere la montagna di rami-spaghetti originale crollare sul tronco.

La suddivisione effettiva dei repository potrebbe essere facoltativa, ma dovresti quindi adottare politiche che delineano in modo chiaro l'ambito consentito di ogni patch inviata (per limitare il rischio di conflitti quando si uniscono le modifiche nel ramo principale). Ridurre il sovraccarico legato ai conflitti è uno degli obiettivi delle metodologie del modello a ramo singolo, quindi presumo che sia rilevante nel tuo contesto.

Durante la migrazione da qualcosa a qualcos'altro, ci sono solo due cose che devi definire:

1. Qual è il tuo obiettivo
2. Come arrivare (il piano di migrazione)

La prima parte è, purtroppo, spesso trascurato o modo troppo vago. Non puoi semplicemente dire che quello che hai è un casino e vuoi organizzarlo. Cosa significherebbe? Ognuno avrebbe una diversa interpretazione (aka: ogni dev pensa che la sua o il suo modo di fare le cose è il migliore).

È probabile che tutti i rami che stai servendo o abbiano servito a uno scopo. Senza un processo target chiaramente definito, le persone continueranno a fare ciò che funziona per loro nel modo più adatto (e giustamente).

Ad esempio, il tuo obiettivo dovrebbe essere definito in modo chiaro come Vincent Driessen ha definito il suo "modello di ramificazione Git di successo" . Se guardi questo modello, è molto preciso: dice dove dovrebbe essere il codice stabile e dove dovrebbero essere sviluppate funzionalità instabili. Indica anche come - e quando - diramare, aggiornare e ricollegare. Sai a cosa serve ogni ramo e cosa farne. Usiamo una variante di ciò che è stato proposto da Vincent e la nostra variazione è definita nel nostro wiki.

L'importante è far comprendere e concordare un obiettivo a tutto il team. Potrebbe valere la pena ricordare alle persone che non stai cercando il loro modello di ramificazione preferito personale, ma un modello su cui tutti i membri del team possono concordare e utilizzare facilmente.

Una volta che hai il tuo obiettivo, sarai in grado di elaborare il tuo piano di migrazione. Quel piano può essere lungo o corto quanto desideri. Ho visto un tale modello di ramificazione imposto da un giorno all'altro; in altri posti, è stato fatto per 2 o 3 sprint. Non importa molto per me, purché stiamo migliorando.

Puoi iniziare con i rami "più grandi" o più importanti. Ad esempio: "da ora in poi, il master deve essere sempre in uno stato per essere distribuito in prod e il ramo dev deve sempre compilare" (o qualunque siano le tue regole). Quindi, imporre i rami versione (rilascio). Successivamente, applicare i rami delle funzionalità. Successivamente, impone un blocco del codice sul ramo della versione, se ha senso.

DevOps è incentrato su comunicazione, apertura ed efficienza. Questi concetti devono essere tenuti a mente e comunicati durante tutto il processo.

Suggerirei di invitare alcune persone al di fuori del team di sviluppo alla riunione di processo come osservatori. Ops o middle management potrebbero avere qualcosa da dire sul tuo modello. Le esigenze degli sviluppatori dovrebbero essere prioritarie, ma se il modello di diramazione è impossibile da allineare con il modo in cui le cose sono gestite, sarebbe meglio sapere ora e non tra un mese o due.

Se hai squadre davvero grandi, cerca comunque di includere tutti. Con squadre molto grandi, finirai comunque con due o tre incontri. Quindi invita i team leader nella stanza, ma disponi di un webcast e fai sapere a tutti. Se qualcuno ha un suggerimento o una preoccupazione, sarà in grado di darne voce al proprio leader del team e, se è valido, verrà indirizzato al secondo o al terzo incontro.

In realtà è molto semplice convertire un repository hydra multi-ramificato in un singolo modello ramificato.

Innanzitutto, vuoi iniziare con i rami che hanno la minima differenza tra se stesso e master o trunk. Esamina la loro età e rilevanza. Se sono ancora rilevanti, inizia a fonderli insieme e risolvere i conflitti. Se non sono più pertinenti, eliminali.

Continua questo processo fino a quando non sei riuscito a unire tutti i tuoi rami, risolto tutti i conflitti e hai solo un singolo ramo rimanente.

Puoi seguire questo semplice schema per iniziare:

1. Crea una copia del tuo ramo master / trunk e chiamalo temp_master
2. Trova il ramo con la massima divergenza dal maestro / tronco.
3. Determina se il ramo deve essere conservato, archiviato o eliminato.
   1. Se deve essere mantenuto, andare al passaggio 4.
   2. Se è necessario eliminarlo o archiviarlo, eliminarlo e archiviarlo, quindi tornare al passaggio 2.
4. Ripetere il passaggio 2 per trovare il ramo successivo con la minima divergenza.
5. Unire i due rami trovati nel passaggio 2 e passaggio 3, risolvendo tutti i conflitti.
6. Unisci questi due rami nel tuo temp_masterramo.
7. Prova il codice nel codice temp_master per vedere se viene compilato e compilato ed esegui altri test automatici che hai per sanità mentale.
   1. Se qualche test fallisce, torna indietro, scopri perché, correggili e ripeti il ​​processo.
   2. Se i test falliscono ancora, scegli due diversi rami con cui lavorare.
8. Ripeti i passaggi da 2 a 7 fino a quando non hai solo due rami, il tuo master / trunk e temp_master.
9. Infine, unisci temp_masterin master / trunk e vivi con il tuo nuovo modello a ramo singolo.

Per le organizzazioni di grandi dimensioni con un tipico ciclo di sprint di 4 settimane, Git-Flow è l'approccio preferito perché si ottengono vantaggi dal ramo Feature Il ramo pronto per la produzione principale è sempre implementabile Inoltre, il ramo principale viene tenuto pulito da commit indesiderati seguendo due cicli di commit (da funzionalità a Develope Developbranch al Maestro).

Inoltre, le ramificazioni sono anche determinate dalla frequenza dei rilasci di produzione. Per una distribuzione frequente in produzione è meglio avere un ramo Feature o un modello centralizzato. In questo caso, le spese generali per la gestione delle filiali vengono trasferite a test efficaci in ambienti inferiori per mantenere la stabilità della produzione.