TFS ramificazione modello di sostenere a lungo QA (test di sistema) ciclo

Question

Diciamo che hai un'applicazione.Questa applicazione è quello di essere controllate e distribuito alla produzione.Ci sono alcuni vincoli sul ciclo di vita dell'applicazione.

1. Solo una versione dell'app esisterà mai in produzione.
2. Una volta distribuito alla produzione se necessario, hot-fix può essere sviluppato.Hot-fix sono strettamente mirati per risolvere specifiche di alta gravità del difetto e di non introdurre nuove funzionalità.L'hot-fix modifica del codice dovrebbe essere inverso integrati con gli altri rami.
3. Prima di relessing di produzione per la nuova versione di funzionalità si deve passare attraverso la QA ciclo.
4. Dopo il rilascio al controllo di qualità e ci vuole tempo significativo per testare l'app.Al primo QA ciclo se QA apre 20 difetti che devono essere corretti nella prossima release per QA senza più funzioni di test.Se QA team quindi si riapre dire 10 difetti quindi sulla prossima versione di QA vogliono solo quei 10 difetti per essere risolto.No altri difetti o qualsiasi nuova funzionalità.La funzionalità di rilascio può avvenire solo dopo il conteggio è 0 (o alcuni difetti sono deciso a non essere fisso o di miglioramento, etc.).
5. Dal momento che il QA ciclo di tempo, durante il tempo di sviluppo non può interrompere.Nuove caratteristiche dovrebbero essere ha continuato ad essere sviluppato per la prossima versione di funzionalità.

Come l'installazione di TFS modello di ramificazione.

Answer 1

Suona come voi sono un perfetto candidato per la "Standard" strategia da TFS ramo / unione di orientamento: http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

In sostanza, questo prende la vostra base Dev <-> Principale <-> Modello di rilascio, quindi aggiunge un altro livello di indirezione.Hot fix ottenere il loro proprio ramo sul lato di Rilascio della gerarchia, in modo che il loro sviluppo + test non disturbare l'ordinario QA ciclo accadendo nel Principale né inquinare la santità di Rilascio.Si può vedere un visual illustrazione a pagina 7 del PDF.

Hai un ferreo requisito che un ramo di Release(es), rappresentano una precisa istantanea di produzione (es.c'è una relazione 1:1 tra visite per il Rilascio e la distribuzioni, e/o di una Versione separata del ramo creato per la distribuzione)?Se poi non si può nemmeno bisogno dell'aggiornamento rapido (hotfix) filiale -- fare correzioni direttamente in Rilascio.Questo è coperto in "di Base" strategia in precedenza nel documento.

In ogni caso, assicurarsi di leggere l'intera suite di documenti.Non è molto, ma distilla un sacco di risultati reali implementazioni.(il "VST Rangers" sono composti principalmente di Mvp e altri consulenti)

Per un più lungo, più teorico occhiata al team di sviluppo di strategie e la loro attuazione in TFS, controllare la documentazione fornita dal gruppo Patterns & Practices:http://msdn.microsoft.com/en-us/library/bb668991.aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html