Auswahl der richtigen Verzweigungsstrategie für Releases

Beginnend mit einem neuen Entwicklerteam für ein neues Projekt müssen wir unsere Verzweigungsstrategie für unser Quell-Repository definieren ( z. B. Microsoft Team Foundation Server 2010 ). Wir haben eine heikle Diskussion darüber geführt, ob ...

A . Haben Sie einen Release- Zweig, aus dem wir Produktions-Builds erstellen, und beschriften Sie dann, wenn tatsächlich etwas veröffentlicht wird

ODER

B . Haben Sie einen neuen Release- Zweig für jedes neue Release in der Produktion ( Bsp. Version 1, 2, 3 usw. )

Option A scheint ziemlich einfach zu sein, aber wir sind uns nicht sicher, ob dies auf lange Sicht zu Problemen führen wird. Option B scheint nur viele einmalige, langlebige Zweige zu schaffen, die sich im Laufe der Zeit häufen.

Hat jemand irgendwelche Erfahrungen, die uns bei der Entscheidung helfen könnten? Insbesondere möchte ich hören, wo die Schmerzpunkte für eine Wahl liegen. Sie können gerne spezifische Erfahrungen in Bezug auf TFS- und / oder Release-Management-Implikationen bereitstellen.

Option A. Verwenden Sie nur Mainline und Tagging für die Freigabe

Vorteile:

• Sie vermeiden es, die Hölle zu verschmelzen.
• Wenn Sie sich an die Hauptlinie halten, werden einige bewährte Methoden empfohlen, z. B. die ordnungsgemäße Release-Planung, die Einführung von nicht viel WIP, die Verwendung der Verzweigung durch Abstraktion zur Bewältigung von Out-of-Band-Langzeitarbeiten sowie die Verwendung des offenen geschlossenen Systems und konfigurierbarer Funktionen für die Verwaltung von Arbeiten in Bearbeitung, die kann; oder darf nicht; müssen jetzt oder in Zukunft deaktiviert werden, um ein vollständiges Rollback freizugeben oder zu vermeiden.

Nachteile:

• Der Umgang mit laufenden Arbeiten wird zu einem Problem und erweitert den potenziellen Oberflächenangriffsbereich, wenn es Zeit für die Veröffentlichung ist. Wenn Ihre Entwickler jedoch diszipliniert sind, sollten neue Funktionen konfigurierbar und modular sein und daher leicht deaktiviert / aktiviert werden können, oder es gibt kein WIP und an jedem Release-Punkt sind alle Arbeiten entweder abgeschlossen oder wurden noch nicht gestartet (dh Scrum).
• Große Änderungen außerhalb des Bandes erfordern mehr Überlegungen im Voraus, um sie zu implementieren (z. B. Verzweigung durch Abstraktion).

Persönlich bevorzuge ich diesen Ansatz. Codeabdeckung und Komponententests sollten Code identifizieren, der nicht bereit ist, aus der Tür zu gehen, und Personen sollten nicht an Code arbeiten, der während der aktuellen Iteration nicht freigegeben wird. Die Verzweigung durch Abstraktion oder andere Mechanismen kann verwendet werden, um langfristige Änderungen zu bewältigen und in Arbeit zu sein.

Wenn Sie dies nicht tun, beschäftigen Sie sich mit Zusammenführungsproblemen, veraltetem Code, Funktionen, die niemals veröffentlicht werden usw.

Option B. Nach Freigabe verzweigen

Vorteile:

• Sie können mit der Arbeit an der nächsten Iteration beginnen, während die aktuelle Iteration ihre Runde der Abnahmetests beendet.
• Andere Sachen bin ich mir sicher.

Nachteile:

• Tonnenweise Zweige.
• Es müssen noch Zweige an Freigabepunkten markiert werden.
• Sie müssen sich weiterhin mit WIP befassen und WIP aus dem Zweig der vorherigen Version in den Zweig der nächsten Version zusammenführen, wenn dies nicht der Fall ist, und müssen den Zweig der Version der Freigabe deaktivieren oder daran ziehen und die Abnahmetests erneut ausführen
• Hotfixes müssen auf mehr Zweige angewendet werden (Zweig + Hotfix + neues Tag freigeben + Hotfix in vnext-Zweig und möglicherweise vnextnext zusammenführen, je nachdem, wo der Hotfix liegt.)

Ich bin kein großer Fan dieser Lösung ^ _ ^.

Im Allgemeinen würde ich empfehlen, nur zu versuchen, sich an die Hauptlinie zu halten. Wenn Ihre Entwickler Probleme haben, kein WIP zu schreiben, das leicht gerissen werden kann, wenn der Schnitt fehlschlägt, oder das für die nächste Version frühzeitig eingecheckt wird, können Sie über das Markieren des Codes an der Stelle sprechen, an der der Code vollständig und verzweigt sein sollte von dort aus, falls erforderlich, um übersehene Fehler und Bugs zu beheben, die Ihre Entwicklertests nicht erkannt haben.

Im Idealfall sollte dies jedoch der Ausnahmeprozess sein, nicht die Regel.

Option C. Verrückte Bonusoption

Wenn Sie Lust haben, können Sie auch ein Verzweigungsmodell pro User-Story / pro Feature in Betracht ziehen. ( Eine schreckliche Idee in TFS oder einem anderen Nicht-DVCS, während sie gleichzeitig unglaublich trivial zu implementieren ist, wenn ein DVCS wie Git oder Mercurial verwendet wird. )

In der Vergangenheit habe ich das Folgende für ein früheres Wartungsteam des Arbeitgebers implementiert, das mit einer alten Codebasis arbeitete, die nicht einfach von svn auf mercurial portiert werden konnte. Es war eine Menge unnötiger Arbeit erforderlich, um die Geschäftsanforderungen einer immer freigebbaren Hauptleitung zu erfüllen, anstatt nur die Veröffentlichungen besser zu koordinieren, aber. . .

1. Die Funktionen wurden von Entwicklern in der Entwicklerabteilung ihres Teams entwickelt.
2. Wenn ein Feature zur Peer-Review bereit ist, bündeln die Entwickler es zu einer einzigen Zusammenführung vom Dev-Zweig zum CR-Zweig und fügen die Feature-ID / User Story in den Titel ein. * Erzwungen durch Pre-Commit-Hook *
3. Nach dem Bestehen von CR wird ein Admin-Tool verwendet, um die Funktion in den QA-Zweig zu befördern. (Ich habe eine kleine Terminalanwendung geschrieben, in der die in den verschiedenen Akzeptanzphasen vorhandenen User Stories aufgelistet sind, und dem Betreiber ermöglicht, sie zwischen diesen Akzeptanzphasen zu bewerben oder herabzustufen.)
4. QA führt Automatisierungs- und manuelle Usability-Tests durch. Wenn die Funktion gut ist, wird sie in den Release-Zweig (Hauptzeile) verschoben. Wenn die Funktion abgelehnt wird, wird sie aus dem QA-Zweig herabgestuft / zurückgesetzt, bis die Entwickler die während des Tests aufgetretenen Probleme beheben und einen Patch an den CR-Zweig senden können.
5. Wenn der Code aus dem QA-Zweig zurückgesetzt wurde und ein Fix angewendet wird, wendet das Terminal-Tool die erforderlichen Änderungen erneut an, um die Funktion aus dem CR-Zweig wieder in den QA-Zweig zu bringen, sodass die QA den Code erneut überprüfen und entweder heraufstufen oder fördern kann Herabstufung erneut.
6. Zu jedem Zeitpunkt sollte sich der Release-Zweig in einem stabilen freisetzbaren Zustand befinden.
7. Nach einer Veröffentlichung werden neue Entwickler, QS und CR von der Hauptlinie gesponnen.

Wir haben separate Filialen für jede Veröffentlichung, die wir veröffentlichen (ca. 4 pro Jahr). Dies ist sehr praktisch, wenn Sie eine bestimmte Version ziehen müssen.

Wenn Sie ein paar ältere Releases warten müssen, ist die Kennzeichnung meiner Meinung nach nicht ausreichend. Mit bestimmten Release-Zweigen können Sie Hotfixes für jeden Zweig separat (oder für eine Auswahl davon) anwenden, ohne sich um die anderen Releases kümmern zu müssen.

Dies erleichtert auch den Vergleich von Releases erheblich, wenn Sie nach einem Fehler oder einer Funktion suchen.

Machen Sie sich keine Sorgen über die Anzahl der Filialen oder die Zeit, in der sie unverändert bleiben. Ihr Versionsverwaltungssystem soll Ihnen die Kontrolle geben und einen Verlauf der Projektentwicklung liefern. Die Geschichte hat die Tendenz, sich nicht zu ändern ... Und machen Sie sich keine Sorgen, dass Ihre Lebensläufe nicht damit umgehen können. Wir verwenden Perforce, 9000+ Dateien in einem Entwicklungszweig, bis zu 50 Entwicklungszweige für die Version (en), an denen wir arbeiten, und wie bereits gesagt, einen einzelnen Zweig pro Version, die wir veröffentlichen. Perforce atmet nicht einmal schwerer.

Kurz gesagt: Erleichtern Sie sich das Leben als Entwickler / Betreuer / Bugfixer / Problemjäger und sorgen Sie sich nicht um die Anzahl der Zweige oder die Anzahl der Dateien. Jeder Lebenslauf mit Selbstachtung wird damit fertig.

Bearbeiten:

Wir sind überhaupt nicht verwirrt über die Anzahl der Filialen, die wir haben. Unser Namensschema für die Release-Zweige und unsere 1-Ausgabe-1-Zweigrichtlinie für die Entwicklungs- (oder Arbeits-) Zweige haben möglicherweise etwas damit zu tun.

Release-Zweige werden nach dem Release benannt, das sie enthalten, dh: R2011SP1 für Release 2011 Service Pack 1. Unsere Arbeitszweige haben weniger intelligente Namen: sub01, sub02, sub03 usw. Das "Sub" ergibt sich aus der Tatsache, dass alle Arbeitszweige Unterzweige sind der Akzeptanzbranche. In der Akzeptanzabteilung werden alle Probleme gesammelt, die zur Freigabe bereit sind.

Unsere 1-Problem-1-Arbeitszweigrichtlinie in Kombination mit der Tatsache, dass unser Problemverfolgungssystem mit einem "Zweig" -Feld angepasst wurde, stellt sicher, dass wir immer wissen, welches Problem in welchem ​​Zweig entwickelt wird. Wenn ein Problem in den Akzeptanzzweig integriert wird, wird dieses Feld aktualisiert. Dies bedeutet, dass wir immer wissen, welche Probleme zur Freigabe bereit sind (sobald der Abnahmetest abgeschlossen ist). In ähnlicher Weise aktualisieren wir dieses Feld, wenn ein Release-Zweig erstellt wird, und auf diese Weise können wir immer feststellen, in welchem ​​Release ein Problem veröffentlicht wurde.

Es geht nur um den Kontext: Wie oft veröffentlichen Sie und was ist in einer Veröffentlichung enthalten.

Hier ist eine kleine Fallstudie, die ich mit meiner alten Arbeit unter Verwendung der B- Methode hatte (wir haben sie absichtlich als Zweig bezeichnet ).

Um die Geschichte in einen Kontext zu setzen,

• Eine Version bestand aus neuen Funktionen in unserer Software: neuen Spielmodi, neuen Funktionen, neuen Konfigurationsoptionen.
• Der Veröffentlichungszyklus war ziemlich lang: Unsere Kunden waren Universitäten, die sich normalerweise ein Jahr lang an einen Funktionsumfang hielten.

Die Hauptentwicklung wurde im Trunk vorgenommen, bis wir für eine bestimmte Version einen vollständigen Status erreicht haben. Zu diesem Zeitpunkt würden wir einen Zweig erstellen, z. B. Projektname-Januar 2012, und unsere Qualitätstests und Fehlerbehebungen in diesem Zweig durchführen. Sobald wir für eine öffentliche Veröffentlichung bereit waren, markierten wir den Code in diesem Zweig und veröffentlichten ihn.

Die Entwicklung der Version endete jedoch nicht mit diesem Tag. Wir hatten unweigerlich Kunden, die Fehler oder kleine Probleme mit der Veröffentlichung fanden. Also in diesem Fall alles , was wir tun müssen, ist zu diesem Zweig zurück, den Code Patch und eine neue etikettierte Version des erstellen january2012 Zweig freigegeben werden, und fusionierte die Updates wieder mit dem Stamm.

In unserem Fall war dieser Ansatz günstig, weil einige Benutzer es vorzogen, bei älteren Versionen mit einem begrenzten Satz von Funktionen zu bleiben, oder einfach weil die Kosten für die Bereitstellung einer völlig neuen Version anstelle eines Hotfixes auf ihrer Infrastruktur einige Probleme verursachten.

Die Fragen, die Sie sich stellen müssen, sind:

• Wie oft lasse ich los?
• Werden meine Releases zu 100% abwärtskompatibel sein?
• Werden meine Kunden ein vollständiges Upgrade durchführen können, um Fehler zu beheben?

Wenn Sie häufig veröffentlichen, lohnt es sich möglicherweise nicht, für jeden Zweig einen Zweig zu haben. Wenn Ihr Release-Zyklus jedoch ziemlich lang ist wie mein alter Anwendungsfall und die Bereitstellung, die Abwärtskompatibilität und das Festhalten von Clients an alten Releases Risiken darstellen können, erspart Ihnen Option B mit Sicherheit viel Schmerz und erleichtert die Unterstützung erheblich Ihre Kunden zu minimalen Kosten für den Umgang mit Filialstörungen.

Ich bevorzuge Option A. Entwickeln Sie die Trunk- und Branch-Releases, wenn sie stabil sind. Dies schränkt die Arbeit bei der Integration von Hotfixes für die Produktionsfreigabe erheblich ein.

Ich wurde beauftragt, einem Team zu helfen, das versucht hat, Option B wieder auf Kurs zu bringen.

Ein paar Dinge zu beachten.

• Migrieren Sie Hotfixes vorwärts durch alle aktiven Codezweige. Dies kann durch Zusammenführen, Patchen und / oder Neuentwickeln erfolgen. Diese sollten vollständig verwaltet werden, um sicherzustellen, dass ein Fix auf alle entsprechenden Releases und dann auf Trunk angewendet wird.
• Berücksichtigen Sie Feature-Zweige, um die Entwicklung von Features isoliert vom Hauptcodestream zu ermöglichen. Diese werden für experimentelle Änderungen empfohlen. Sie können Feature-Zweige jederzeit verlassen, wenn das Feature nicht funktioniert.
• Markieren und verfolgen Sie Ihre Zusammenführungspunkte.
• Verzweigen Sie Ihre Releases bei Bedarf. Ich finde, dass dies normalerweise der Fall ist, wenn die Version für Release Candidate Builds bereit ist. In einigen Fällen kann die Einführung inkompatibler Änderungen am Rumpf eine frühzeitige Verzweigung erzwingen. Betrachten Sie einen Feature-Zweig.

Ich habe einige Jahre an einem System gearbeitet, das etwas zwischen den beiden von Ihnen beschriebenen Schemata verwendet. Der Schlüssel ist, dass ein mehrstufiges Nummerierungsschema verwendet wird. Die äußere Ebene ist im Grunde die API-Version, die in Zweigen verwaltet wird (mit entsprechenden Cross-Merges, wenn etwas in mehreren Zweigen behoben werden muss), und die innere Ebene ist die genaue Version, die mit Tags verwaltet wird.

Insbesondere wenn wir wissen, über welche genaue Version ein Kunde verfügt, wissen wir genau, aus welcher Quelle der Code erstellt wurde, und können ein genaues Duplikat erstellen, damit wir genau sehen können, was gerade passiert. Dies ist sehr wichtig für die Unterstützung! Die äußere Ebene der Zweige, die API-Versionen, die wir derzeit veröffentlichen, entwickelt sich jedoch im Laufe der Zeit weiter (wobei der Hauptstamm der Entwicklung die meisten neuen Funktionen erhält). Wenn wir eine neue Hauptversion der API erstellen, erstellen wir einen neuen Zweig, um dies von zu unterstützen (sodass der Trunk immer auf die Entwicklung des Hardcore-Kerns ausgerichtet sein kann), und wir überlegen, ob wir die derzeit älteste Unterstützung am Ende der Lebensdauer ausführen sollen Ast.

Daher empfehle ich etwas, das wirklich eine Mischung aus A und B ist . beide haben gute Aspekte, aber keiner ist an sich vollständig. Nutzen Sie das Beste aus beiden Welten.

Ich habe in der Vergangenheit TFS verwendet, um Option (B) effektiv zu implementieren.

Das Verzweigen / Zusammenführen ist ein großartiges Werkzeug, wenn es in kleinen Stücken ausgeführt wird. Die Schwierigkeit besteht nicht darin, einen Zweig zu erstellen (das ist einfach dumm) oder eine Woche Arbeit wieder in den Baum zu schieben (das ist normalerweise auch einfach) ... es liegt darin, das CI-System hinter Ihrer Quellcodeverwaltung automatisch zum Laufen zu bringen Sie.

Weil die Verzweigung umstritten ist, wenn das System nicht automatisch Tests für Ihre Verzweigung erstellt und ausführt.

Wir hatten den Standard-Build-Workflow von TFS angepasst, um die relativen Pfade von Änderungssätzen zu erkennen, und eine Konvention festgelegt, anhand derer die Anpassung einen neuen Zweig erkennen konnte (im Gegensatz zu einfach einem neuen Unterordner unter einem Entwicklungsstamm). Es war reibungslos, leicht zu verzweigen, leicht zu verzweigen, und wir erhielten kontinuierliches Feedback von unserem System für Kompilierungen und Tests.

Ich sehe viele Leute, die erklären, wie unmöglich diese Strategien unter TFS sind, und ich glaube, dass dies auf mangelnde Kenntnis der Möglichkeiten einer XAML-basierten Build-Engine zurückzuführen ist. TFS ist nicht nur Quellcodeverwaltung, sondern eine vollständige Lösung und sollte als solche verwendet werden.