SDLC mit GitLab gestalten: Best Practices für CI, Merges und Automatisierung

Dieser Beitrag ist Teil II der Blogreihe SDLC 2026. Hier geht es zu Teil I.

Im ersten Teil dieser Blogreihe haben wir gesehen, wie sich rund um den Merge Request ein SDLC aufbauen lässt, der Compliance-Anforderungen effizient erfüllt. Auf dieser Basis folgen hier nun weitere Empfehlungen für die Gestaltung eines SDLC, der auch flexibel die individuellen Anforderungen des Teams und des Unternehmens erfüllt.

Continuous Integration

Während der Feature Branch sicherstellt, dass Änderungen erst nach Fertigstellung und Freigabe gemergt werden können, bildet er auch ein Risiko: Parallel ablaufende Entwicklungen können zu Konflikten führen. Daher ist es wichtig, die Prinzipien von Continuous Integration auch hier anzuwenden. 

• Kurzlebige Feature Branches, die ein kleines Feature repräsentieren und nicht ein ganzes Projekt. Idealerweise enthalten diese nicht mehr als die Arbeit eines Tages.
• Integration von Änderungen aus dem Hauptentwicklungsstrang in den Feature Branch. Durch Merge in den Feature Branch oder Rebase dafür sorgen, dass Konflikte regelmäßig in kleinen Schritten aufgelöst oder verhindert werden. So läuft die Entwicklung gar nicht erst weit auseinander.
• Neben „echten“ Konflikten, wo die gleiche Code-Stelle geändert wurde, kann es auch „abhängige“ Konflikte geben: Beispielsweise wurde in einem Branch eine Funktion entfernt, während ein anderer Branch einen neuen Aufruf dieser Funktion einführt. Aus Git-Sicht gibt es keinen Konflikt, aus Compiler-Sicht schon.

Bewusste Historie durch die richtige Art des Merges

Bei der Nutzung vieler Branches kann die Git-Historie schnell unübersichtlich werden. Hier hilft es, sich bewusst für bestimmte Arten von Merges zu entscheiden.

• Squash oder kein Squash: Beim Squash werden alle Commits des Feature Branches zu einem einzigen Commit auf dem Main zusammengefasst. Damit erzeugt man im Main eine Historie, wo es für jedes Feature genau einen Commit gibt. Die Historie ist damit sehr übersichtlich. Es kann aber auch dazu führen, dass die Commits sehr groß sind (abhängig von der Größe der Änderungen im Branch). Wenn im Branch viel ausprobiert, ergänzt oder nachträglich gefixt wurde, dann empfiehlt sich ein Squash. Wenn die Historie im Branch schon aus logischen, aufeinander aufbauenden Schritten besteht, dann sollte man ohne Squash mergen und diese Historie erhalten.
• Fast-forward oder Merge Commit: Mit Fast-forward-Merges entsteht garantiert eine lineare Historie ohne Abzweigungen, was für die spätere Nachvollziehbarkeit sehr gut ist. Damit diese möglich sind, muss der Feature Branch immer auf dem aktuellen Main basieren, was auch generell zu empfehlen ist (siehe Continuous Integration). Allerdings geht damit auch ein Stück weit die Information verloren, welche Änderung aus welchem Branch kam. Bei der anderen Variante entsteht immer ein Merge Commit. Dieser markiert explizit die Zusammenführung von zwei Branches und kann über die Nutzung von Templates  auch weitere Informationen enthalten, z.B. wer den Merge Request genehmigt hat. So wird diese Information in der Git-Historie selbst festgeschrieben.

Hier gibt es kein pauschales „Besser“ oder „Schlechter“. Man muss sich bewusst sein, was man erreichen will und welches Vorgehen zur eigenen Arbeitsweise passt. Damit kann man sich die richtigen Einstellungen suchen und auch als Default in GitLab hinterlegen oder sogar erzwingen.

Zusammenarbeit statt Gegeneinander

Ich erlebe oft, dass Compliance- oder Security-Teams von Entwicklungsteams als „Hindernis“ oder gar „Gegner“ wahrgenommen werden. Wenn man den SDLC neu gestaltet, sollte man diese aber bewusst ins Boot holen und Anforderungen sowie Lösungen gemeinsam besprechen. Meist ist dies unkomplizierter und erfolgreicher als gedacht – vor allem, wenn man auf einer guten Tool-Unterstützung aufbaut. Die Teams bestimmen die Regeln und Prozesse ja nicht aus Langeweile, sondern um gesetzlichen Anforderungen, Kundenanforderungen etc. gerecht zu werden. Wichtig ist dabei, sich das Ziel vor Augen zu halten („Was wollen wir erreichen?“) und nicht die bisherige Lösung.

Policies

Mit Policies können Dinge in GitLab zentral erzwungen werden, z. B. die Ausführung von Security Scans in allen Pipelines oder die Konfiguration von Approval-Regeln. Während „Zwang“ für viele erstmal abschreckend klingt, kann es auch eine große Entlastung sein. Die Entwicklungsteams müssen sich keine Gedanken um die korrekte Konfiguration und Dokumentation machen, sich nicht mit Prozessen herumschlagen usw. Sie können sich einfach darauf verlassen, dass gewisse Compliance-Aspekte zentral konfiguriert sind und sie damit konform arbeiten.

Für Compliance Teams bedeutet das einen Kontrollgewinn und gleichzeitig weniger individuelle Überprüfungen und Diskussionen bei unterschiedlichen Teams.

Automatisierung nutzen

Die Build Pipeline sollte möglichst den ganzen Prozess automatisieren, vom Bauen über das Testen, Paketieren und Ausrollen der Anwendung. Auch wenn dabei Informationen in externen Systemen gepflegt werden müssen, kann dies meist über API-Aufrufe oder andere Integrationen gelöst werden. Die Vorteile liegen auf der Hand:

• Geschwindigkeitsvorteil im Vergleich zur manuellen Ausführung
• Reproduzierbare Ergebnisse
• Nachvollziehbarkeit in Logs
• Geringere Fehleranfälligkeit

GitLab bietet hier als Plattform sehr viele Möglichkeiten, um Dinge direkt integriert umzusetzen und dadurch weniger andere Tools anbinden zu müssen. Beispiele sind die Package- und Container Registry, Workitems oder der GitLab Agent for k8s. Das ist auch für Entwicklungsteams vorteilhaft, da es weniger Kontextwechsel bedeutet. Gleichzeitig werden Compliance-Risiken minimiert, da weniger Schnittstellen und separate Konfigurationen gewartet und geprüft werden müssen.

Diese Empfehlungen sollen helfen, dass der Entwicklungsprozess nicht nur Compliance sicherstellt, sondern auch die Anforderungen des Teams selbst berücksichtigt und dafür an den entsprechenden Stellen individuell abgestimmt wird.

Fazit

Der SDLC sollte nicht starr sein, sondern ist ein anpassbares Regelwerk, das die Anforderungen von Compliance und Entwicklungsteams erfüllen muss. Es geht um die Erreichung von Zielen, nicht um das stumpfe Abarbeiten oder Übertragen von Regeln und alten Prozessen. Außerdem sollten grundlegende Prinzipien wie Continuous Integration und Automatisierung direkt im Prozess verankert werden.

Wichtig ist dabei die Zusammenarbeit mit verschiedenen Bereichen des Unternehmens, um von Anfang an gemeinsam einen passenden Prozess zu definieren, anstatt sich im Nachhinein zu streiten.