Quando dovrebbero essere creati i rami di sviluppo?

Stiamo spostando il team del nostro progetto dall'uso di un singolo ramo principale / trunk a più rami sviluppo / lavoro che dovrebbero essere regolarmente fusi nel principale. Stiamo basando il nostro nuovo processo su questo articolo e sulla TFS Branching Guide (stiamo usando TFS e Visual Studio 2010).

Attualmente ci sono tra 1 e 5 persone che lavorano contemporaneamente al progetto. Main deve essere stabile in qualsiasi momento perché vogliamo che l'opzione venga rilasciata ogni volta che ne abbiamo bisogno. Non abbiamo sprint fissi - almeno non ancora - e al momento rilasciamo ogni 1-2 settimane.

Proprio in questo momento ogni persona sta risolvendo bug in tutta l'applicazione. Tra un paio di settimane inizieremo lo sviluppo di un nuovo componente di grandi dimensioni per l'app.

Un punto critico che stiamo riscontrando è quando dovrebbero essere creati i rami di sviluppo . Implementeremo più storie utente in parallelo a seconda del set di abilità dello sviluppatore. Abbiamo pensato di creare una succursale per ogni sviluppatore, ma non ha senso perché ci sarà sempre bisogno di collaborazione su un lavoro. Non possiamo cavarcela con un singolo ramo di sviluppo perché vorremmo unirci a Main mentre altri lavori sono stati completati.

Qualcuno ha qualche consiglio su questo?

Non mi piacciono i rami arbitrari, ad esempio le correzioni di Fred o le correzioni di Harry. Mi sento molto più a mio agio con una funzione (indipendente) con un ramo che consente a più sviluppatori di operare su una funzione; ma per unire la funzione solo quando è completa.

Quindi, in questo momento hai solo bisogno del ramo "bugfix" ma una volta iniziato lo sviluppo dovresti creare un ramo per ogni caratteristica significativa. In questo modo, una volta terminati, possono essere uniti e rilasciati senza dipendere da altre funzionalità di buggier.

Non sono sicuro di come TFS sia bravo a fondersi, ma sono sicuro che lo saprai tra qualche mese :)

Non possiamo cavarcela con un singolo ramo di sviluppo perché vorremmo unirci a Main mentre altri lavori sono stati completati.

Sembra che tu sappia già che devono essere creati più rami di sviluppo. Mi vengono in mente due scenari probabili:

1. Ognuno dei cinque sviluppatori sta lavorando su parti indipendenti del progetto (correzione di bug) - Assicurati che venga creato un singolo ramo per ogni sviluppatore. Ciò pone l'onere e la responsabilità su ogni sviluppatore per assicurarsi che il proprio insieme di modifiche non sia in conflitto con il lavoro di qualcun altro. È molto probabile che uno dei tuoi cinque sviluppatori commetta un errore. Se / Quando questo è il caso, non ha alcun senso che tutti gli altri siano ostacolati.
2. Sviluppi di funzionalità multiple - Indipendentemente dal numero di sviluppatori che lavorano su una particolare funzionalità / bug, questi dovrebbero essere separati. Un esempio di questo vantaggio è che tutti i commit del codice fanno parte delle funzionalità che si stanno sviluppando - non ci sono ripensamenti.

Filiali di lavoro implicito con DVCS

Usiamo Mercurial quindi c'è il ramo di lavoro implicito nella casella di sviluppo degli sviluppatori. Il commit viene sempre eseguito nell'area di lavoro locale. Quando viene completato un lavoro rilasciabile, viene inviato al server repository primario dove viene creato e testato automaticamente.

Non creiamo quasi mai rami espliciti, ma poi i nostri sprint non durano mai più di 1 settimana e le carte non richiedono più di 1-2 giorni per essere completate.

Inoltre, puoi mitigare il dolore di unione inserendo il lavoro da altre parti di codice o altri progetti in modo che le persone non debbano fare fusioni difficili in ogni momento.

Ho usato sia un singolo ramo per trama che un ramo per uscita (tutti gli sviluppatori fanno il check-in delle loro storie per lo sviluppo e se una di queste interrompe il ramo dello sviluppo è rotto per tutti). Consiglio vivamente un ramo per storia se non ti piacciono i conflitti. Il ramo dev rimarrà sempre stabile per tutti gli sviluppatori e non ci saranno tempi di attesa per uno sviluppatore che lavora su un pezzo di codice che un altro sviluppatore ha già rotto. Quando la tua storia è finita, tutto il tuo codice è nel tuo ramo. Lo unirai a dev ma non fare il check-in e testare, in caso di conflitti lo risolverai e chiederai alla persona con cui sei in conflitto di evitare di rimuovere il suo codice. Quindi unisci a dev. Questo aiuta tutti gli sviluppatori a lavorare senza problemi. Dipende anche dalle dimensioni dell'azienda. La nostra azienda ha 200 sviluppatori che lavorano contemporaneamente su una base di codice, ma ramo separato per le loro storie. Una volta che il codice viene unito al ramo di sviluppo, il ramo della trama viene immediatamente eliminato. Spero che questo possa essere d'aiuto. Grazie

Se questo è basato su git, allora devi solo creare un ramo per ogni correzione di bug, correggere il bug nel più breve tempo possibile, unire il ramo di correzione di bug con il ramo di sviluppo, quindi inviare la modifica al ramo di sviluppo. Revisionare le richieste pull e l'unione dovrebbe essere la priorità più alta, perché più velocemente lo fai, migliori sono le possibilità che l'unione non causi problemi. Una volta uniti, questi rami possono essere eliminati.