Modello di ramificazione TFS 2010 per un'applicazione interna

Question

Questa non è una domanda in cui non ho idee, ma invece vorrei presentare un modello e vedere se viene approvato o chiunque può vedere problemi con esso o ha suggerimenti migliori. Dicono che sia meglio scegliere con attenzione il modello di ramificazione per evitare futuri mal di testa.

Quindi abbiamo un'applicazione interna con una sola versione (l'ultima) rilasciata ai clienti e fondamentalmente ci sono 2 tipi di attività di sviluppo: l'attività principale è lavorare per la prossima versione e di solito include nuove funzionalità e correzioni correttive ed è pianificato, e il secondo che non è pianificato e riguarda la manutenzione e include gli hotfix della versione corrente in produzione.

Dopo una lunga ricerca, abbiamo deciso di utilizzare un tronco Principale da cui diramiamo 2 rami figli: Sviluppo e Manutenzione (o Hotfix ). Come viene presentato nella guida, lo sviluppo quotidiano avverrebbe nel ramo Sviluppo da cui eseguiamo l'integrazione inversa (RI) ogni volta che abbiamo funzionalità pronte per la prossima versione. Subito prima del rilascio, l'integrazione inversa verrà interrotta e il codice verrà stabilizzato nel ramo Principale . Dopo il rilascio da Main ci sarà un'integrazione diretta (FI) da Main a Development e Maintenance . < / p>

Qualsiasi hotfix avverrà solo in Manutenzione e, a seconda della correzione (ad esempio, se vogliamo mantenerlo nella base di codice) eseguiremo un RI in Main e da lì un FI in Sviluppo .

Ora sembra tutto a posto, almeno sulla carta, quindi vorrei sentire le opinioni degli altri su questo modello.

Ad esempio, potremmo anche considerare di avere un altro ramo, Release , in cui la stabilizzazione del codice avviene prima del rilascio in produzione (invece di lavorare direttamente in Main ) e ovviamente rilasceremo da qui alla produzione e faremo un RI in Principale seguito da un FI a Sviluppo e Manutenzione , ma non lo siamo sicuro se questo porterà qualche vantaggio o aumenterà solo la complessità?

E supponendo che ci saranno funzionalità in Sviluppo che non saranno pronte o non desiderate per la prossima versione questo significa che dovremo fare un po 'di "selezione rapida" dei changeset correlati alle caratteristiche desiderate, ma non è troppo buono secondo i documenti. Qualche suggerimento?

Ancora una volta so che non è una domanda semplice e diretta, ma piuttosto aperta, tuttavia spero di sentire qualcuno con un'esperienza simile. Grazie in anticipo per la tua attenzione.

Answer 1

Hai letto la documentazione di TFS ALM Rangers Branching Guidance?Quello che stai proponendo assomiglia più o meno al loro "Piano di filiale standard", sebbene incoraggino ad avere un ramo di rilascio e di "pacchetto di servizi" (molto simile ai rami di rilascio e manutenzione sopra).

http://vsarbranchingguide.codeplex.com/

Ho implementato il piano di diramazione standard presso alcuni clienti e non ho avuto problemi con esso.Se prevedi di adottare flussi di lavoro simultanei (equipaggi di funzionalità, ecc.), Anche la Branching Guidance ha piani solidi.

Un'altra cosa da considerare potrebbe essere un modello a gradini in cui crei nuovi rami di sviluppo a ogni versione e congeli quello vecchio come rilascio.Ciò eviterebbe le istanze riservate poiché puoi semplicemente correggere il vecchio e FI la correzione al nuovo ramo Dev, se necessario.Ho lavorato anche su questo modello ed è stato fantastico.