CI/CD-Pipeline aufbauen: Phasen und Stages

In L1 hast du das Konzept CI/CD kennengelernt und eine Pipeline-Animation gesehen. Jetzt schauen wir uns das Innenleben einer Pipeline detailliert an: was passiert in jeder Stage genau, wie hängen die Stages zusammen, wie werden Artefakte weitergereicht, und wie strukturiert man komplexe Pipelines mit mehreren Umgebungen.

Diese Lektion ist tool-agnostisch – die Konzepte gelten gleichermaßen für GitHub Actions, GitLab CI/CD, Jenkins. Wenn du die Stages verstehst, kannst du dich in jedes Tool einarbeiten.

1) Stage, Job, Step – die Hierarchie

Jede CI/CD-Pipeline hat eine hierarchische Struktur mit drei Ebenen, die du nicht verwechseln solltest:

• Pipeline: der gesamte Ablauf, ausgelöst durch ein Ereignis (z.B. Push, Pull-Request, Zeitplan)
• Stage: eine logische Phase wie „Build", „Test", „Deploy". Stages laufen typischerweise nacheinander.
• Job: eine konkrete Aufgabe innerhalb einer Stage. Mehrere Jobs in einer Stage laufen oft parallel.
• Step / Task: einzelner Befehl oder Aktion innerhalb eines Jobs (z.B. npm install)

Beispiel: Pipeline „CI" hat Stages „Build, Test, Deploy". Die Test-Stage hat zwei parallele Jobs „Unit-Tests" und „Integration-Tests". Jeder Job führt mehrere Steps aus.

2) Die typischen Pipeline-Stages im Detail

Schau dir jede Stage genauer an – klick die Stages für Details:

3) Sequentielle vs. parallele Ausführung

Innerhalb einer Stage können mehrere Jobs parallel laufen – ein wichtiger Faktor für Pipeline-Geschwindigkeit. Aber nicht alles ist parallelisierbar:

4) Trigger: was startet eine Pipeline?

Eine Pipeline läuft nicht „einfach so" – sie wird durch ein Ereignis ausgelöst. Die wichtigsten Trigger:

5) Artefakte: was wird zwischen Stages weitergereicht?

Stages sind nicht isoliert – sie teilen Daten über Artefakte. Ein Artefakt ist eine Datei oder ein Verzeichnis, das in einer Stage entsteht und in späteren Stages gebraucht wird:

6) Multi-Environment-Pipelines

Professionelle Software wird nicht direkt von Entwicklungs- auf Live-Server deployed. Stattdessen gibt es mehrere Umgebungen mit unterschiedlichem Risiko-Niveau:

7) Beispiel: kompletter Pipeline-Aufbau

Hier ein realistisches Pipeline-Beispiel in GitLab CI/CD-Syntax, das viele Konzepte zusammenführt:

Lies das Beispiel von oben nach unten: 4 Stages definiert, dann pro Stage ein oder mehrere Jobs. Build-Stage hat 1 Job. Test-Stage hat 2 Jobs die parallel laufen. Deploy-Staging läuft automatisch bei jedem Push auf main. Deploy-Production läuft nur bei einem Git-Tag und nur auf manuellen Knopfdruck.

8) Caching: schneller durch Wiederverwendung

Ein Trick um Pipelines schneller zu machen: Cache. Dependencies (npm-Packages, Maven-Artefakte, pip-Packages) brauchen Minuten zu laden. Wenn sich nichts an der Dependency-Definition geändert hat – wozu nochmal laden?

Mit Cache spart eine Pipeline oft 60-80% Zeit. Wichtig: der Cache-Key muss sich ändern wenn die Dependencies sich ändern – sonst hast du veraltete Daten. Übliche Praxis: Hash der package-lock.json als Key.

9) Quality Gates: wann darf eine Pipeline weiter?

Eine Quality Gate ist ein Schwellenwert, den eine Pipeline erfüllen muss um zur nächsten Stage zu kommen. Beispiele:

• Tests müssen alle grün sein: keine roten Tests, sonst Stopp
• Code-Coverage mindestens 80%: weniger? Pipeline bricht ab
• Keine Security-Findings mit CVSS > 7: kritische CVEs blocken Deploy
• Linting ohne Errors: Warnings ok, Errors nicht
• Maximale Komplexität pro Funktion: zu komplexer Code wird verboten
• Bundle-Size unter X: bei Frontend-Apps wichtig für Performance

Tools wie SonarQube haben Quality-Gates eingebaut. Wenn ein Gate scheitert, schlägt die Pipeline fehl – egal wie kritisch das Feature ist, dass deployed werden sollte.

10) Pipeline-Optimierungs-Tipps

Wenn deine Pipeline zu langsam ist (über 10-15 Min), gibt es bewährte Optimierungen:

• Parallelisieren wo möglich: Tests auf mehrere Runner aufteilen
• Caching nutzen: Dependencies, Build-Outputs, Docker-Layers
• Fail Fast: schnellste Stages zuerst (Lint vor Tests, Tests vor Build vor Deploy)
• Nur betroffene Module bauen: bei Monorepos nicht alles neu, nur was sich geändert hat
• Shallow Clones: git clone --depth=1 spart bei großen Repos viel Zeit
• Docker-Layer-Caching: häufig unveränderte Layer cachen, nur App-Layer neu
• Pipeline-Triggers verfeinern: nicht jede Doku-Änderung muss Tests triggern
• Selbstgehostete Runner: bei viel CI-Last günstiger und schneller als SaaS

Faustregel: jede Stage sollte unter 5 Minuten dauern. Wenn länger – aufteilen oder optimieren. Eine 30-minütige Pipeline frustriert Entwickler und sie umgehen sie irgendwann.

Zusammenfassung

Eine CI/CD-Pipeline besteht aus Stages (Phasen) mit Jobs (Aufgaben) und Steps (Befehlen). Typische Stages: Checkout → Build → Test → Quality → Package → Deploy. Stages laufen sequentiell, Jobs in einer Stage oft parallel. Trigger: push, pull_request, schedule, manual, tag, webhook. Artefakte wandern zwischen Stages (Source → JAR → Docker-Image → Running Pods). Multi-Environment: dev → integration → staging → production, oft mit manuellen Approvals vor prod. Quality Gates blockieren Pipeline bei nicht erfüllten Kriterien (Coverage, Security, Linting). Caching spart Zeit. Faustregel: jede Stage unter 5 Min, gesamt unter 15 Min.