Wer ein Source Control Management benutzt wird früher oder später an dem Punkt eines Releases kommen. Spätestens ab diesem Zeitpunkt muss man sich Gedanken machen, wie man den Quellcode nun am besten verwaltet. Branching & Merging sind hier in dem Blogpost die Schlagwörter um die es gehen soll.
Grundbegriffserklärung: Branching?
Ein Branch (dt. Zweig) ist eine quasi eine Kopie des IST Zustandes des Source Codes. So kann man z.B. 2 unterschiedliche "Entwicklungszweige” haben um verschiedene Sachen zu entwickeln - völlig voneinander losgelöst.
Merging?
Merging ist genau die Umkehroperation des branchings. Wenn man aus einem Hauptzweig einen "Entwicklerzweig” abgespaltet hat, möchte man diesen auch irgendwann wieder in den Hauptzweig zurückführen. Diesen Vorgang nennt man mergen.
Toolunterstützung
Ich werde in diesem Blogpost nur die Theorie erklären, allerdings sind beide Vorgänge in mir jedem bekannten Source Control Management System irgendwie mit dabei. Das System kennt also die Verzweigungen. Dies ist wichtig damit das System beim Merging wieder unterstützt.
Ein guten Guide (besonders im Zusammenhang mit dem TFS) zum Thema Branching & Merging befindet sich auf Codeplex.
Branching Strategien: "Basic Branching”
Das ist die simpelste Herangehensweise. Der Main-Pfad repräsentiert unser Hauptentwicklungszweig. Hierbei muss sichergestellt werden, dass man möglichst immer den Main-Zweig "stabil” lässt, sodass man theoretisch jederzeit ein neues Release rausgeben kann. Entwicklungsarbeiten würden nur im Development-Zweig gemacht. Am Ende einer Entwicklungsphase würde der Entwicklungszweig wieder in den Mainzweig "gemerged” und von dort aus wieder ein neuer Branch für einen neuen Release gezogen.
Was erreichen wir dadurch?
Man kann jedes Release nachvollziehen und die Entwicklung beeinträchtigt nicht den Mainzweig - was bei einem Hotfix z.B. wichtig wäre.
"Standard Branch Plan”
Dieses Vorgehensmodell könnte schon bei weniger komplexen Projekten ausreichen. Ziel ist es immer den Main Zweig absolut stabil zu halten.
Im Alltag wird man ein Entwicklungsprojekt X haben, welches nun z.B. in Version 1 released wurde. Nun gehen die Arbeiten für Version 1.5 im Entwicklungszweig gut voran, allerdings wurde ein Bug auf dem Live System gefunden. Direkt in dem Main Zweig den Bug zu finden und zu lösen kann Nebenwirkungen haben. Daher hat man noch einen "Service Pack” bzw. "Hotfix” Zweig. In diesem Zweig kann der Fehler gefunden werden und auch getestet werden. Wenn alles OK ist, kann man aus dem "Service Pack” bzw. "Hotfix” Zweig wieder nach Main mergen (also die Bugfixes nun auch im Main Zweig einchecken) und ein neues Release ausgeben.
"Advanced Branch Plan”
Hier wird noch zusätzlich ein direkter Hot Fix Zweig eingeführt. Dies kann man vielleicht ganz gut mit den Windows Service Packs und Hotfixes vergleichen. Kleinere Sachen werden in einem Hotfix Zweig gefixt. Der Hotfix wird dann weiter nach oben in den Service Pack Branch gemerged. Nachdem man einige Hotfixes gemacht hat kann man ein Service Pack rausgeben. In diversen Abständen sollten die Änderungen die im Service Pack Zweig sind natürlich auch wieder nach Main fliessen, damit man in der nächsten großen Version die alten Fehler nicht wieder drin hat.
Der Development Zweig - "Branch per Feature”
Diese drei Beispiele sind nur für die Produktivumgebungen wichtig gewesen. Für die Entwicklung kann man natürlich auch mehrere Entwicklungszweige anfangen. So kann man z.B. mehrere Entwicklungsteams getrennt voneinander arbeiten lassen oder man macht ein Branch für jedes Feature:
Jedes Entwicklungsteam kann für sich an einem Feature arbeiten. Nach einem gewissen Stand kann das Team auch für den Test einen eigenen Branch anlegen.
Egal wie komplex man es gestaltet. Der "Main” Zweig trennt die Entwicklung und das Produktivsystem. Man kann Änderungen die auf dem Produktivsystem gemacht wurden über den Hotfix -> Service Pack -> Main Zweig bis zu den diversen Development Branches durchreichen "Forward Integration” bzw. "Reverse Integration” sind hier die Stichwörter.
Wie kann das z.B. im Source Control aussehen:
Was vorher in den Bildchen schematisch erklärt wurde, kann im Explorer z.B. so aussehen. Dies ist in dem Fall der TFS Team Explorer. In der Version 2010 hat sich auch einiges in dem Gebiet getan. Als kleines Beispiel kann der TFS die Hierarchie sehr nett darstellen:
Weitere Ressourcen:
Alle Bilder stammen aus dem Visual Studio TFS 2010 Branching Guide - allerdings trifft die pure Theorie genauso z.B. auf SVN zu.
Ich versuche die verschiedenen Sachen in den nächsten Blogposts direkt mal mit einem TFS Projekt zu zeigen. Das Thema ist sehr groß und nicht mit einem Blogpost zu erschlagen. Hier ging es mir nur um die aller gröbsten Basics.
