TFS Verzweigungs Modell lange QA (Systemprüfung) Zyklus zu unterstützen

Question

Nehmen wir an Sie eine Anwendung haben. Diese Anwendung ist QA getestet und zur Produktion eingesetzt werden. Es gibt einige Einschränkungen für den Anwendungslebenszyklus.

1. Nur eine Version der App wird existiert immer in der Produktion.
2. Sobald der Produktion zum Einsatz, wenn erforderlich Hot-Fixes entwickelt haben wird. Hot-Fix sind eng zu beheben spezifische hohe Schwere Fehler gezielt und nicht neue Funktionen einzuführen. Die Hot-Fix-Code ändern sollte umgekehrt zu anderen Branchen integriert werden.
3. Vor der Produktion für neue Features Release relessing es durch QA-Zyklus gehen muss.
4. Nach dem Loslassen es QA nimmt viel Zeit für die App zu testen. Beim ersten QA-Zyklus, wenn QA 20 Defekte öffnen müssen sie ohne weitere Features in der nächsten Release für QA festgelegt werden, um zu testen. Wenn QA-Team wieder öffnet dann 10 Defekte sagen dann auf die nächste Veröffentlichung QA wollen sie nur die 10 Mängel behoben werden. Keine andere Defekte oder irgendwelche neuen Features. Die Freigabe nächste Funktion kann erst nach Fehlerzahl geschehen ist 0 (oder einige Mängel sind entschieden nicht festgelegt oder Verstärkung etc werden.).
5. Da der QA-Zyklus Zeit in Anspruch nimmt, während dieser Zeit der Entwicklung kann nicht aufhören. Neue Funktionen sollten für die nächste Feature Release fortgesetzt werden, entwickelt werden.

Wie würden Sie Ihre Setup TFS Verzweigungsmodell.

Answer 1

Klingt wie Sie ein perfekter Kandidat für den "Standard" Strategie aus dem TFS Zweig / merge Führung sind: http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

Im Wesentlichen das Ihren Grunde Dev nimmt <-> Haupt <-> Freigabe Modell, fügt dann eine weitere Schicht der Dereferenzierung. Hot Fixes erhält ihre eigene Niederlassung auf der Release-Seite der Hierarchie, so dass ihre Entwicklung + Test nicht den gewöhnlichen QA-Zyklus in Haupt geschieht stören noch die Heiligkeit der Veröffentlichung verschmutzen. Sie können sich auf Seite 7 des PDF eine visuelle Darstellung sehen.

Haben Sie eine ironclad Anforderung haben, den Zweig Release (n) eine genaue Momentaufnahme der Produktion darstellen (das heißt, es ist eine 1: 1-Beziehung zwischen checkins Release und Installationen und / oder einem separaten Release-Zweig pro Einrichtung erstellt)? Wenn nicht, dann können Sie nicht einmal den Hotfix Zweig müssen - tun Hotfixes direkt in Release. Dies wird in der „Basic“ Strategie früher im Dokument behandelt.

In jedem Fall sollten Sie die ganze Reihe von Dokumenten zu lesen. Es dauert nicht lange, aber destillieren viele Erkenntnisse aus realen Implementierungen. (Die „VSTS Rangers“ sind aus MVPs und andere Vor-Ort-Berater in erster Linie gemacht)

Für einen längeren, mehr theoretischen Blick auf Teamentwicklungsstrategien und deren Umsetzung in TFS, überprüfen Sie die Papiere aus dem Patterns aus & Practices-Gruppe: http://msdn.microsoft.com/en-us/library/bb668991. aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title= html