Die unterschiedlichen Varianten des Branching und Merging

Im letzten Teil unseres Blogbeitrages gingen wir auf die Grundlagen des Branching und Merging in einem modernen Application Lifecycle Managements ein. In diesem Blogbeitrag widmen wir uns den unterschiedlichen Varianten mit ihren Vor- und Nachteilen.

Nach einer abgeschlossenen Analyse-Phase sind in vielen Software-Projekten zu Beginn an natürlich-sprachige Requirements vorhanden, die Features nicht nur vollständig, sondern auch atomar, eindeutig und konsistent beschreiben. Diese unterschiedlichen Features gilt es dann von unterschiedlichen Teams entwickeln zu lassen. Sind die Features klar voneinander getrennt, lässt sich ein sogenannter „Feature-Branch-Plan“ entwickeln.

Die Idee hinter diesem Konzept ist die Isolierung eines jeden einzelnen Features in seinem eigenen Branch. Features werden in die Mainline integriert, sobald diese stabil genug für einen Release sind.

Über Forward Integration werden zuerst Teile aus der Mainline in den Feature-Branch integriert. Im Anschluss daran wird der Feature-Branch stabilisiert, etwaige Konflikte aufgelöst und über Reverse Integration in die Mainline zurück gespielt. Der Vorteil dieser Vorgehensweise liegt eindeutig auf der Hand. Während in der Mainline nur noch geringfügige Änderungen durchgeführt werden müssen, lassen sich im Feature-Branch die neuen Funktionalitäten testen und bei schweren Ausnahmefehlern einfach wieder zurück spielen.

Folgende Arbeitsschritte wiederholen sich dabei regelmäßig:

1. Arbeitskopie erstellen (Mainline)
2. Forward Integration (Mainline to Branch)
3. Review der Änderungen
4. Änderungen testen
5. Fehler beseitigen
6. Reverse Integration (Branch to Mainline)

Falls Sie nun mit dem Gedanken spielen, selbst mit einem Feature-Branch-Plan zu arbeiten, so gibt es trotz der unzähligen Vorteile natürlich auch ein paar wenige Nachteile. Je größer die zeitliche Diskrepanz zwischen Mainline und dem Feature-Branch ist, umso mehr erhöht sich die Komplexität und das Auftreten von potentiellen Konflikten.

Dieses Problem lässt sich aber auf eine elegante Art und Weise lösen. Ein Feature-Branch muss nicht immer vollständig sein um Änderungen aus der Mainline entgegen zu nehmen. Daher ist es wichtig so oft wie möglich Änderungen aus der Mainline über Forward Integration in den Feature-Branch zurück zu spielen. Dies reduziert auf Dauer die Komplexität und führt zu einer frühen Harmonisierung zwischen Mainline und den unterschiedlichen Feature-Branches.

Im nächsten Blogbeitrag widmen wir uns den Vor- und Nachteilen eines Single-Branches.

Wir freuen uns, wenn Sie beim nächsten Mal wieder dabei sind.

Bleiben Sie gespannt!

Quellen:

Manfred Broy, Marco Kuhrman: Projektorganisation und Management im Software Engineering, Springer-Verlag, 2013

Richard Hundhausen: Professional Scrum Development with Microsoft® Visual Studio® 2012 – See more at: http://blog.hood-group.com/blog/2014/04/22/anforderungen-im-alm/#sthash.2xWfr95r.dpuf

Donig, Jens: Perfekte Softwareentwicklung – Prozesse, Technologien und Methoden für erfolgreiche Softwareprojekte – Application Lifecycle Management (ALM), Symposion Publishing, Hrsg. Lang, Scherber; Düsseldorf 2013 – See more at: http://blog.hood-group.com/blog/2014/05/13/aenderungsmanagement-prinzipien-im-application-lifecyle-management/#sthash.O0Unyswa.dpuf

Marco Prillwitz

Kontaktieren Sie Marco Prillwitz

Zuhören - was der Kunde braucht. Hinterfragen - was er tatsächlich benötigt. Marco Prillwitz ist ohne jeglichen Zweifel Missionar im Bereich des Requirements Engineerings und als Consultant, Trainer und Coach bei HOOD tätig. Neben seiner langjährigen Erfahrung im Requirements Management und der Systementwicklung liegt seine Stärke in der Modellierung von Geschäfts- und Systemprozessen. Themen aus dem agilen Umfeld finden das besondere Interesse des Professional Scrum Masters. Seine Leidenschaft besteht darin, Impediments frühzeitig zu erkennen, gekonnt mit den Team entgegen zu steuern und das Potenzial aus Mensch und Organisation höchstmöglich zu entfalten.