Wir versuchen, den "Basic Dual Branch Plan" wie von den ALM Ranger im letzten Visual Studio TFS Branching and Merging Guide . Von der Anleitung:
Der grundlegende Zweigplan mit einem MAIN-, DEV- und RELEASE-Zweig ermöglicht die gleichzeitige Entwicklung für Ihr nächstes Release, einen stabilen MAIN-Zweig zum Testen und einen RELEASE-Zweig für jedes Schiff, das Fehlerbehebungen blockiert. Mehrere Entwicklungsbereiche werden unterstützt, indem Sie zusätzliche Entwicklungszweige von MAIN erstellen. Dies sind Peers miteinander und Kinder von MAIN.
Zusätzliche Releases werden durch das Erstellen von Release-Zweigen für jede Produktversion unterstützt. Jeder Release-Zweig ist ein Kind von MAIN und ein Peer zu einander (z. B. Release 2.0 Branch ist Peer zu Release 3.0 und beide sind Kinder von MAIN). Wenn Sie jeweils nur ein einziges Release in der Produktion unterstützen, können Sie einen einzelnen Release-Zweig in Betracht ziehen und direkt in diesem Zweig Fehlerkorrekturen vornehmen. Sobald der RELEASE-Zweig erstellt wurde, können MAIN und die Entwicklungszweige die Änderungen übernehmen, die für die nächste Produktversion genehmigt wurden.
Wir sind unschlüssig, ob wir einen einzelnen Release-Zweig (und Label-Releases) verwenden oder einen neuen Release-Zweig pro Release erstellen möchten. Es gibt jedoch einige Fragen, die für beide Seiten gelten und die in den Leitlinien nicht behandelt werden.
Meine Hauptfrage ist: Wann sollten wir einen RELEASE-Zweig erstellen (oder den getesteten Code in den einzelnen RELEASE-Zweig verschieben, wenn wir so vorgehen)?
Ich würde denselben Rat geben wie Adarsh Shah , dass in den meisten Fällen zwei Zweige (MAIN, RELEASE) ausreichen und die Verwendung von Feature-Zweigen für Dinge, die Sie nicht sofort in MAIN übernehmen möchten, da dies eine Weile dauern würde vollständig zum Testen bereit. Und mit RELEASE meine ich eine Verzweigung pro tatsächlicher Veröffentlichung.
Denken Sie jedoch daran, dass MAIN theoretisch jederzeit in einem releasefähigen Zustand sein sollte. Dies bedeutet, Feature-Zweige für viele kleine Änderungen zu verwenden und Dinge nicht in MAIN zusammenzuführen, solange das Feature nicht als bereit betrachtet wird. Nun, das ist etwas, mit dem Sie experimentieren sollten und sehen, was in Ihrer Umgebung am besten funktioniert. Wenn Sie feststellen, dass es zu schwierig ist, MAIN in einem releasefähigen Zustand zu halten, erstellen Sie auf jeden Fall einen separaten DEV-Zweig, um die tägliche Arbeit zu übernehmen. Meiner Erfahrung nach kann man mit einigen guten Richtlinien, automatisierten und manuellen Tests schnell in einen Fluss kommen, in dem MAIN als ziemlich stabil betrachtet werden kann. Ich habe in Umgebungen gearbeitet, in denen wir einen DEV-Zweig hatten, der sehr instabil war, einen stabilen MAIN-Zweig und Umgebungen, in denen wir keinen DEV-Zweig hatten. Manchmal wurde der DEV-Zweig benötigt, manchmal wurde es zu einer Last, sie synchron zu halten, da sowohl DEV als auch MAIN ziemlich stabil waren und im Wesentlichen nur eine Kopie voneinander waren.
Nun, wann sollten Sie den Release-Zweig erstellen. Es hängt von der Art der Entwicklung ab, die Sie gerade machen. Für kleine Desktop-Projekte oder Websites, die einen ziemlich konstanten Veröffentlichungszyklus haben (z. B. eine einzelne Veröffentlichung pro Sprint), finde ich es am einfachsten, einen Veröffentlichungszweig am Ende eines Sprints zu erstellen und ihn nur zu drücken zur Produktion der Sprint nach.
%Vor%Also, am Ende von S1 erstelle ich den Release-Zweig R1 von MAIN, aber es wird noch nicht in die Produktion geschoben. Während S2 sind beide neuen Funktionen auf MAIN implementiert und kritische Fehler sind auf R1 behoben. Wenn ein Fix für R1 genehmigt wird, wird es auch wieder in MAIN zusammengeführt, wenn es erforderlich ist. Am Ende von S2 wird ein neues R2 erstellt und R1 wird in Produktion gebracht. Ich habe gefunden, dass dieser Ansatz ziemlich gut funktioniert. Sie haben im Grunde einen vollständigen Sprint, um die letzten Probleme in einem Veröffentlichungszweig zu erarbeiten.
Natürlich, wenn ein ernsthafter kritischer Fehler in der Produktion auftritt, hat dieser Fehler Vorrang vor allem anderen. Ein Zweig RXa, RXb, ... kann dann aus dem bestehenden R-Zweig erstellt werden, der in Produktion ist, den Hot-Fix implementieren und diesen Hot-Fix in die Produktion schieben. Sie können dann prüfen, ob die Änderungen aus dem Hot-Fix in Ihren MAIN-Zweig eingefügt werden müssen. Erstellen Sie keinen Hot-Fix für den MAIN-Zweig und führen Sie ihn nicht zusammen. Sie werden feststellen, dass er schnell zu komplex wird, da sich auf MAIN bereits ein großer Teil des umgebenden Codes geändert hat.
Hier ist, was ich vorschlagen würde:
1) Führen Sie die gesamte Entwicklung im Zweig "Haupt" aus, bis der Code abgeschlossen ist. Code complete ist der Zeitpunkt, an dem Entwickler mit der Arbeit an neuen Funktionen für diesen Sprint aufhören, aber Regressionsfehler beheben können. Code abgeschlossen kann einige Tage vor der Veröffentlichung oder bis zu einer Woche, basierend auf wie lange ist Ihr Sprint).
2) Erstellen Sie an diesem Punkt einen neuen RELEASE-Zweig vom MAIN. Stellen Sie die Zweigstelle für die QA / Staging-Umgebung bereit, um einen Rauchtest durchzuführen. Danach wird das QA-Team den RELEASE-Zweig verwenden, um den Test für das Release durchzuführen.
3) Entwickler können zu diesem Zeitpunkt mit den neuen Funktionen für den nächsten Sprint arbeiten und mit dem Einchecken der Änderungen in den MAIN-Zweig beginnen. Alle beim Testen gefundenen Regressionsprobleme werden zuerst im RELEASE-Zweig behoben und dann wieder zu MAIN zusammengeführt.
4) Alle Änderungen im Code in der RELEASE-Verzweigung werden dann für weitere Tests an QA / Staging weitergegeben.
5) Sobald die Veröffentlichung abgeschlossen ist, wird jeder in der Produktion gefundene Fehler in der RELEASE-Verzweigung behoben und an Prod heißfixiert und wieder mit MAIN zusammengeführt.
Nein. 1 wird zu spät sein und nein. 2 wird zu früh IMO sein.
Ich würde vorschlagen, für jeden RELEASE einen neuen Zweig zu erstellen und dann alte RELEASE-Zweige regelmäßig loszuwerden, anstatt Etiketten zu verwenden.
Außerdem bevorzuge ich nur zwei Zweige MAIN (die auch DEV ist) und RELEASE, außer dass jeder Zweigentwickler eine bestimmte Funktion / Framework-Änderung usw. benötigt. Unter dem Stammordner erstelle ich normalerweise MAIN, RELEASES (alle Release-Zweige) und Branches (alle Zweige, die sich auf ein Feature / Framework beziehen usw. werden aber nur in speziellen Fällen nicht immer erstellt)
Tags und Links tfs tfs2012 merge branch branching-and-merging