La mia azienda sta fondendo le filiali in modo errato?

Di recente mi sono imbattuto in un articolo di MSDN su ramificazione e fusione e SCM: Branching and Merging Primer - Chris Birmele .

Nell'articolo dicono che 'big bang merge' è un antipasto che si fonde:

Big Bang Merge - differire la fusione dei rami fino alla fine dello sforzo di sviluppo e tentare di unire tutti i rami contemporaneamente.

Mi sono reso conto che questo è molto simile a quello che la mia azienda sta facendo con tutti i rami di sviluppo che vengono prodotti.

Lavoro in una società molto piccola con una persona che funge da revisione finale + autorità di fusione del tronco. Abbiamo 5 sviluppatori (incluso me), a ciascuno di noi verrà assegnato un compito / bug / progetto separato e ciascuno di essi si staccherà dal tronco corrente (sovversione) e quindi eseguirà il lavoro di sviluppo nel nostro ramo, testerà i risultati, scriverà la documentazione se necessario, esegui una revisione tra pari e un ciclo di feedback con gli altri sviluppatori, quindi invia la filiale per la revisione + unione sul nostro software di gestione del progetto.

Il mio capo, l'unica autorità sul repository di trunk, rimanderà effettivamente tutte le recensioni delle filiali fino a un solo momento in cui eseguirà le recensioni il più possibile, alcuni rami verranno respinti per miglioramenti / correzioni, alcuni i rami si uniranno nel tronco, alcuni rami verranno rigettati a causa di conflitti, ecc.

Non è insolito per noi avere 10-20 filiali attive nella coda di revisione finale da unire in trunk.

Inoltre, spesso dobbiamo risolvere i conflitti nella fase finale di revisione e unione perché due rami sono stati creati dallo stesso trunk ma hanno modificato lo stesso pezzo di codice. Di solito lo evitiamo semplicemente rinominando il tronco e riapplicando le nostre modifiche e risolvendo i conflitti, quindi sottoponendo il nuovo ramo per la revisione (rebase dei poveri).

Alcune domande dirette che ho sono:

• Stiamo esibendo lo stesso anti-pattern che è stato descritto come la "fusione del big bang"?
• Alcuni dei problemi che stiamo riscontrando sono il risultato di questo processo di unione?
• Come possiamo migliorare questo processo di unione senza aumentare il collo di bottiglia sul mio capo?

Modifica: dubito che il mio capo allenterà la sua presa sul repository del trunk o consentirà ad altri sviluppatori di unirsi al trunk. Non sono sicuro di quali siano le sue ragioni, ma non ho davvero intenzione di sollevare l'argomento perché è stato sollevato prima e abbattuto piuttosto rapidamente. Penso che non si fidino di noi, il che non ha senso perché tutto è tracciato comunque.

Qualsiasi altra intuizione di questa situazione sarebbe apprezzata.

Alcuni suggerimenti:

• Non c'è nulla di sbagliato nell'avere molte funzionalità o rami bug fintanto che le modifiche apportate in ciascun ramo sono abbastanza piccole che puoi ancora gestire i conflitti di unione risultanti in modo efficace. Questo dovrebbe essere il tuo criterio se il tuo modo di lavorare è ok, non un articolo MSDN.

• Ogni volta che un ramo viene unito al tronco, il tronco deve essere unito al più presto in tutti i rami di sviluppo aperti. Ciò consentirebbe a tutte le persone del team di risolvere i conflitti di unione in parallelo nel proprio ramo e quindi di farsi carico del gatekeeper del bagagliaio.

• Funzionerebbe meglio se il gatekeeper non aspettasse che 10 rami siano "pronti per la fusione nel trunk" - la risoluzione dei conflitti di fusione dalle ultime integrazioni del trunk richiede sempre un po 'di tempo per il team, quindi è probabilmente meglio lavorare a intervalli di tempo intrecciati - una integrazione da parte del gatekeeper, una nuova unione da parte del team, la successiva integrazione da parte del gatekeeper, la successiva nuova unione da parte del team e così via.

• Per mantenere i rami piccoli, potrebbe essere utile suddividere le funzioni più grandi in più attività più piccole e sviluppare ciascuna di queste attività in un ramo a sé stante. Se la funzione non è pronta per la produzione fino a quando non vengono implementate tutte le attività secondarie, nasconderla dalla produzione dietro una funzione di attivazione / disattivazione fino al completamento di tutte le attività secondarie.

• Prima o poi incontrerai attività di refactoring che interessano molti file nella base di codice - questi hanno un alto rischio di causare molti conflitti di unione con molti rami. Questi possono essere gestiti al meglio comunicandoli chiaramente nel team e assicurandoti di gestirli esattamente come ho scritto sopra: integrandoli prima in tutti i rami degli sviluppatori prima del reinserimento e suddividendoli in piccoli sub-refactoring.

• Per le dimensioni della tua squadra attuale, avere un solo gatekeeper potrebbe comunque funzionare. Ma se la tua squadra crescerà di dimensioni, non c'è modo di avere un secondo gatekeeper (o più). Nota Non sto suggerendo di consentire a tutti di unirsi al tronco, ma ciò non significa che solo il tuo capo sia in grado di farlo. Probabilmente ci sono uno o due sviluppatori senior che potrebbero essere candidati anche a svolgere il lavoro di gatekeeper. E anche per le dimensioni della tua squadra attuale, un secondo gatekeeper potrebbe rendere più facile l'integrazione della tua squadra nel bagagliaio più spesso e prima o quando il tuo capo non è disponibile.

Stiamo esibendo lo stesso anti-pattern che è stato descritto come la "fusione del big bang"?

Sembra così.

Alcuni dei problemi che stiamo riscontrando sono il risultato di questo processo di unione?

Decisamente

Come possiamo migliorare questo processo di unione senza aumentare il collo di bottiglia sul mio capo?

Nella mia azienda, ogni sviluppatore ha la capacità di fondersi. Assegniamo una richiesta di unione a un altro sviluppatore, eseguiamo il ciclo di revisione / feedback / aggiornamento fino a quando entrambe le parti non sono soddisfatte. Quindi il revisore unisce il codice.

10-20 filiali in attesa di fusione sono un segno che il processo è difettoso. Se ne avessimo così tanti, tutto il lavoro degli sviluppatori si fermerebbe fino a quando non verrà chiarito.

Questo è essenzialmente il modo in cui funzionano molti progetti open source, incluso in particolare il kernel Linux, che ha molti più rami in volo rispetto a te in qualsiasi momento. Il modo tipico per evitare le fusioni del big bang in questi progetti è quello di creare un altro ramo (o più rami) per l'integrazione continua. Questo è il ramo che usi per assicurarti che le tue modifiche funzionino insieme ai tuoi colleghi e viene periodicamente ridisegnata sul bagagliaio quando il gatekeeper fa le revisioni.

Facoltativamente, puoi utilizzare questo ramo per combinare diverse delle tue richieste pull in un'unica grande richiesta coerente per la revisione da parte del tuo capo. Linus Torvalds riceve in genere richieste pull che sono state integrate a due o più livelli di profondità e possono avere una dimensione dell'ordine, ad esempio, di un nuovo driver di file system completo.

Sono d'accordo con Doc Brown ma vedo anche un altro antipattern:

Il mio capo, l' unica autorità sul repository di trunk , rimanderà effettivamente tutte le revisioni delle filiali fino a un solo momento in cui eseguirà le revisioni il più possibile, alcuni rami verranno respinti per miglioramenti / correzioni, alcuni i rami si uniranno nel tronco, alcuni rami verranno rigettati a causa di conflitti , ecc.

Nel mio umile ci sono alcuni antipasti di gestione:

1. Lui / lei è l'unico punto di strozzatura che limita la velocità della squadra. Il tuo fattore bus è 1. La teoria dei vincoli dice che dovresti sforzarti di migliorare la parte più lenta della catena.
2. Il tuo manager sta rallentando il tuo ciclo di feedback e riduce l'agilità del tuo team. Puoi rilasciarlo ogni settimana?
3. La complessità delle fusioni cresce esponenzialmente con la quantità di codice. È meglio effettuare 10 fusioni con 100 righe rispetto a 1 su 1000 righe. Questo è solo uno dei motivi per cui dovresti farlo al più presto
4. Se rilevi un guasto nel bagagliaio, lo farai in un secondo momento. Quale dei vari rami era quello problematico
5. Le decisioni dovrebbero essere prese da coloro che hanno più conoscenza di loro. Chi ne sa di più in questo caso? Scommetto che gli sviluppatori che hanno creato il codice.
6. Non è possibile correggere un bug in produzione se il proprio manager è in vacanza.
7. Stai rifando il lavoro e stai gettando indietro i rami. Questa è una perdita di tempo. Anche il tempo che attende per raggiungere la produzione è uno spreco.

Raccomandazioni:

• Il tuo manager deve delegare la responsabilità al team. Devi dimostrare che la squadra è matura, professionale. Metti in chiaro che possono fidarsi della squadra
• Implementa un metodo di revisione. Forse hai bisogno dell'approvazione di altri due membri del team.
• Può essere che l'utilizzo di SVN lo stia rendendo più difficile. Prova Git e vedi se ti aiuta. Ancora di più. Se usi GitHub puoi utilizzare il meccanismo Pull Request in modo che un'unione richieda determinati voti.
• Leggi e condividi informazioni su pratiche agili, integrazione continua e DevOps.

Quando si esegue il lavoro di funzionalità in rami separati, non è possibile eseguire facilmente test di integrazione fino a quando uno dei rami non viene unito al trunk e inserito negli altri rami di funzionalità. Nella mia esperienza, questo è il problema principale con l'anti-pattern Big Bang Merge. Idealmente, dovresti svolgere il lavoro sulle funzionalità, testarlo nel ramo delle funzionalità, unirlo nel trunk e a quel punto hai finito con la funzione. Se non è stato unito, è necessario rivisitarlo ogni volta che qualcos'altro viene unito nel trunk prima di esso. Il dolore di questo anti-pattern è che hai molti bug di tipo integrazione che si presentano alla fine del ciclo di sviluppo.

Quindi hai 20 filiali. Il ramo 1 è appena unito. Quindi lo sviluppatore del ramo 2 deve unire il ramo 1 nel proprio ramo per poter unire in main senza conflitti, quindi unire. Quindi lo sviluppatore del ramo 3 deve unire il ramo 1 e il ramo 2 nel proprio ramo per poter unire in main senza conflitti, quindi si fonde.

Esercizio per il lettore: scrivere un programma che stampa il mio post completo :-)

Questa è una follia. Passerai un'incredibile quantità di tempo a fonderti.

Dato il modo in cui lavori e che il tuo capo è un maniaco del controllo responsabile, la ramificazione in sé sembra essere il problema. Invece di creare un ramo per ogni funzione, ogni sviluppatore impegna la sua funzione in parti, direttamente nel trunk. Ciò pone l'onere dell'integrazione sullo sviluppatore in più passaggi più piccoli (win-win). Il gate keeper può tenere il passo con il rilevamento di modifiche minori per un periodo più lungo prima nel ciclo di sviluppo ed essere ancora il revisore principale.

La ramificazione stessa è qualcosa che non vuoi fare a meno che tu non abbia un'ottima ragione per farlo o non hai altra opzione. Sei abbastanza piccolo da mantenere le cose sincronizzate più strettamente, il che sarà più facile e più sicuro.