Strategische Verzweigungen
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Quellcode ist eine wichtige Ressource in der Entwicklung. Es kann jedoch eine Herausforderung sein, Quelldateien effektiv zu verwalten und zu entwickeln, wenn mehrere Entwickler gleichzeitig an Dateiupdates arbeiten. Sie können mithilfe eines Versionskontrollsystems Quellcode in freigegebenen Repositorys speichern, parallel laufende Entwicklungsmaßnahmen isolieren, Codeänderungen integrieren und vorherige Dateiversionen wiederherstellen. Ein Schlüsselelement in der Versionskontrolle ist der Branch, der gleichzeitiges Entwickeln ermöglicht. Wenn Sie strategische Branches verwenden, können Sie die Reihenfolge und Konsistenz mehrerer Versionen der Software aufrechterhalten.
Team Foundation bietet ein flexibles und zuverlässiges Versionskontrollsystem. Team Foundation-Versionskontrolle ermöglicht das Verwalten von mehreren Revisionen bei der Entwicklung von Quellcode, Dokumenten, Arbeitsaufgaben und anderen wichtigen Informationen, an denen Ihr Team arbeitet.
Wie verwaltet das Team Code, während es mehrere Änderungen gleichzeitig in mehreren Projektreleases einführt?
Wenn Sie mit einem Versionskontrollsystem arbeiten, müssen Sie überlegen, wie eine Branchstruktur eingerichtet wird. Sie können einen Branch erstellen, indem Sie die Quellcodedatei spiegeln. Anschließend können Sie die Verzweigung ändern, ohne die Quelle zu beeinflussen. Wie die Branchstruktur in der folgenden Abbildung zeigt, enthält der MAIN-Branch abgeschlossene Funktionen, die die Integrationstests erfolgreich bestanden haben, während der DEVELOPMENT-Branch den Code enthält, der gegenwärtig erstellt wird. Wenn eine neue Funktion in der DEVELOPMENT-Verzweigung fertig gestellt wird und Integrationstests erfolgreich verlaufen, können Sie den Code von der DEVELOPMENT-Verzweigung auf die MAIN-Verzweigung heraufstufen. Dieser Prozess wird als Rückwärtsintegration bezeichnet. Im umgekehrten Fall spricht man bei der Zusammenführung des Codes von dem MAIN-Branch zum DEVELOPMENT-Branch von Vorwärtsintegration.
Weitere Informationen zum Erstellen und Zusammenführen von Codebranches finden Sie auf der folgenden Seite der CodePlex-Website zum Team Foundation Server-Leitfaden 2.0 zum Branching.
Für Branchen und Zusammenführen gelten die folgenden Prinzipien:
Für jeden Branch wird eine definierte Richtlinie zur Integration von Code in den Branch benötigt. In der Verzweigungsstruktur der vorherigen Abbildung können Sie z. B. ein Teammitglied zuweisen, das die MAIN-Verzweigung besitzen und verwalten soll. Dieses Mitglied ist für folgende Vorgänge zuständig: Ausführen des anfänglichen Verzweigungsvorgangs, Rückwärtsintegration von Änderungen von der DEVELOPMENT-Verzweigung in die Hauptverzweigung und Vorwärtsintegration von Änderungen von der MAIN-Verzweigung in die DEVELOPMENT-Verzweigung. Vorwärtsintegration ist wichtig, wenn in die MAIN-Verzweigung auch Änderungen von anderen Verzweigungen integriert werden.
Die MAIN-Verzweigung muss Code enthalten, der Integrationstests bestanden hat, damit er jederzeit freigegeben werden kann.
Der DEVELOPMENT (oder Arbeit)-Branch wird ständig weiterentwickelt, da Teammitglieder in regelmäßigen Abständen Änderungen einchecken.
Bezeichnungen sind Momentaufnahmen der Dateien in einer Verzweigung zu einem bestimmten Zeitpunkt.
Weitere Informationen finden Sie unter Verwenden von Bezeichnungen zum Erstellen einer Momentaufnahme der Dateien.
Team Foundation Build ermöglicht Ihnen die Auswahl verschiedener Arten von Builds für die Verzweigungen: manuell, fortlaufend, abgegrenzt, rollend und geplant. Es wird empfohlen, dass der MAIN-Branch über einen abgegrenzten Eincheckbuildtyp verfügt. Das bedeutet, dass die DEVELOPMENT-Verzweigung alle Anforderungen für die MAIN-Verzweigung erfüllen muss, bevor Sie einen Commit für eine Rückwärtsintegration ausführen können. Für den DEVELOPMENT-Branch sollte ein fortlaufender Buildtyp ausgeführt werden, da das Team so schnell wie möglich über neue Eincheckvorgänge informiert muss, die den DEVELOPMENT-Branch betreffen.
Wie oft sollte das Team Änderungen rückwärts und vorwärts integrieren?
Wie die folgende Abbildung zeigt, sollte die Rückwärts- und Vorwärtsintegration zumindest beim Abschluss einer User Story ausgeführt werden. Obwohl unter Umständen jedes Team Vollständigkeit anders definiert, bedeutet der Abschluss einer User Story im Allgemeinen, dass Sie sowohl die Funktionalität als auch die entsprechenden Komponententests abschließen. Sie können erst eine Rückwärtsintegration in den MAIN-Branch ausführen, wenn Sie die Stabilität des DEVELOPMENT-Branches überprüft haben.
Wenn Sie mehr als eine Arbeitsverzweigung (d. h. DEVELOPMENT-Verzweigung) verwenden, wird die Vorwärtsintegration in alle Arbeitsverzweigungen ausgeführt, sobald eine beliebige Verzweigung in die MAIN-Verzweigung integriert wird. Da die MAIN-Verzweigung stabil gehalten wird, ist die Vorwärtsintegration sicher. Konflikte oder Fehler in den Arbeitsbranches können auftreten, da Sie nicht garantieren können, dass die Arbeitsbranches stabil sind.
Es ist wichtig, dass alle Konflikte so schnell wie möglich gelöst werden. Durch Verwendung eines abgegrenzten Eincheckens für die MAIN-Verzweigung wird die Rückwärtsintegration deutlich vereinfacht, da Qualitätstore zur Vermeidung von Konflikten oder Fehlern in der MAIN-Verzweigung beitragen. Weitere Informationen finden Sie unter Einchecken in einen Ordner, der von einem Gated-Check-In-Buildprozess gesteuert wird.
Wie verwaltet das Team Quellcodedateien, die unterschiedliche User Storys implementieren?
Wie die folgende Abbildung zeigt, können Sie Änderungen an einer Arbeitsverzweigung regelmäßig einchecken, um eine User Story fertig zu stellen. Sie können zur gleichen Zeit mehrere User Storys in dem gleichen Branch implementieren. Sie können jedoch nur dann eine Rückwärtsintegration in den Hauptbranch ausführen, wenn Sie die gesamte derzeit ausgeführte Arbeit abschließen. Es wird empfohlen, dass Sie User Storys nach ähnlicher Größe gruppieren, da Sie die Integration kleiner User Storys nicht durch eine große User Story blockieren möchten. Sie können die zwei Sätze von User Storys in zwei Verzweigungen aufteilen.
Wann sollte das Team einen Branch hinzufügen?
Verzweigungen sollten in den folgenden Situationen erstellt werden:
Wenn Code in einem anderen Zeitplan/Zyklus freigegeben werden muss als die vorhandenen Branches.
Wenn für den Code eine andere Branchrichtlinie erforderlich ist. Wenn ein neuer Branch erstellt wird, der die neue Richtlinie besitzt, kann der strategische Wert des Projekts erhöht werden.
Wenn Funktionen an einen Kunden freigegeben werden und das Team Änderungen vornehmen möchte, die den geplanten Freigabezyklus nicht beeinflussen.
Sie sollten keinen Branch für jede User Story erstellen, da dadurch hohe Integrationskosten entstehen. Obwohl TFVC das Erstellen von Branches vereinfacht, kann der Aufwand für deren Verwaltung bedeutsam werden, wenn Sie viele Branches besitzen.
Wie verwaltet das Team Releases aus der Perspektive der Versionskontrolle?
Das Team sollte in der Lage sein, am Ende eines Sprints Code freizugeben. Mit Team Foundation Server können Sie einen Branch bezeichnen, um eine Momentaufnahme des Codes zu einem bestimmten Zeitpunkt zu erstellen. Entsprechend der folgenden Abbildung können Sie die MAIN-Verzweigung für eine Version bezeichnen. Auf diese Weise können Sie den Status des Branches an diesem Punkt wiederherstellen.
Da für Freigaben u. U. Updates implementiert werden müssen, bietet das Erstellen eines Branches für eine Freigabe dem Team die Möglichkeit, unabhängig am nächsten Sprint zu arbeiten, ohne Konflikte mit künftigen Freigaben zu verursachen. Die folgende Abbildung zeigt einen Branch, der Code für ein Update enthält und nach einer Freigabe am Ende des zweiten Sprints rückwärts in den MAIN-Branch integriert wird.
Wenn Sie eine Verzweigung für eine Freigabe erstellen, sollte dieser Schritt von der MAIN-Verzweigung aus erfolgen, da diese am stabilsten ist. Eine Verzweigung für eine Freigabe von einer Arbeitsverzweigung kann Probleme bei der Integration verursachen, da die Stabilität der Arbeitsverzweigungen nicht garantiert ist.