SDLC mit GitLab: Grundlagen für klassische Prozesse

In meinem Arbeitsalltag prallen gerade zwei völlig unterschiedliche Welten aufeinander. Auf der einen Seite stehen etablierte Unternehmen, die ihren SDLC mit GitLab modernisieren und absichern wollen. Oft sind sie reguliert und Compliance spielt eine große Rolle.

Auf der anderen Seite steht das Thema KI-gestützte Softwareentwicklung, wo sich der ganze SDLC im Extremfall komplett auflöst. Agenten übernehmen den kompletten Entwicklungsprozess, von der Anforderungsspezifikation über die Umsetzung und das Testing bis hin zum Review. Die Entwicklungszyklen werden dadurch extrem kurz. Das Ergebnis: Beliebige Produkte lassen sich in rasantem Tempo entwickeln und testen.

Irgendwo dazwischen steht das AI-Paradoxon, das Schreiben von Code geht rasend schnell und es wird sehr viel Code produziert. Trotzdem wird die Entwicklung und Auslieferung von Features nicht schneller, der Review-Prozess wird zum Nadelöhr und Prozesse werden nicht angepasst.

Im Rahmen dieser Serie werde ich einen Blick in die Zukunft werfen und beleuchten, wie der Softwareentwicklungsprozess im Jahr 2026 aussieht, insbesondere für die Anforderungen regulierter Unternehmen und umgesetzt mit GitLab.

Der klassische SDLC mit GitLab im Überblick

Im ersten Teil dieser Blogreihe schauen wir uns an, wie ein moderner SDLC mit GitLab ohne KI aussieht und welche Features uns helfen können, die Compliance-Anforderungen umzusetzen.

Die Funktionen sind nicht neu und für manche Unternehmen vielleicht „ganz normal“. Andere entwickeln und betreiben seit vielen Jahren Software, die die Grundlage ihres Geschäfts bildet und bei der die Prozesse noch nicht angepasst wurden. Genau diese Anwendungen müssen jetzt oft auf moderne Tools und Prozesse umgezogen werden.

Aktuell nutzen sie vielleicht noch SVN oder Harvest für die Versionierung, vielleicht aber auch schon Git in Kombination mit Reviews in Gerrit oder Builds mit Jenkins. Kurz gesagt: Die Tool-Landschaft ist historisch gewachsen und fragmentiert. Jetzt stehen viele vor der Herausforderung, den gesamten Prozess dringend Compliance-gerecht zu gestalten.

Anforderungen und Issues im Entwicklungsprozess

Der Entwicklungsprozess beginnt oft mit Anforderungen, egal ob für neue Features oder Bugfixes. Diese lassen sich in GitLab mittels Issues abbilden und es gibt den kompletten Rahmen drumherum: Epics, Tasks, Roadmaps, Milestones usw. In der Praxis setzen Kunden oft Jira für diese Phase ein. GitLab hat in den letzten Monaten intensiv auch für die Planning Phase neue Features geliefert. Dennoch – und das ist verständlich – beobachten wir schrittweise Migrationen, beginnend mit Gitlab für Code, CI und Security. Die Planning Features werden dabei optional in der Zukunft gesehen und bleiben daher in diesem Artikel erst einmal außen vor.

Die Abbildung von Anforderungen ist aber auch aus Compliance-Sicht sehr wichtig. Tatsächlich muss oft nachgewiesen werden, dass es überhaupt eine Anforderung gab, bevor Änderungen ausgerollt werden können.

Feature Branches

GitLab basiert – wie der Name schon sagt – auf dem Versionsverwaltungssystem Git. Git unterstützt nicht nur bei der Historisierung und Nachverfolgung von Änderungen, sondern ist auch sehr stark im Branching. Für die isolierte Umsetzung von Änderungen bietet sich ein Feature-Branch-Workflow an: Jedes Feature wird in einem separaten Branch umgesetzt. Erst wenn es fertig ist, wird es in den Hauptentwicklungszweig (main) zurück gemerged.

Einfacher Feature Branch Workflow: die Entwicklung des Features findet erstmal separat statt und wird später explizit in den Main Branch gemergt.

Mit Runnern integriert GitLab die Funktion eines Buildservers in Form von CI/CD-Pipelines. Diese können verschiedene Jobs enthalten und so den Code kompilieren, analysieren, testen und ausrollen oder externe Tools einbinden. Die Ergebnisse in Form von Build-Artefakten, Container Images, Test-Reports, SBOMs und Vulnerability Reports können dann direkt in GitLab gespeichert und verwaltet werden.

An der Stelle ist für uns wichtig, dass Tests und Code-Analysen schon in einer Pipeline für den Branch laufen können und die Ergebnisse vor der Integration in den Main Branch bereitstehen. So können diese direkt ausgewertet werden und Fehler bzw. Schwachstellen kommen gar nicht erst im Main Branch an.

Der Merge Request als zentrales Compliance-Artefakt

Erst danach erfolgt die Zusammenführung mit dem Hauptentwicklungsstrang. Genau an diesem Punkt setzt ein Feature an, welches in GitLab die Grundlage für viele Compliance-relevante Funktionen bildet: der Merge Request. Wie der Name schon sagt, ist der Merge Request die „Anfrage“, etwas „zusammenzuführen“, also einen Git-Merge durchzuführen. Mit dem Merge Request steht uns ein zentrales Artefakt zur Verfügung, auf dem wir die weiteren Compliance- und Qualitätssicherungsprozesse aufbauen können.

In vielen Unternehmen gilt für alle Änderungen ein Vier-Augen-Prinzip: Niemand kann alleine Code ändern und auf die Produktionsumgebung bringen. Alle Änderungen müssen immer von mindestens einer zweiten Person freigegeben werden. Diese Anforderung besteht oft aus Compliance-Sicht und taucht in der Regulatorik unter anderem in der ISO 27001, im SOC2-Standard und den Anforderungen der BAIT/VAIT auf.

Für die Umsetzung gibt es bei Merge Requests „Approvals“, also Freigaben. Es lässt sich sehr detailliert konfigurieren, wie viele Freigaben es geben muss, wer freigeben kann und was passiert, wenn nach der Freigabe noch Dinge geändert werden.

Approval Rule: es kann genau festgelegt werden, wer einen Merge Request freigeben muss.

Approval Settings: außerdem können weitere Details zu Freigaben festgelegt werden. Beispielsweise, dass jede neue Änderung alle vorhandenen Freigaben zurücksetzt.

Merge Checks: Neben Freigaben können auch weitere Bedingungen geprüft werden, bevor der Merge Request gemerged werden kann.

Im Merge Request sehen sowohl die umsetzenden als auch die freigebenden Personen alle relevanten Informationen:

• Titel und Beschreibung des Merge Requests (wenn vorhanden mit Referenzen auf Anforderungen/Issues)
• Quell- und Ziel-Branch
• alle Commits auf dem Quell-Branch
• das Diff zwischen beiden Branches
• Ergebnisse der Pipeline im Branch (Status, Tests, Coverage, Schwachstellen)
• wer muss freigeben, wer hat freigegeben
• eine Änderungshistorie

Es muss nicht jeder einzelne Commit überprüft werden, sondern das gesamte Diff zwischen Quell- und Ziel-Branch wird dargestellt (wobei natürlich auch die einzelnen Commits geprüft werden können, wenn gewünscht). Damit hat man die Grundlage für eine Begutachtung der Änderungen. Dies umfasst natürlich das Code-Review, bei der das Diff nicht nur geprüft werden kann. Man kann zeilenweise Kommentare hinzufügen, Änderungen vorschlagen und so in verschiedenen Threads diskutieren. Aber auch eine Referenz auf die Anforderungen ist gegeben, Testergebnisse sind direkt sichtbar und Änderungen an der Code Coverage werden angezeigt. So ergibt sich ein umfassendes Bild von den Änderungen und ihren Auswirkungen. Der Merge Request dient somit als zentrales Compliance-Artefakt, der die notwendigen Informationen bündelt und unveränderbar dokumentiert.

An dieser Stelle sind wir aber noch nicht am Ende unserer Reise zum Merge des neuen Features angekommen, es gibt noch weitere Möglichkeiten. Um nicht nur den Code zu bewerten, sondern auch die laufende Anwendung zu testen und zu erleben, bietet GitLab das Feature der „Review Environments“. Das heißt, ein Branch kann als eigene Umgebung deployt werden, dort können manuelle oder automatisierte Tests und Abnahmen stattfinden. Auch ein DAST Scan (Dynamic Application Security Testing) kann gegen diese Umgebung ausgeführt werden. Danach kann die Umgebung wieder abgeräumt werden. All das wird von GitLab verwaltet und ist integriert in Pipeline, Merge Request und andere Funktionen.

Die Erkenntnisse aus der laufenden Anwendung können ebenfalls für die Freigabe des Merge Requests herangezogen werden.

Der Merge Request zeigt auf der Übersicht an, welche Bedingungen für den Merge erfüllt sein müssen. Oben gibt es weitere Reiter, um sich beispielsweise alle Commits, Pipelines oder Unterschiede anzusehen.

Ein Vorteil von GitLab als integrierte Plattform ist, dass es nicht nur die Pipeline an sich enthält, sondern auch viele Security Scans selbst bereitstellt. So können statische Code-Analysen, Container Scanning, Dependency Scanning, Secret Detection und IaC Scanning direkt in die Pipeline eingebunden werden. Die Ergebnisse stehen natürlich auch im Merge Request zur Verfügung. Es lassen sich separate Approval-Regeln für gefundene Vulnerabilities und Lizenzen definieren. Das bringt alle betroffenen Teams an einen Tisch: Keine Toolbrüche mehr, maximale Transparenz und eine lückenlose Dokumentation an Ort und Stelle. Ganz egal, ob am Ende die Freigabe der Entwicklung, der QA, des Product Owners oder des Security- und Compliance-Teams benötigt wird.

Wenn über die Abhängigkeiten neue Lizenzen eingeführt werden, dann ist hier eine zusätzliche Freigabe vom Compliance Team erforderlich. Das Security Scanning hat keine Probleme gefunden, daher muss das Security Team nicht separat freigeben.

Wenn dann alle Prüfungen abgeschlossen und Freigaben erteilt sind, kann endlich der Merge erfolgen.

Weiterer Prozess im Lifecycle

Der Prozess endet hier natürlich noch nicht, denn es müssen z. B. noch Releases erstellt und auf verschiedene Stages ausgerollt werden. Diese Schritte lassen sich ebenfalls mit Pipelines automatisieren und auch mit weiteren Freigaben (z. B. für Deployments auf bestimmte Umgebungen) versehen.

Fazit und Ausblick

Regulierung betrifft immer mehr Unternehmen, während gleichzeitig immer mehr Prozesse in Unternehmen durch Software abgebildet werden. Der Bedarf an konformen Entwicklungsprozessen und unterstützenden Tools ist daher groß.

GitLab hat diesen Bedarf erkannt und Lösungen für die Anforderungen regulierter Unternehmen gefunden. Zentraler Ankerpunkt für den konformen SDLC ist dabei der Merge Request, der Informationen aus vielen Bereichen bündelt und die Freigaben verwaltet. Als Partner unterstützen wir Unternehmen regelmäßig dabei, genau solche konformen Prozesse mit GitLab zu konzipieren und in die Praxis umzusetzen.

Natürlich gibt es noch viele weitere Features im Compliance Umfeld, auf die ich hier nicht eingegangen bin, weil der Fokus auf dem Entwicklungsprozess selbst liegen sollte. Dies wären beispielsweise verschiedene Dashboards, Audit Logs, Berechtigungssysteme und die Verwaltung von Vulnerabilities. Das deutschsprachige GitLab Team bietet auch einen Blogbeitrag, der die Features aus der Compliance-Management-Sicht vorstellt.

Compliance muss dabei kein Hindernis für Geschwindigkeit sein, durch eine integrierte Plattform und einen hohen Grad an Automatisierung lässt sie sich nahtlos in den SDLC integrieren. Damit erreicht man definierte Prozesse, explizite Freigaben und die Einbindung von Security ohne langwierige manuelle Schritte.

Neue Herausforderungen gibt es durch die große Menge an Code und Änderungen, die durch KI-Lösungen verfügbar werden. Im Laufe dieser Serie werden wir natürlich auch diese betrachten und mit der Regulatorik in Beziehung setzen.