Auswählen einer effektiven Branchingstrategie

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Das Erstellen von Branches für Ihre Team Foundation-Versionskontrollrepositorys (TFVC) ist nützlich, um Risiken zu isolieren. Beachten Sie einige Herausforderungen, denen Teammitglieder häufig gegenüberstehen, wenn sie mit mehr als fünf oder zehn anderen an einem Softwareprojekt arbeiten:

• Die Gruppe hat einige (oder auch mehrere) verschiedene Featureteams, von denen jedes an einem Teil der Funktionalität arbeitet, der ziemlich unabhängig ist. Aber jedes Team ist auch auf die von anderen Teams erstellte Funktionalität angewiesen. Sie müssen das Risiko der Änderungen isolieren, die von der in jedem dieser Teams erledigten Arbeit eingearbeitet werden, und gleichzeitig müssen Sie die gesamte Arbeit in einem Produkt zusammenführen.

• Das Testteam benötigt eine stabile Version des zu testenden Codes, und gleichzeitig müssen die Entwickler mit neuen Features vorankommen, die gelegentlich das Produkt destabilisieren.

• Die Software hat zwei frühere Versionen, und eine aktuelle Version wird bearbeitet. Obwohl der Großteil der Entwicklung in die aktuelle Version investiert wird, müssen die früheren Versionen immer noch mit gelegentlichen Freigaben von Service Packs, wichtigen Korrekturen, Sicherheitspatches und anderen Änderungen unterstützt werden.

In diesem Artikel werden einige gängige Branchingstrategien erläutert, die Ihnen helfen sollen, die richtige Entscheidung zu treffen.

Im Gegensatz zu Git-Branches, deren Bereich das Repository ist, ist der Bereich von TFVC-Branches der Pfad, was sie somit weniger schlank macht. Legen Sie die Messlatte für das Erstellen von Branches hoch, und branchen Sie nur dann, wenn Code- oder Releaseisolation wirklich erforderlich ist.

Nur „main“

Die Nur „main“-Strategie kann ordnerbasiert sein oder mit dem Ordner main, der in einen Branch konvertiert wurde, verfolgt werden, um zusätzliche Sichtbarkeitsfeatures zu aktivieren. Sie committen Ihre Änderungen in den Mainbranch und zeigen Entwicklungs- und Releasemeilensteine optional mit Bezeichnungen an.

RISIKO: Die Veränderbarkeit und der fehlende Verlauf mit TFVC-Bezeichnungen können das Risiko der Änderungssteuerung mit sich bringen.

Beginnen Sie mit der „Nur main“-Branchingstrategie, branchen Sie strategisch, und übernehmen Sie andere Strategien, um bei Bedarf komplexere Strategien zu entwickeln.

Entwicklungsisolation

Wenn Sie einen stabilen Mainbranch aufrechterhalten und schützen müssen, können Sie einen oder mehrere dev-Branches aus main verzweigen. Dies ermöglicht Isolation und gleichzeitige Entwicklung. Arbeit lässt sich in Entwicklungsbranchen (dev) nach Feature, Organisation oder vorübergehender Zusammenarbeit isolieren.

Es ist möglich, dass es Änderungen im Mainbranch gibt. Führen Sie immer eine Vorwärtsintegration (FI, Forward Integration) des Mainbranchs in den dev-Branch aus, und lösen Sie Mergekonflikte auf. Führen Sie dann eine Rückwärtsintegration (RI, Reverse Integration) der Änderungen zurück in den Mainbranch aus. Behalten Sie den selben Qualitätsmaßstab für alle Branches bei. Führen sie Buildvorgänge sowie Buildüberprüfungstests (BVTs) in dev auf dieselbe Weise wie in main durch.

HINWEIS: Mit dieser Strategie können Teams den dev-Branch wahrscheinlich für immer erhalten und so möglicherweise einen umfangreichen Mergeticketverlauf aufbauen.

Featureisolation

Die Featureisolation ist eine spezielle Ableitung von der Entwicklungsisolation, mit der Sie einen oder mehrere Feature-Branches aus main (wie gezeigt) oder aus Ihren dev-Branches verzweigen können.

Wenn Sie an einem bestimmten Feature arbeiten müssen, kann es eine gute Idee sein, einen Featurebranch zu erstellen.

Halten Sie die Lebensdauer der Featurearbeit und des zugehörigen Featurebranchs kurz. Führen Sie häufig eine Vorwärtsintegration (FI) von Änderungen aus dem übergeordneten Branch durch. Führen Sie eine Rückwärtsintegration (RI) zurück in den übergeordneten Branch nur durch, wenn vereinbarte Teamkriterien erfüllt sind, z. B. die Definition von „Fertig“ (Done). Ein Rollback von Features in main kann kostspielig sein und Tests zurücksetzen.

Releaseisolation

Releaseisolation führt mindestens einen Releasebranch aus main ein. Die Strategie ermöglicht gleichzeitige Releaseverwaltung, mehrere und parallele Releases sowie Codebase-Momentaufnahmen zur Releasezeit.

Wenn das Release bereit für die Sperrung ist, ist es an der Zeit, einen neuen Branch für das Release zu erstellen.

Führen Sie nie eine Vorwärtsintegration (FI) aus main durch. Sperren Sie Releasebranches mithilfe von Zugriffsberechtigungen, um unbeabsichtigte Änderungen an einem Release zu verhindern. Patches und HotFixes, die am Releasebranch vorgenommen wurden, können mittels Rückwärtsintegration (RI) zurück in den Mainbranch überführt werden.

HINWEIS: Keins der Branchingszenarien ist unveränderlich, weshalb Sie feststellen werden, dass Notfall-Hotfixes in Releasebranches ausgeführt werden. Entwickeln Sie jede Strategie so, dass sie Ihren Anforderungen entspricht, ohne die Komplexität und die damit verbundenen Kosten aus den Augen zu verlieren.

Wartungs- und Releaseisolation

Die Wartungs (Servicing)- und Releaseisolationsstrategie führt Servicing Branches ein. Diese Strategie ermöglicht die gleichzeitige Dienstverwaltung von Service Packs sowie Codebase-Momentaufnahmen zur Releasezeit.

Verwenden Sie diese Strategie, wenn Sie ein Wartungsmodell für Kunden benötigen, um ein Upgrade auf die nächste Hauptversion sowie zusätzliche Service Packs pro Release durchzuführen.

Wie die Releaseisolation werden die Wartungsisolation und die Releasebranches erstellt, wenn das Release für die Sperrung bereit ist. Führen Sie niemals eine Vorwärtsintegration (FI) aus main in Servicing oder aus Servicing in Release durch. Sperren Sie den Releasebranch, um Änderungen zu verhindern. Zukünftige Wartungsänderungen können im Servicing Branch vorgenommen werden.

Erstellen Sie neue Servicing und Releasebranches für nachfolgende Releases, wenn Sie diesen Grad an Isolation benötigen.

Wartungs-, Hotfix-, Releaseisolation

Obwohl es nicht empfohlen wird, können Sie die Strategien weiterentwickeln, indem Sie zusätzliche Hotfix-Branches und zugehörige Releaseszenarien einführen.

An diesem Punkt haben Sie einige der gängigen TFVC-Branchingszenarien erfolgreich erkundet. Sie können sie weiterentwickeln oder andere Strategien untersuchen, z. B. Umschalten von Features, also das Ein- und Ausschalten von Features, um festzustellen, ob ein Feature zur Laufzeit verfügbar ist.

Fragen und Antworten

Warum sollten Branches kurzlebig sein?

Dadurch, dass Branches kurzlebig bleiben, werden Mergekonflikte so gering wie möglich gehalten.

Warum nur bei Bedarf branchen?

Um DevOps zu nutzen, müssen Sie sich auf die Automatisierung von Erstellung (Build), Tests und Bereitstellung verlassen. Veränderung ist kontinuierlich, häufig und Mergevorgänge sind schwieriger, da Mergekonflikte häufig manuelles Eingreifen erfordern. Es wird daher empfohlen, das Branchen zu vermeiden und sich auf andere Strategien zu verlassen, z. B. das Umschalten von Features.

Warum sollten Sie Branches entfernen?

Ihr Ziel sollte es sein, Änderungen so schnell wie möglich wieder in den Mainbranch zu integrieren, um langfristige Mergefolgen abzumildern. Temporäre, nicht verwendete und übermäßige Branches führen zu Verwirrung und Mehraufwand für das Team.

Kann eine Codebasis projektübergreifend gebrancht werden?

Ja. Dies wird aber nicht empfohlen, es sei denn, Teams müssen die Quelle gemeinsam nutzen und können einen gemeinsamen Prozess nicht freigeben.

Was ist mit der Code-Promotion-Strategie?

Die Code-Promotion-Strategie fühlt sich wie ein Relikt aus der Ära der Wasserfallentwicklung an. Sie kommt typischerweise bei langen Testzyklen und getrennten Entwicklungs- und Testteams vor. Die Strategie wird nicht mehr empfohlen. Weitere Informationen zu dieser Strategie finden Sie im Branching-Leitfaden.

Warum werden beim Zusammenführen von dev- und Mainbranch keine Änderungen erkannt?

Sie haben wahrscheinlich Änderungen bei früheren Zusammenführungen ignoriert, z. B. mithilfe der keep source-Konfliktlösungsoption. Weitere Informationen finden Sie unter Zusammenführen des Entwicklungsbranchs in Main: Keine zusammenzuführenden Änderungen .

Gibt es Ähnlichkeiten zwischen TFVC- und Git-Branchstrategien?

Die TFVC-Branchingstrategie für Featureisolation ähnelt den Git-Topic-Branches.

Autor*innen: Jesse Houwing, Marcus Fernandez, Mike Fourie und Willy Schaub von ALM | DevOps Rangers. Sie können hier Kontakt mit ihnen aufnehmen.

(c) 2015 Microsoft Corporation. Alle Rechte vorbehalten. Dieses Dokument wird „wie besehen“ zur Verfügung gestellt. Die in diesem Dokument enthaltenen Informationen und zum Ausdruck gebrachten Ansichten, auch URL- und andere Internet-Websitebezüge, können ohne vorherige Ankündigung geändert werden. Sie tragen das alleinige Verwendungsrisiko.

Dieses Dokument stellt keinerlei Rechtsansprüche auf geistiges Eigentum in Microsoft-Produkten jeglicher Art bereit. Dieses Dokument darf für interne Referenzzwecke kopiert und verwendet werden.