Raus aus dem Teufelskreis Über kurze Release-Zyklen hin zum Trunk-based Development

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Turbine Kreuzberg GmbH

Wer seine Entwicklungszyklen zu lang werden lässt, riskiert einen Teufelskreis, aus dem nur schwer wieder zu entkommen ist. Kurze Entwicklungszyklen lassen einen nicht nur deutlich flexibler auf Fehler reagieren, sondern fördern auch die Developer.

Eine Zeitung erscheint (meist) einmal am Tag. Das ist eine ganz schön lange Zeit, in der eine Nachricht Gültigkeit behält – gerade in unserer digitalen, schnelllebigen Welt. Journalisten und Journalistinnen arbeiten meist unter Hochdruck an ihren Texten. Die Redaktionsleitung achtet akribisch darauf, dass keine Schreib- oder anderweitige Fehler abgedruckt werden.

Trotz Redigier-Tools und dem finalen Blick des Chefs vom Dienst schleichen sich dennoch immer wieder kleine Fehler in den Druck. Manchmal wird sogar eine Richtigstellung in der nächsten Ausgabe notwendig. Ganz anders bei Online-Artikeln: Sind sie fertig, können sie erscheinen. Fehler lassen sich schnell ausbessern. So ähnlich ist es mit langen und kurzen Entwicklungszyklen beim Programmieren.

Längere Zyklen erfordern ein hohes Maß an Genauigkeit. Werden nämlich Fehler auf dem Produktivsystem ausgerollt (Deployment), können diese erst mit dem nächsten Zyklus ausgebessert werden. Das führt dazu, dass Entwicklerinnen und Entwickler sowie Product Owner – ähnlich wie im Journalismus Tätige – unter hohem Druck stehen, fehlerlos zu arbeiten.

Die gängige Reaktion darauf: Sie führen zusätzliche Prozesse ein, die sicherstellen sollen, dass kein Fehler passiert. Dadurch verlängert sich der Vorgang natürlich nur noch weiter. Ein Teufelskreis, der sich nur durch möglichst kurze Entwicklungszyklen durchbrechen lässt.

Wie erreiche ich kürzere Zyklen?

Als Entwickler strebt man danach, dass der Code, den man lokal entwickelt hat, anschließend direkt durch den Continuous-Integration-, kurz (CI-Prozess läuft und – wenn die CI-Pipeline erfolgreich ohne Fehler durchgelaufen ist – ohne einen manuellen Zwischenschritt sofort auf dem Produktivsystem ausgerollt wird (Continuous Deployment, CD). Continuous Integration bedeutet eine ständige Integration des Codes in den Haupt-Branch der Entwicklung (üblicherweise „main“ oder „master“ genannt). Die Kür ist es, dass das Vertrauen in die Prozesse (Pipeline, QA & Testing) so hoch ist, dass man – wenn möglich – sogar mehrfach am Tag auf das Produktivsystem deployen kann.

Um das zu erreichen, sollten die Tasks in möglichst kleine, überschaubare und schnell zu entwickelnde Teilstücke aufgeteilt werden. So können Änderungen schneller durch die CI-Pipeline laufen und - theoretisch - jederzeit auf dem Produktivsystem deployed werden. Auch die Pipelines mit ihren Test- und Build-Schritten sollten so effizient wie möglich gestaltet sein und schnell durchlaufen werden können.

Dies dient dazu, ein hohes Vertrauen in den Workflow zu erzeugen und die manuellen Abnahmeprozesse dahinter so reduziert wie möglich zu halten, beziehungsweise idealerweise komplett obsolet zu machen. Dadurch erreicht man auch im Fall von auftretenden Problemen wie Bugs oder notwendigen Anpassungen durch nicht vorhergesehene geänderte Anforderungen schnelle Reaktionszeiten, um auf Entwicklungsseite flexibel reagieren zu können.

In der Realität sieht das leider oft anders aus. Vorgesetzte oder Beauftragende bspw. wollen vor dem Deployment auf das Produktivsystem (manuell) das Release überprüfen. Dazu muss man eine Staging-Umgebung bauen, in der unter möglichst realen Bedingungen die Änderungen getestet werden können. Das wiederum kostet natürlich auch Zeit.

In vielen Projekten ist es daher so, dass mehrere Änderungen erst einmal angesammelt werden – üblicherweise bis zum Ende eines Sprints, wenn z.B. ein bestimmtes Feature vollständig umgesetzt ist. Auf das Produktivsystem wird erst nach der Abnahme und Freigabe durch die beauftragenden Stakeholder. Ein Sprint dauert meist zwei Wochen, das heißt, es wird maximal alle zwei Wochen deployed.

Haben Projekte hingegen lange Entwicklungszyklen, in denen sehr komplexe Prozesse oder Features umgesetzt wurden, können im schlimmsten Fall mehrere Monate vergehen, bis wieder auf dem Produktivsystem deployed wird. Riesige Feature-Branches mit mehreren Hundert oder Tausend Zeilen geändertem Code sind extrem schwierig zurückzuspielen (mergen). Auch Merge-Konflikte sind da vorprogrammiert.

Länger dauernde Feature-Arbeiten, die einen entsprechenden Branch aufmachen, lassen sich natürlich nicht immer vermeiden. Um jedoch später keine Probleme zu bekommen, sollte man sich periodisch die zwischenzeitlichen Änderungen vom Hauptbranch ziehen, um auf dem aktuellen Stand zu bleiben. Das hilft, da eventuelle Konflikte gleich aufgelöst werden können und nicht erst am Ende geballt auftreten.

Next step: Trunk-based Development

Und der Trend geht sogar noch einen Schritt weiter. Das Ziel von Trunk-based Development ist es, keine Zyklen mehr zu haben: Die Mitglieder des Entwicklungsteams committen mehrmals am Tag direkt in den Haupt-Branch. Das Erstellen von separaten (Feature-)Branches soll die Ausnahme bleiben. Darüber hinaus wird zu zweit (Pairing) oder sogar in der Gruppe (Mobbing) programmiert.

Idealerweise geschieht das testgetrieben (Test-driven development). Das bedeutet, es werden vor dem eigentlichen Code erst die entsprechenden Tests geschrieben, die die zu implementierende Änderung überprüfen. Vor jedem Commit wird überprüft, ob alle – zumindest schnell durchführbaren – Tests erfolgreich sind. Zusätzlich überprüfen automatisierte Tools, ob alle Tests für den Master Branch erfolgreich sind.

Die Vorteile von Trunk-based Development sind nicht von der Hand zu weisen. Das direkte Arbeiten am Hauptbranch vereinfacht den Workflow für die Teammitglieder. Mögliche Konflikte werden schneller sichtbar. Durch die Übertragung der Verantwortung auf das ganze Team und dem gemeinsamen Entwickeln zu zweit oder in der Gruppe steigt die Chance auf einen besseren Teamzusammenhalt und höheren Knowledge-Transfer.

Natürlich ist Trunk-based Development nicht in jedem Projekt umsetzbar. Andererseits ist die Methode ein weiterer Schritt Richtung kleinerer und schnellerer Zyklen. Denn wie man in der Zeitung trotz all der Vorkehrungen immer mal wieder einen Fehler entdeckt, werden sich auch auf Produktivsystemen immer Fehler einschleichen.

Ein testgetriebener Entwicklungsprozess mit kleinen Inkrementen und ein schneller, verlässlicher CI-Prozess helfen im Zweifelsfall, schnell reagieren zu können. Und so entkommt man dem Teufelskreis langsamer Deployment-Zyklen.

* Bernd Alter ist Co-CTO bei Turbine Kreuzberg.

(ID:49543632)