Branching e CI Build con Agile

3

Seguiamo molti processi agili, inclusi test automatici, integrazione continua, recensioni sprint, ecc ... Stiamo discutendo di quanto spesso dovremmo rilasciare i build di rilascio.

Abbiamo fatto scatti di due settimane e provato a distribuire alla produzione alla fine di ogni sprint. Alcuni di noi pensano che dovremmo ramificare ogni sprint. Alcuni di noi pensano che sia eccessivo. Se un progetto comprende tre soluzioni di Visual Studio e ramifichiamo ogni sprint, allora ci sono tre rami e tre build CI da creare ogni due settimane. Se facciamo questo per sei mesi, finiremo con 36 rami e 36 build CI. C'è un sovraccarico in questo.

Per quelli di noi che pensano che ramificando ogni sprint sia eccessivo, non abbiamo una buona alternativa. Nel mio ultimo progetto, abbiamo implementato alcune soluzioni dal trunk principale. Sì, non va bene, ma si è salvato su parte del sovraccarico.

Qual è il modo giusto per gestire la ramificazione / rilascio e le build CI, usando agile, quando abbiamo cicli di sprint brevi (due settimane)?

    
posta Bob Horn 30.08.2012 - 03:57
fonte

2 risposte

4

Finché tagga ogni versione non è necessario diramarti. L'unica volta che devi diramarti è quando devi applicare un hotfix a una versione precedente e non puoi semplicemente aggiornare i tuoi clienti all'ultima versione. Se hai bisogno di tornare a una versione precedente e applicarla su una patch, devi rimuovere il tag / etichetta.

Vorrei leggere un riuscito modello di branching Git

Devi diramarti quando vuoi continuare a inserire nuove funzionalità, ma non darle come patch per una versione precedente. Qual è il loro ragionamento per creare un ramo ogni primavera?

    
risposta data 30.08.2012 - 04:11
fonte
2

È una buona idea creare un tag per ogni versione. Se hai tre soluzioni che vengono rilasciate separatamente, allora significherebbe tre tag, non vedo alcun problema. Ogni versione deve avere la propria configurazione di build sul server CI? Dipende da quante versioni devi supportare. Se hai solo bisogno di supportare l'ultima versione, mentre stai lavorando su una nuova versione, puoi partire con almeno due configurazioni di build: una che viene creata ogni volta che vengono apportate modifiche al trunk, una che genera l'ultima versione.

    
risposta data 30.08.2012 - 05:44
fonte