Die besten Verzweigungsstrategien für eine schnelle Entwicklung

Verzweigungsstrategien ‒ wie Feature-Verzweigung oder Trunk-basierte Entwicklung ‒ können Entwicklungsteams helfen, schneller zu agieren. Man kann damit die parallele Entwicklung lenken, was es den Entwicklern ermöglicht, als Teil eines Teams simultan an Aufgaben zu arbeiten. Und parallele Builds und Tests helfen den Entwicklern, schnell das erforderliche Feedback zu erhalten.

Aber wenn Projekte und Teams größer werden, wird die parallele Arbeit immer komplexer. Denn es geht nicht mehr nur darum, die Änderungen innerhalb eines Teams zusammenzuführen. Bei komplexen Produkten gibt es mehrere Teams, die den Quellcode integrieren müssen.

Innerhalb eines bestehenden Teams hilft die Strategie „früh und häufig zusammenführen“, mit diesem Problem umzugehen. Aber Integrationen zwischen den Teams werden häufig auf einen späteren Zeitpunkt im Entwicklungszyklus verschoben. Wenn man den gesamten Quellcode kurz vor dem Ende zusammenführt, kann das zu massiven Merge-Konflikten und Verzögerungen beim Release führen.

Aber deine Teams brauchen die Qualität nicht der Schnelligkeit wegen zu opfern. Es gibt eine bessere Strategie für das Verzweigen des Quellcodes.

Indem dein Team häufiger verzweigt und zusammenführt, kann es produktiver sein. Die Implementierung der richtigen Verzweigungsstrategie kann helfen, deine Anstrengungen bei der parallelen Entwicklung zu unterstützen (egal, wie groß dein Team oder dein Projekt ist).

So kannst du bessere Produkte entwickeln und deine Code-Basis stabil halten. Da die Teammitglieder in der Lage sind, an Teilen des Quellcodes zu arbeiten, ohne andere zu beeinträchtigen, können sie mehr schaffen.

Grundlagen der Verzweigung

Das Verzweigen von Quellcode hilft Softwareentwicklerteams, parallel zu arbeiten. Sie können die Branches nutzen, um Änderungen zu koordinieren und an einer gemeinsamen Code-Basis zusammenzuarbeiten.

Um mit dem Verzweigen zu beginnen, brauchen die Teams eine Versionskontrolle. Versionskontrollsysteme (version control systems, VCS) organisieren den Quellcode, speichern die Arbeit der Entwickler und ermöglichen es Teams, Änderungen durchzuführen und durchzusetzen.

Wenn beim Verzweigen ein Branch erstellt wird, erstellt das VCS einen Speicherauszug der Code-Basis. Und wenn die Dateien verändert werden, können die Teams die Änderungen zusammenführen. Branches können für Features, das Aktualisieren des Frameworks, zum Erstellen gemeinsamer Komponenten und zum Verwalten von Releases verwendet werden.

Mit VCS beginnen

Du kannst kostenlos mit einem VCS von Perforce ‒ Helix Core ‒ beginnen. Lade Helix Core herunter und du kannst noch heute besser verzweigen. 

Verzweigung mit Perforce

Was ist eine Verzweigungsstrategie?

Verzweigungsstrategien werden verwendet, um die Arbeit zu koordinieren; sie ermöglichen eine einfachere Integration von Änderungen und Releases. Sie erschaffen einen Entwicklungs-Workflow.

Warum man das braucht

Bei Teams, die aus Hunderten oder Tausenden von Entwicklern bestehen, können Verzweigung und Zusammenführung schwierig sein. Schlechte Merges und Integrationen kurz vor dem Ende beanspruchen die Zeit der Entwickler und verzögern damit möglicherweise zukünftige Arbeit oder Releases.

Damit deine Teams weniger Sorgen (und Aufwand) haben, sollte deine Verzweigungsstrategie auf folgende Ziele ausgerichtet sein:

• Produktivität erhöhen
• Paralleles Entwickeln ermöglichen
• Eine Reihe geplanter, strukturierter Releases erlauben
• Einen eindeutigen Verbreitungspfad für die Softwareänderungen bis zur Produktion bereitstellen
• Evolution, um bereitgestellten Änderungen Rechnung zu tragen, vielleicht täglich
• Mehrere Versionen der veröffentlichten Software und Patches unterstützen

Welche Verzweigungsstrategien gibt es?

Der Punkt einer Verzweigungsstrategie besteht darin, Änderungen am Quellcode effizient zu verwalten. Dieser Workflow wirkt sich sowohl auf die Entwicklungs- als auch auf die Deployment-Workflows aus.

Verzweigung nach Feature (Aufgabenverzweigung)

Die Feature-Verzweigung ermöglicht es den Entwicklern, einen Branch für ein bestimmtes Feature oder eine Aufgabe zu erstellen. Diese werden häufig als User Storys bezeichnet. In diesem Workflow mit einem Branch je Problem können die Entwickler separat arbeiten.

Beispielsweise könnte ein Team oder eine Person einen aggressiven Fehler tief im Quellcode beheben, während ein anderes Team einen neuen Workflow für den Endbenutzer kreiert. Jedes Team kann unabhängig an der ihm zugeordneten Aufgabe arbeiten und die Veränderungen in die Basis (Mainline) einpflegen, wenn die Arbeit erledigt ist.

Vorteile der Feature-Verzweigung

Wenn die Entwickler unabhängig vom Kernprodukt experimentieren und arbeiten können, kann das die Code-Basis stabil halten. Diese Strategie gibt deinem Team die Freiheit, innovativ zu sein, und du kannst Workflows für CI/CD implementieren.

Sie hilft den Entwicklern auch, ihre Arbeit schon früh aufzuteilen. Statt sich mit einem vollständigen Release abzumühen, können sie sich auf kleine Sets mit Änderungen konzentrieren. Die Feature-Branches können außerdem nach spezifischen Feature-Gruppen aufgeteilt werden. Jedes Team oder untergeordnete Team kann für die Entwicklung seinen eigenen Branch beibehalten. Wenn die Arbeit beendet ist, können die Änderungen getestet und geprüft werden, bevor die Branches wieder zusammengeführt werden.

Bei der Nutzung der Feature-Verzweigung für große Unternehmen/Code-Basen ist es wichtig, die Änderungen häufig teamübergreifend zu integrieren.

Indem man alle Änderungen schon früh im Entwicklungszyklus integriert, kann man teure Konflikte vermeiden, deren Auflösung wirklich lange dauern würde.

Nachteile der Feature-Verzweigung (und was man dagegen tun kann)

Der Zweck von Feature-Branches besteht darin, dass der Branch besteht, solange das Feature entwickelt wird. Und damit haben viele Teams zu kämpfen. Langlebige Feature-Branches sind beim Merging ein Alptraum. Denn um Konflikte zu vermeiden, könnten Entwickler längere Zeit isoliert arbeiten. Aber dadurch entstehen sogar noch mehr Probleme.

Feature-Branches funktionieren nur, wenn die Entwickler (und Teams) häufig verzweigen und zusammenführen.

In vielen Entwicklerforen spricht man darüber, mindestens einmal täglich zu mergen. Aber viele Teams befolgen dieses bewährte Verfahren nicht. Und darüber hinaus gibt es bei den meisten VCS-Systemen keine Option zum Einblick in die Basis. Muss man überhaupt mergen? Gibt es neue Änderungen?

Bei diesem Problem ist es hilfreich, für jeden Feature-Branch eine Testumgebung zu erschaffen. Du solltest auch Feature-Branches früh in deinen Entwicklungszyklus integrieren. Dann kannst du häufiger testen und einrichten, um sicherzustellen, dass zwischen den Branches keine Probleme bestehen. Das Testen des Quellcodes auf der Produktionsebene hilft sicherzustellen, dass der Code erst eingeführt wird, wenn er fertig ist.

Verzweigungsstrategie Feature-Flag für kontinuierliche Übermittlung

Das Ziel von DevOps-Teams besteht darin, häufig zu testen, indem sie häufig builden. Mit kontinuierlichem Integrieren, Testen und Übermitteln des Quellcodes zurück zu den Entwicklern wird sichergestellt, dass die Teams Fehler früh bemerken und Probleme schnell lösen.

Um diese Art der Entwicklung zu unterstützen, implementieren manche Teams Feature-Toggles bzw. -Flags, statt einen separaten Feature-Branch zu erhalten. Der Vorteil besteht darin, dass die gesamte Arbeit direkt aus der Mainline erfolgen kann. Das bedeutet weniger Branches und minimales Mergen.

Durch die Nutzung von Feature-Toggles können Teile des Quellcodes während des Build-Prozesses ein- oder ausgeschaltet werden. Feature-Flags können Teams helfen, Skalierungen schnell durchzuführen. Aber es verlangsamt sie im Laufe der Zeit, sobald Projekte und Teams größer werden.

Bei einer monolithischen Code-Basis kann es kostenaufwendig sein, dies aufrechtzuerhalten. Die Flags müssen für jedes neue Feature auf der Programmierungsebene hinzugefügt werden. Und die Admins müssen Scripts schreiben, um sie zu verwalten. Damit wird den DevOps-Teams, die an einer Build-Automatisierung arbeiten, die wirklich helfen kann, schneller zu liefern, Zeit genommen.

[Blog zu ähnlichem Thema: Wie man die Software Delivery Pipeline optimiert]

Verzweigung nach Release

Bei der Verzweigung nach Release wird für jedes potenzielle Release ein Branch erstellt, der alle anwendbaren Storys enthält. Der Branch wird erstellt, wenn ein Team beginnt, an einem neuen Release zu arbeiten.

Bei Teams, die mit der Zeit mehrere Releases und Patch-Versionen unterstützen müssen, ist die Verzweigung nach Release erforderlich. Die Teams können innerhalb der Basis an allen User Storys für dieses spezifische Release arbeiten.

Häufig werden je nach Art des Releases unterschiedliche Verzweigungsstrategien befolgt. Beispielsweise kann es bei großen Releases zusätzlich zum Release-Branch aus diesem heraus eine Feature-/Team-basierte Verzweigungsstrategie nutzen, wobei Patches/Hotfixes direkt in den Release-Branch eingearbeitet werden.

Vorteile der Verzweigung nach Release

Wenn man an einem Produkt mit mehreren parallel laufenden Versionen oder mit einer Modifizierung für einen bestimmten Kunden arbeitet, benötigt man die Verzweigung nach Release. So kann sich das Team auf spezifische Probleme je nach Patch oder Release konzentrieren.

Nachteile der Release-Verzweigung (und was man dagegen tun kann)

Die Arbeit mit vielen Release-Branches kann die Pflege erschweren. Bei vielen Änderungen und Mitwirkenden kann die Code-Basis schnell instabil werden.

Diese Art der Verzweigung kann potenziell auch zu mehr Arbeit für die Teams führen. Wenn mehrere Releases erhalten werden müssen, müssen die Änderungen in mehrere Versionen eingefügt werden. Beispielsweise unterstützt du Version 1.0, 2.0, 3.0. usw.

Wenn du mehrere parallele Versionen und Anpassungen deiner Software verwaltest, ist es entscheidend, dass ein Prozess eingerichtet wurde. Er sollte sicherstellen, dass Bugfixes in die relevanten Zweige übertragen, zusammengeführt und getestet werden, um Regressionen zu vermeiden. 

Merging für Anfänger

Egal, ob du die Verzweigung nach Aufgabe/Feature, Verzweigung nach Release oder eine Kombination beider Verzweigungsstrategien einsetzt, am Ende des Branchs führst du zusammen.

Je nach VCS variiert dein Workflow. Sowohl bei zentralisierten als auch bei verteilten Systemen führst du im Allgemeinen alles auf einem Server zusammen. Eine Single Source of Truth verhilft deinen DevOps-Teams zu einem einfacheren Build-Prozess. Sie können alles, was sie für einen Build benötigen, von einem zentralen Speicherort abrufen.

Und damit du die „Merging-Hölle“ vermeidest, haben wir ein paar Tipps für besseres Verzweigen für dich.

Bewährte Verfahren zum Verzweigen für alle Verzweigungsstrategien

Deine Verzweigungsstrategie für ein Projekt kennen und verstehen

Wenn du dich für eine Verzweigungsstrategie entscheidest, musst du sie dokumentieren und deinem Team mitteilen. Du solltest Folgendes skizzieren:

• Wann sollte ein Entwickler verzweigen? Von wo?
• Wann sollte ein Entwickler zusammenführen (und wie oft)? Wohin?

Es ist entscheidend, diesen Workflow teamübergreifend zu definieren. Dies geschieht im Allgemeinen durch Dokumentation oder Verzeichnisstrukturen oder auf einem Whiteboard. Frage während des Entwicklungszyklus bei deinen Teams nach, um sicherzustellen, dass alle die gleichen Informationen haben.

Minimieren der Auscheck-Zeit des Quellcodes

Wir sagen es nochmal für die Entwickler in der letzten Reihe! Manche Teams haben viele Branches und andere nur wenige. Aber egal, wie viele es sind, wenn man die Zeit begrenzt, in der Quellcode ausgecheckt wird, hilft das, Merging-Konflikte zu verhindern.

Die Entwickler sollten Quellcode regelmäßig hinauskopieren, um sicherzustellen, dass sie die aktuellsten Dateien haben. Je länger etwas ausgecheckt ist, desto isolierter kann dieser Quellcode werden.

Die Abhängigkeiten erkennen

Wenn du an einem Hotfix oder sogar an einem Feature arbeitest, musst du wissen, welche Versionen oder Teams von dieser Arbeit betroffen sind. Vor dem Verzweigen ist es wichtig, darüber nachzudenken, wie die Änderungen übertragen werden müssen und wo Quellcode integriert werden muss.

Überprüfen des Merge-/Integrationsprozesses

Nehmen wir an, ein Entwickler führt mehrere Änderungen an einem Branch durch. Nach dem Mergen funktioniert der Build nicht mehr. Der Entwickler repariert ihn. Und dann, kurz vor dem Release, wird der Quellcode teamübergreifend integriert. Und KAWUMM ist alles kaputt.

Aber welche Änderung hat das Problem verursacht?

Je mehr Quellcode du überprüfen musst, desto länger dauert der Merge bzw. die Integration. Häufiges Zusammenführen verringert die Gefahr, dass etwas kaputtgeht. Wenn die Mitwirkenden den Quellcode früher integrieren oder ihn teamübergreifend bei jeweils nur einem Team integrieren, können sie Probleme schnell erkennen.

Das richtige System zur Versionskontrolle

Bei der Auswahl des VCS-Systems ist das Verzweigen nur ein Aspekt. Das System sollte eine Reihe von Dateien, Mitwirkenden und Anforderungen an Builds unterstützen. Außerdem brauchst du Leistung, damit es funktioniert.

Und obwohl das Verzweigen wahrscheinlich nie völlig stressfrei sein wird, muss es mit dem richtigen VCS keine großen Kopfschmerzen verursachen. Mit Helix Core – der Versionskontrolle von Perforce – bekommst du Perforce Streams. Diese Verzweigungsmethode zeigt die Beziehungen zwischen den Branches an und verfügt über integrierte bewährte Verfahren zum Verzweigen. Es bietet großen Teams eine bessere Möglichkeit zum Verzweigen und Zusammenführen.

Höhere Geschwindigkeit mit Perforce Streams

Streams macht Entwicklern das Leben leichter. Es hilft ihnen, mehr zu programmieren, statt sich mit allgemeinen Arbeiten zu beschäftigen. Und die Admins brauchen keine Zeit damit zu verbringen, Workflows und komplizierte Scripts zu implementieren und wütende E-Mails zu verschicken.

Streams verfügt über die integrierte Struktur zum Unterstützen komplexer Verzweigungen für Entwicklung und Releases (egal, für welche Strategie du dich entscheidest). Und darüber hinaus ist diese Grundlage so flexibel, dass du sie an die Arbeitsweise deines Teams anpassen kannst.

So funktioniert Perforce Streams

Wenn ein Entwickler einen Branch erstellt, richtet Streams den zugehörigen Workspace automatisch ein. Das Programm weiß, welche Dateien zur Verfügung stehen, und die Entwickler können sehen, an welchen gearbeitet wird (und von wem).

Streams erstellt und zeigt den Ablauf der Änderungen zwischen den Branches.

Die Verzweigungsstrategie von Streams für mehrere Releases

Dein Team braucht sich nicht mehr auf Benennungskonventionen zu verlassen, um die Beziehung der Branches zueinander zu erkennen. Und du kannst darauf verzichten, Verzweigungsstrategien auf einem Whiteboard zu dokumentieren! Denn mit Streams weißt du immer, wohin dein Quellcode gehört.

Mit dem Stream Graph können die Entwickler visualisieren, wie der Quellcode übertragen wird. Sie können schnell überprüfen, ob sie die neueste Version der Mainline oder des Integration Branch besitzen. Wenn Updates zur Verfügung stehen, kann neuer Quellcode nach unten zusammengeführt werden. Dann können Änderungen nach oben kopiert werden. Das hilft, die Branches stabil zu halten.

So einfach geht das.

Beseitige Komplikationen, verzweige mit Streams. Es erledigt die Arbeit für dich. Sieh es dir selbst an.