SDLC mit GitLab: Trunk Based Development, Pair und Ensemble Programming compliant umsetzen

Im ersten Artikel dieser Serie haben wir gesehen, dass der Compliance-orientierte Workflow in GitLab stark auf der Nutzung von Feature-Branches beruht. Im zweiten Teil konnten wir diesen Ansatz zwar etwas individualisieren, aber der Kern bleibt gleich: Ein Branch pro Feature und die Nutzung von Merge Requests sind essenziell.

Alternativen wie das Trunk Based Development mit Feature Flags haben ihre eigenen Vorteile, werden in regulierten Umfeldern aber oft nicht akzeptiert.

Hier wollen wir uns noch einmal anschauen, wie das in der Praxis gelöst werden kann, damit ein moderner SDLC mit GitLab gelingt.

Trunk Based Development

Beim Trunk Based Development werden Änderungen direkt auf dem Hauptentwicklungsstrang („Trunk“, in Git oft „main“) vorgenommen. Die Änderungen aller Entwickler sind immer direkt integriert – vorausgesetzt, das Team committet häufig und sammelt Code nicht lokal. Somit kommt es gar nicht erst zu großen Konflikten und der gefürchtete Merge-Aufwand fällt gar nicht erst an.

Da alle Änderungen sofort in diesem Stand enthalten sind, lassen sie sich meist mit Feature-Flags abschalten.

Wie in der Einleitung bereits genannt, wird dieses Vorgehen meist aus Compliance-Gründen abgelehnt, weil technisch nicht sichergestellt werden kann, dass alle Änderungen von mehreren Personen gemeinsam durchgeführt oder geprüft wurden.

Kollaborative Entwicklung: Pair Programming

Pair Programming bedeutet, dass zwei Leute gemeinsam an einer Aufgabe arbeiten. Dabei gibt es zwei definierte Rollen: Driver und Navigator. Einer sagt, was getan wird, der andere führt aus und die Rollen rotieren regelmäßig. Dabei findet ein kontinuierliches Code Review statt.

Höchste Integration: Ensemble Programming

Auch Mob Programming oder Software Teaming: Ähnlich wie beim Pair Programming gibt es auch hier feste Rollen, aber die Anzahl der Personen ist größer als zwei und es wird reihum rotiert. In den meisten Fällen arbeitet das gesamte Team gemeinsam an einem Feature.

Da bereits mehrere Leute gemeinsam am Code arbeiten, ist das 4-Augen-Prinzip erfüllt und es könnte direkt trunk-based gearbeitet werden. Wie bereits geschrieben, fehlen aber der Nachweis und die Sicherstellung dafür. Es könnte auch eine Person alleine Änderungen vornehmen und committen. Das System weiß schließlich nicht, wie viele Leute gemeinsam vor dem Bildschirm sitzen.

Die Lösung: Konformer Workflow für agile Teams

Wenn man im Ensemble oder Pair arbeiten will, dann lässt sich das durchaus auch mit Feature Branches und Merge Requests abbilden. Das Pair bzw. Ensemble kann wie vorher beschrieben arbeiten und verschiedene Leute können committen, egal ob am eigenen Arbeitsplatz oder an einer gemeinsamen Station. Wichtig ist nur, dass sie nicht auf dem main arbeiten, sondern auf einem Feature Branch. Der Merge Request kann dann wie vorher beschrieben ganz normal erstellt werden. 

Zu beachten ist die korrekte Konfiguration der Approval-Regeln. Beim 4-Augen-Prinzip geht es darum, dass niemand allein Änderungen vornehmen kann. Beim Pair/Ensemble Programming ist das durch die Arbeitsweise bereits gegeben, es findet ein kontinuierliches Review statt. Dieses muss aber auch dokumentiert werden, dafür sind die Approvals nötig.

In vielen Standard-Konfigurationen dürfen Committer nicht approven, um zu verhindern, dass sie ihre eigenen Änderungen freigeben und so das 4-Augen-Prinzip umgehen. Für Pairs würde das bedeuten, dass noch eine dritte Person approven müsste, bei großen Ensembles vielleicht noch eine sechste oder siebte. 

Daher empfehle ich eine Konfiguration, bei der Committer explizit approven dürfen, aber zwingend mehrere Approvals gefordert sind. Für ein Pair bedeutet das: Beide Committer dürfen freigeben. Damit ist sauber dokumentiert, dass zwei Personen den Code geprüft haben. Ein Alleingang ist ausgeschlossen. Das gleiche Prinzip greift beim Ensemble, wo einfach zwei oder mehr Teilnehmende approven.

Dies ist eine elegante Lösung, die das kontinuierliche Review anerkennt, aber gleichzeitig die Compliance-Anforderung (4-Augen-Prinzip) erfüllt, ohne eine unnötige dritte Person hinzuziehen zu müssen.

Wichtig ist, dass jeder Commit alle Approvals zurücksetzen muss, sonst kann jemand nach dem Approval noch committen und so die Prüfung umgehen.

Wie im vorherigen Artikel beschrieben, sollten die Regeln für Freigaben mittels einer Merge Request Approval Policy konfiguriert werden. Damit wird die Konfiguration zentral verwaltet, was sicherstellt, dass sie korrekt ist und sich nicht jedes Team selbst um die Einrichtung kümmern muss.

Fazit: Ein sicherer und agiler SDLC mit GitLab

Dieser Ansatz zeigt, dass moderne, kollaborative Entwicklungsmethoden wie Pair und Ensemble Programming nicht im Widerspruch zu strengen Compliance-Anforderungen stehen müssen. Durch die intelligente Anpassung der Approval-Regeln im Merge Request lassen sich das kontinuierliche Review dokumentieren und das 4-Augen-Prinzip erfüllen. Damit haben wir die Grundlagen für einen SDLC mit GitLab geschaffen, der sowohl Compliance-sicher als auch flexibel für das Team ist. In den weiteren Teilen dieser Serie wenden wir uns der nächsten Herausforderung zu: Wie integrieren wir KI-Agenten in diesen regulierten Prozess?