Strategische Verzweigungen

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 die Verzweigung, die gleichzeitiges Entwickeln ermöglicht. Wenn Sie strategische Verzweigungen 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. Weitere Informationen über Versionskontrolle in Visual Studio Team Foundation Server finden Sie unter Verwenden der Versionskontrolle.

Wie verwaltet das Team Code, während es mehrere Änderungen gleichzeitig in mehreren Projektversionen einführt?

Wenn Sie mit einem Versionskontrollsystem arbeiten, müssen Sie überlegen, wie eine Verzweigungsstruktur eingerichtet wird. Sie können eine Verzweigung erstellen, indem Sie die Quellcodedatei spiegeln. Anschließend können Sie die Verzweigung ändern, ohne die Quelle zu beeinflussen. Wie die Verzweigungsstruktur in der folgenden Abbildung zeigt, enthält die MAIN-Verzweigung abgeschlossene Funktionen, die die Integrationstests erfolgreich bestanden haben, während die DEVELOPMENT-Verzweigung 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 der MAIN-Verzweigung zur DEVELOPMENT-Verzweigung von Vorwärtsintegration.

Weitere Informationen zum Erstellen und Zusammenführen von Codeverzweigungen finden Sie auf der folgenden Seite der CodePlex-Website zum Team Foundation Server-Verzweigungshandbuch 2.0.

Für Verzweigung und die Zusammenführung gelten die folgenden Prinzipien:

1. Für jede Verzweigung wird eine definierte Richtlinie zur Integration von Code in die Verzweigung 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.

2. Die MAIN-Verzweigung muss Code enthalten, der Integrationstests bestanden hat, damit er jederzeit freigegeben werden kann.

3. Die DEVELOPMENT (oder Arbeit)-Verzweigung wird ständig weiterentwickelt, da Teammitglieder in regelmäßigen Abständen Änderungen einchecken.

4. 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 die MAIN-Verzweigung ü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 die DEVELOPMENT-Verzweigung sollte ein fortlaufender Buildtyp ausgeführt werden, da das Team so schnell wie möglich über neue Eincheckvorgänge informiert muss, die die DEVELOPMENT-Verzweigung 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 die MAIN-Verzweigung ausführen, wenn Sie die Stabilität der DEVELOPMENT-Verzweigung ü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 Arbeitsverzweigungen können auftreten, da Sie nicht garantieren können, dass die Arbeitsverzweigungen stabil sind.

Es ist wichtig, dass alle Konflikte so schnell wie möglich gelöst werden. Durch Verwendung eines abgegrenzten Eincheckvorgangs 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 ausstehender Änderungen für einen abgegrenzten Eincheckbuild.

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 der gleichen Verzweigung implementieren. Sie können jedoch nur dann eine Rückwärtsintegration in die Hauptverzweigung 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 eine Verzweigung hinzufügen?

Verzweigungen sollten in den folgenden Situationen erstellt werden:

• Wenn Code in einem anderen Zeitplan/Zyklus freigegeben werden muss als die vorhandenen Verzweigungen.

• Wenn für den Code eine andere Verzweigungsrichtlinie erforderlich ist. Wenn eine neue Verzweigung erstellt wird, die 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 keine Verzweigung für jede User Story erstellen, da dadurch hohe Integrationskosten entstehen. Obwohl das Erstellen von Verzweigungen vereinfacht, kann der Aufwand für die Verwaltung von Verzweigungen, bedeutsam werden, wenn Sie viele Verzweigungen besitzen.

Wie verwaltet das Team Freigaben 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 eine Verzweigung 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 der Verzweigung an diesem Punkt wiederherstellen.

Da für Freigaben u. U. Updates implementiert werden müssen, bietet das Erstellen einer Verzweigung 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 eine Verzweigung, die Code für ein Update enthält und nach einer Freigabe am Ende des zweiten Sprints rückwärts in die MAIN-Verzweigung 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.