GitLab CI/CD im Detail: Stages, Jobs, Pipelines für moderne Software

TL;DR

• GitLab CI/CD ist weit mehr als ein Build-Tool: Richtig eingesetzt wird es zum zentralen Rückgrat Ihres Delivery-Prozesses – von Commit bis Produktion, inklusive Dokumentation und Audit-Trail.
• Kernbausteine wie .gitlab-ci.yml, Stages, Jobs und Artifacts erlauben es, eine klare, reproduzierbare Lieferkette zu modellieren – inklusive Build (Kaniko, SBOM), Test (pytest, Integration, Trivy), Package (Push zu Harbor, Signatur), Deploy (GitOps mit ArgoCD).
• Moderne Anforderungen aus Cyber Resilience Act, NIS‑2, DORA und GDPR lassen sich direkt in GitLab CI/CD verankern: SBOM-Erzeugung, CVE-Scanning, signierte Images, Audit-Trails und sauberes Secrets-Management.
• Eine durchdachte Pipeline-Struktur macht Compliance zur integrierten Eigenschaft Ihrer Software-Lieferkette – statt zu einem nachgelagerten Kontrollmechanismus.
• ayedo unterstützt Sie dabei, GitLab CI/CD, Harbor, ArgoCD und Ihr Kubernetes-Ökosystem so zu orchestrieren, dass Delivery-Geschwindigkeit, Sicherheit und Compliance gleichermaßen gewinnen.

---

GitLab CI/CD als Rückgrat Ihres Delivery-Prozesses

Wer heute Software verantwortet, verwaltet nicht nur Quellcode, sondern komplette Lieferketten: Quellcodeverwaltung, Build-Prozesse, Container-Images, Policy-Checks, Deployments, Audits. GitLab CI/CD bündelt diese Fäden an einem Ort.

Statt einzelne Tools lose zu verknüpfen, definieren Sie mit GitLab CI/CD:

• wann welcher Schritt ausgeführt wird,
• welche Artefakte daraus entstehen,
• welche Qualitäts- und Compliance-Gates davor liegen,
• und wie Änderungen reproduzierbar in Ihre Produktivumgebung gelangen.

Die Pipeline wird damit zur formalen, überprüfbaren Beschreibung Ihres Lieferprozesses. Das ist nicht nur operativ wertvoll, sondern auch ein starker Hebel in Audits im Kontext von NIS‑2, DORA und dem kommenden Cyber Resilience Act.

---

GitLab CI/CD Grundlagen: .gitlab-ci.yml, Stages, Jobs, Artifacts

.gitlab-ci.yml als zentraler Vertrag

Die .gitlab-ci.yml im Repository ist der „Vertrag“ zwischen Ihrem Team und GitLab:

• Sie beschreibt die komplette Pipeline – von Tests über Builds bis zum Deployment.
• Jede Änderung ist versioniert und kann im Rahmen von Merge Requests geprüft werden.
• Review und Änderungshistorie der Pipeline selbst werden damit Teil Ihres Audit-Trails.

Organisatorisch ist es sinnvoll, die Verantwortung für diese Datei klar zu regeln: z. B. Ownership im Platform-Team, Review-Pflicht bei Produktteams.

Stages: Die logische Struktur Ihrer Lieferkette

Stages strukturieren die Pipeline in aufeinanderfolgende Phasen. Ein gängiges Muster für moderne containerbasierte Entwicklung:

1. test – Qualitätssicherung (Unit-, Integrations- und Security-Tests)
2. build – Container-Images bauen und SBOM erzeugen
3. package – Images und Charts veröffentlichen, signieren
4. deploy – GitOps-Sync in Zielumgebungen

Innerhalb einer Stage können mehrere Jobs parallel laufen. Erst wenn alle Jobs einer Stage erfolgreich abgeschlossen sind, beginnt die nächste. So modellieren Sie explizite „Quality Gates“, etwa: kein Build, solange Tests oder Security-Scans fehlschlagen.

Jobs: Konkrete Aufgaben mit klarer Verantwortung

Ein Job beschreibt eine konkrete Tätigkeit, z. B.:

• „Unit-Tests ausführen mit pytest“
• „Container-Image mit Kaniko bauen“
• „Image mit Trivy auf CVEs scannen“
• „Helm-Chart paketieren und nach Harbor pushen“
• „ArgoCD-Sync für Staging auslösen“

Jeder Job:

• läuft in einem definierten Container-Image (Ihre „Build-Umgebung“),
• hat ein klares Skript (z. B. Shell-Befehle),
• kann Artifacts erzeugen,
• und lässt sich gezielt wiederholen oder manuell anstoßen.

Artifacts: Die Belege Ihrer Pipeline

Artifacts sind Dateien, die ein Job erzeugt und an nachfolgende Jobs oder menschliche Reviewer weitergibt – besonders wichtig für Compliance:

• Testreports (JUnit, Coverage)
• Security-Reports (Trivy, SAST/DAST)
• SBOM-Dateien (z. B. CycloneDX, SPDX)
• Paketierte Artefakte (Helm-Charts, Manifeste)

In einer von Cyber Resilience Act und NIS‑2 geprägten Welt sind Artifacts nicht nur technisch nützlich, sondern auch Nachweise: Sie dokumentieren, dass definierte Prüfungen tatsächlich stattgefunden haben.

---

Eine praxisnahe Pipeline: Von Kaniko bis ArgoCD

Im Folgenden skizzieren wir eine typische, in der Praxis bewährte Pipeline-Struktur für containerisierte Anwendungen auf einer modernen Plattform mit Kubernetes, GitLab, Harbor und ArgoCD.

Stage „build“: Container-Image und SBOM

In der Build-Phase geht es um reproduzierbare, sichere Images.

Kaniko für container-native Builds

Statt einen Docker-Daemon in der CI zu betreiben, nutzt die Pipeline ein Kaniko-Image als Build-Umgebung. Der Job:

• zieht den Applikations-Quellcode,
• baut daraus das Container-Image,
• versieht es mit sinnvollen Tags (Commit-Hash, SemVer, ggf. Build-Nummer),
• und pusht es in ein Projekt in Harbor.

Wichtig aus Compliance-Sicht:

• Das Image wird aus einer klar definierten Basis (Trusted Base Image) gebaut.
• Die Build-Logs sind reproduzierbar und im Job-Log einsehbar.
• Die verwendeten Basis-Images können Teil Ihres freigegebenen Katalogs sein.

SBOM-Erzeugung im Build

Parallel oder direkt im Anschluss erzeugt ein weiterer Job eine Software Bill of Materials (SBOM) für das gerade gebaute Image, z. B. im CycloneDX- oder SPDX-Format. Die SBOM wird:

• als Artifact abgelegt,
• mit dem Image-Tag verknüpft,
• und idealerweise zusammen mit dem Image in Harbor gespeichert.

Der Cyber Resilience Act fordert Transparenz über Software-Komponenten; eine automatisierte SBOM-Erzeugung im Build ist der praktischste Weg dorthin.

Stage „test“: Qualität und Security

Die Test-Stage kann mehrere Jobs parallel ausführen.

Unit- und Integrationstests mit pytest

Ein Job führt z. B. Unit-Tests mit pytest im Anwendungs-Container oder einem entsprechenden Test-Image aus, ein weiterer Job Integrationstests (z. B. gegen eine temporäre Datenbank).

Best Practices:

• Testjobs speichern ihre Reports als Artifacts.
• Coverage-Metriken werden zurück in GitLab gespielt, sodass Sie Trends über Zeit sehen.
• Merge Requests werden nur freigegeben, wenn definierte Qualitätskriterien erfüllt sind.

Security-Scans mit Trivy

Ein weiterer Job nutzt Trivy oder ein ähnliches Tool für Vulnerability-Scanning:

• Entweder gegen das frisch gebaute Container-Image,
• oder direkt gegen die SBOM (SBOM-basiertes Scanning).

Trivy-Reports werden als Artifacts gespeichert. In einem Compliance-Kontext können Sie definieren:

• welche Schweregrade (CVSS-Scores) toleriert werden,
• für welche Schweregrade ein Merge oder Deployment blockiert wird,
• und wie Ausnahmen (temporär akzeptierte Vulnerabilities) dokumentiert werden.

Damit schlagen Sie eine direkte Brücke zu Anforderungen aus NIS‑2 und DORA nach systematischem Schwachstellenmanagement.

Stage „package“: Registry, Signaturen und Helm-Charts

In der Package-Phase werden die Ergebnisse der vorherigen Stages in wiederverwendbare Einheiten überführt.

Push zu Harbor und Signatur mit Notary

Ein Job übernimmt das Veröffentlichen des Container-Images in Harbor:

• Images werden in dedizierte Projekte (z. B. „dev“, „staging“, „prod“) gepusht.
• Neben dem eigentlichen Image werden Metadaten wie SBOM-Referenzen hinterlegt.

Anschließend signiert ein weiterer Job das Image – etwa über Notary oder COSIGN:

• Es entsteht eine kryptografische Signatur, die sicherstellt, dass das Image aus Ihrer Pipeline stammt.
• Downstream-Systeme (z. B. Admission Controller im Cluster) können damit erzwingen, dass nur signierte Images deployt werden.

Signierte Container-Images sind ein zentraler Baustein für eine vertrauenswürdige Lieferkette im Sinne des Cyber Resilience Act.

Helm-Charts paketieren

Für Kubernetes-basiertes Deployment werden Helm-Charts gebaut und in derselben Registry abgelegt:

• Chart-Versionen werden automatisiert aus Git-Metadaten abgeleitet.
• Das Chart referenziert die zuvor gebauten und signierten Images.
• Auch Charts können signiert werden, sodass sichergestellt ist, dass Deployments nur freigegebene Versionen verwenden.

Stage „deploy“: GitOps mit ArgoCD

Statt Deployments direkt aus der CI-Pipeline anzustoßen, setzt sich GitOps durch: Ihre Pipeline ändert nur Git-Repositories, während ArgoCD diese Änderungen in Ziel-Cluster synchronisiert.

Ein typischer Deploy-Job:

• aktualisiert die Image-Tags oder Chart-Versionen im GitOps-Repository (z. B. über einen Commit auf einem „environment“-Repo),
• stößt optional einen ArgoCD-Sync oder Health-Check an,
• dokumentiert im Job-Log, welche Version wohin deployt wurde.

Vorteile:

• Jede Änderung an einer Umgebung ist als Git-Commit nachvollziehbar – inklusive Autor, Zeitpunkt und Kommentar.
• Rollbacks sind standardisiert: ArgoCD kann auf frühere Commits zurückspringen.
• Audit-Anforderungen aus NIS‑2 und DORA nach Nachvollziehbarkeit und Wiederherstellbarkeit werden auf Prozess-Ebene erfüllt.

---

Compliance-by-Design: CRA, NIS‑2/DORA und GDPR in der Pipeline

Cyber Resilience Act: SBOM, CVE-Scanning, signierte Images

Der Cyber Resilience Act wurde 2024 auf EU-Ebene verabschiedet und tritt 20 Tage nach Veröffentlichung im Amtsblatt in Kraft; die meisten Pflichten werden nach einer Übergangsfrist von 36 Monaten anwendbar sein. GitLab CI/CD ist das ideale Vehikel, um diese Pflichten pragmatisch umzusetzen:

• Transparenz über Komponenten: SBOM-Generierung im Build als Pflichtschritt.
• Schwachstellen-Management: Automatisiertes CVE-Scanning von Images und SBOMs; definierte Grenzwerte blockieren Releases bei kritischen Lücken.
• Integrität der Lieferkette: Signierte Container-Images und Charts, enforced durch Policy-Engines im Cluster.

Statt auf manuelle Dokumentation zu setzen, erzeugt Ihre Pipeline diese Nachweise automatisch – konsistent und auditierbar.

NIS‑2 und DORA: Audit-Trails und Kontrollmechanismen

Die NIS‑2-Richtlinie (Richtlinie (EU) 2022/2555) ist am 16.01.2023 in Kraft getreten; Mitgliedstaaten müssen sie bis zum 17.10.2024 in nationales Recht umsetzen. Die DORA-Verordnung (Verordnung (EU) 2022/2554) gilt ab dem 17.01.2025 unmittelbar für Finanzunternehmen in der EU.

Beide Regime verlangen robuste Prozesse und nachvollziehbare Kontrollen. GitLab CI/CD unterstützt Sie dabei:

• Transparente Änderungswege: Jede Pipeline ist mit einem Commit, einem Merge Request und einem Autor verknüpft.
• Genehmigungs-Workflows: Deployments in sensible Umgebungen können an manuelle Bestätigungen (Manual Jobs) oder Merge-Request-Approvals geknüpft werden.
• Automatisierte Protokollierung: Job-Logs, Artifacts und Umgebungs-Informationen dienen als Audit-Trail, ohne dass Teams zusätzliche Tabellen pflegen müssen.

GitLab wird damit ein wichtiges Puzzlestück Ihrer übergeordneten Compliance-Strategie.

GDPR: Keine Secrets in Git, sauberes Handling personenbezogener Daten

Die GDPR (DSGVO) gilt seit dem 25.05.2018 und adressiert auch technische und organisatorische Maßnahmen in der Softwareentwicklung.

Wesentliche Punkte für Ihre Pipeline:

• Keine Klartext-Secrets in Git: Zugangsdaten, Tokens, private Schlüssel haben im Repository nichts verloren. Stattdessen:
  • GitLab CI Variables (masked, protected),
  • externe Secret-Stores (z. B. Vault) und deren Integration über den External Secrets Operator im Cluster.
• Log-Hygiene: Job-Logs sollten keine personenbezogenen Daten enthalten. Das betrifft insbesondere Integrationstests mit realen Daten – hier sind Anonymisierung oder synthetische Testdaten Pflicht.
• Datenflüsse verstehen: SBOMs und Reports können indirekt Informationen über verwendete Komponenten offenlegen. Sie sollten bewusst entscheiden, mit wem Sie welche Reports teilen.

Eine gut strukturierte GitLab-Pipeline macht es deutlich einfacher, diese Regeln konsequent und überprüfbar umzusetzen.

---

Gedankliches Beispiel: Eine vollständige .gitlab-ci.yml im Überblick

Ohne in konkrete Konfigurationen abzutauchen, lohnt ein strukturierter Blick darauf, wie eine vollständige .gitlab-ci.yml für den oben beschriebenen Prozess typischerweise aufgebaut ist.

Globale Definitionen

Am Anfang steht meist eine Reihe globaler Elemente:

• Stages: test, build, package, deploy.
• Globale Variablen:
  • Registry-URL (z. B. für Harbor),
  • Projektname und Namespace,
  • Image-Name und Tag-Konvention (z. B. Commit-Hash, Release-Tag),
  • Pfade zu Helm-Charts und SBOM-Dateien.
• Default-Image (optional): Eine Standard-Build-Umgebung für einfache Jobs.

Diese Sektion bildet die Basis, auf die alle nachfolgenden Jobs zugreifen.

Test-Jobs

Die Test-Stage umfasst mehrere Jobs, typischerweise:

• Linting/Static Analysis: Code-Qualität und einfache Sicherheitsregeln.
• Unit-Tests: Ausführung mit pytest oder einem äquivalenten Framework; Erzeugung von Test- und Coverage-Reports.
• Integrationstests: Start unterstützender Services (z. B. Test-DB), Ausführung komplexerer Test-Suiten.

Alle diese Jobs:

• speichern ihre Reports als Artifacts,
• markieren die Pipeline als fehlgeschlagen, wenn Tests scheitern,
• können in Merge Requests bereits als „Preview“ laufen, bevor Code in den Haupt-Branch gelangt.

Build- und SBOM-Jobs

In der Build-Stage sehen wir typischerweise:

• Image-Build mit Kaniko:
  • Nutzung eines Kaniko-Executor-Images,
  • Authentifizierung gegenüber Harbor über CI-Variablen,
  • Push des resultierenden Images mit mehreren Tags (z. B. Commit-Hash und „latest“).
• SBOM-Generierung:
  • Job, der das gerade gebaute Image scannt,
  • Erzeugung einer SBOM-Datei,
  • Abspeichern als Artifact und optional Upload in ein dediziertes SBOM-Repository.

Die Build-Stage wird nur gestartet, wenn alle Test-Jobs erfolgreich waren.

Security- und Packaging-Jobs

Je nach Teamstruktur können Security-Scans eine eigene Stage oder Teil der Build-/Package-Stage sein. Typischer Aufbau:

• Vulnerability-Scan mit Trivy:
  • Scan des Images oder der SBOM,
  • Generierung eines strukturierten Reports,
  • Markierung kritischer Findings, die die Pipeline blockieren.
• Image-Signatur:
  • Job, der Notary oder ein vergleichbares Tool nutzt,
  • Ablage der Signatur in der Registry oder einem begleitenden System.
• Helm-Chart-Packaging:
  • Aktualisierung von Versionsfeldern im Chart,
  • Packaging des Charts,
  • Push in die OCI-fähige Registry (Harbor).

Hier greifen technische und regulatorische Anforderungen unmittelbar ineinander.

Deploy-Jobs mit GitOps

Die Deploy-Stage ist oft in mehrere Umgebungen unterteilt:

• Deploy to Dev/Staging:
  • Automatisches Update des GitOps-Repos (z. B. Branch „staging“),
  • optional automatischer ArgoCD-Sync.
• Deploy to Production:
  • Job, der nur auf Tags oder Releases reagiert,
  • häufig als „manual“ markiert, sodass ein menschliches Approval nötig ist,
  • Update des Produktions-Branches im GitOps-Repo,
  • ArgoCD-Sync und Health-Check.

Jeder dieser Jobs dokumentiert:

• welche Image-/Chart-Version wohin deployt wurde,
• welcher Benutzer das Deployment (bei manuellen Jobs) freigegeben hat,
• ob und wann ArgoCD das Deployment erfolgreich synchronisiert hat.

Damit wird die .gitlab-ci.yml zu einem lesbaren, versionierten Abbild Ihres gesamten Delivery- und Governance-Modells.

---

Häufige Fragen

Wie weit muss ich GitLab CI/CD standardisieren, bevor ich an Compliance denken kann?

Sie müssen nicht auf eine „perfekte“ Pipeline warten. Sinnvoll ist ein iterativer Ansatz:

1. Baseline schaffen: Einheitliche Grundstruktur (test, build, package, deploy) für alle Services.
2. Sicherheits-Checks integrieren: Mindestens ein automatisierter Vulnerability-Scan und grundlegende Testpflicht.
3. Compliance-Gates ergänzen: SBOM-Erzeugung, Signaturen, manuelle Approvals für sensible Deployments.

Wichtig ist, dass Ihre Teams sich auf einen gemeinsamen Mindeststandard einigen. GitLab CI/CD macht es relativ einfach, zentrale Vorlagen (Template-Jobs, Include-Files) zu definieren, die dann in allen Projekten genutzt werden.

Wie passt das zu bestehenden Tools wie Jenkins oder GitHub Actions?

Viele Organisationen leben zunächst mit einer Übergangsphase, in der mehrere CI/CD-Systeme parallel existieren. GitLab CI/CD punktet bei:

• enger Integration mit Merge Requests,
• durchgängigem Audit-Trail in einem System,
• einfacher Kopplung mit Registries wie Harbor und GitOps-Tools wie ArgoCD.

Eine pragmatische Strategie ist es, neue oder stark regulierte Anwendungen prioritär auf GitLab CI/CD zu migrieren und Legacy-Pipelines schrittweise nachzuziehen. Wichtig ist eine klare Roadmap – nicht der sofortige „Big Bang“.

Wie unterstützt ayedo konkret bei GitLab CI/CD und Compliance?

ayedo kombiniert Plattform-Expertise mit regulatorischem Verständnis:

• Wir entwerfen gemeinsam mit Ihren Teams standardisierte, GitLab-basierte Delivery-Pipelines, die auf Ihre Plattform-Landschaft (inkl. Kubernetes, Harbor, ArgoCD) abgestimmt sind.
• Wir integrieren Security- und Compliance-Funktionen (SBOM, CVE-Scanning, Signaturen, Audit-Trails) so, dass sie technische Exzellenz unterstützen statt Entwicklungsprozesse zu blockieren.
• Wir helfen dabei, diese Standards in Ihren Organisationseinheiten zu verankern – inkl. Schulung, Dokumentation und Vorbereitung auf Prüfungen im Rahmen von NIS‑2, DORA und GDPR.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

GitLab CI/CD wird dann zum echten Rückgrat Ihres Delivery-Prozesses, wenn Pipeline-Definitionen, Plattform-Komponenten und Compliance-Anforderungen als zusammenhängendes System gedacht werden. Eine sauber strukturierte .gitlab-ci.yml ist dabei mehr als eine technische Datei: Sie ist die ausführbare Spezifikation Ihres Software-Lebenszyklus – inklusive der Nachweise, die Aufsichtsbehörden und interne Revisionen zunehmend einfordern.

In vielen Organisationen besteht die Herausforderung weniger in der Technik als in der Koordination: Wie setzen wir einheitliche Standards? Wie integrieren wir Registries wie Harbor, GitOps-Controller wie ArgoCD und zentrale Security-Tools sinnvoll? Und wie stellen wir sicher, dass Teams diese Vorgaben nicht als Bremse, sondern als Enabler erleben?

Genau an dieser Schnittstelle arbeitet ayedo: Wir bauen und betreiben für Sie eine integrierte Software Delivery Plattform, auf der GitLab CI/CD, Kubernetes, Registry, Secrets-Management und Observability zusammenspielen. Gemeinsam mit Ihren Engineering- und Security-Teams entwickeln wir wiederverwendbare Pipeline-Bausteine, die:

• moderne Anforderungen aus Cyber Resilience Act, NIS‑2, DORA und GDPR abbilden,
• Ihre vorhandenen Tools und Prozesse einbinden,
• und gleichzeitig genug Flexibilität für unterschiedliche Applikationsteams lassen.

Wenn Sie Ihre bestehenden Pipelines in Richtung eines belastbaren, auditierbaren und dennoch schlanken CI/CD-Standards weiterentwickeln möchten, begleiten wir Sie von der ersten Bestandsaufnahme über das Zielbild bis zur praktischen Implementierung in Ihren Projekten.

Für einen strukturierten Einstieg in dieses Thema und konkrete Empfehlungen zu Ihrer Situation laden wir Sie ein zu einem gemeinsamen Gespräch zu Ihren
CI/CD Best Practices