Begriff

Pipeline Stage

DevOps CI/CD S1

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Eine CI/CD Pipeline ist wie ein Fließband in der Autofabrik. Das Auto wird nicht in einem Schritt gebaut. Es gibt Stationen:

Karosserie schweißen.
Lackieren.
Motor einbauen.
Qualitätskontrolle. In DevOps heißt jede Station Stage.
Build Stage: Code kompilieren.
Test Stage: Unit Tests laufen lassen.
Deploy Stage: Auf Server schieben. Die Regel: Stage 2 startet erst, wenn Stage 1 erfolgreich war. Wenn Lackieren (Stage 2) fehlschlägt, wird kein Motor eingebaut (Stage 3 stoppt).

Merksatz: Ein logischer Abschnitt innerhalb einer CI/CD-Pipeline, der eine Gruppe von Aufgaben (Jobs) zusammenfasst, die parallel ausgeführt werden können, aber sequenziell zu anderen Stages stehen.

.gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

compile_job:
  stage: build
  script: make

unit_test:
  stage: test
  script: npm test

lint_test:
  stage: test # Läuft PARALLEL zu unit_test!
  script: npm run lint

Alle Jobs in "test" warten, bis "build" fertig ist. Aber unit_test und lint_test laufen gleichzeitig (schneller).

1. Artifact Passing

Stage 1 (Build) erzeugt eine Datei app.jar. Stage 2 (Test) läuft auf einem anderen Server (Runner). Der Runner löscht alles nach dem Job. Wie kommt app.jar zu Stage 2? Artifacts. Stage 1 lädt app.jar zum CI-Server hoch (S3/Minio). Stage 2 lädt es automatisch runter. Ohne Artifacts compilst du in jeder Stage neu (Zeitverschwendung!).

2. DAG (Directed Acyclic Graph)

Stages ("Erst alles A, dann alles B") sind starr. Was, wenn ich den "Android Build" und "iOS Build" habe? iOS dauert 20 Minuten, Android 2 Minuten. Die "Deploy Android" Stage müsste 20 Min warten, bis iOS fertig ist. Moderne Pipelines nutzen DAGs (needs in GitLab). "Deploy Android" braucht nur "Build Android". Es startet sofort, wenn Android fertig ist, auch wenn iOS noch baut. Das beschleunigt Pipelines massiv.

3. Manual Gates & Environments

Die "Deploy Prod" Stage ist oft speziell. Sie läuft nicht automatisch. when: manual. Ein Mensch muss im UI auf "Play" drücken. Oft gekoppelt mit Environments ("Protected Environment"). Nur Maintainer dürfen diesen Knopf drücken. Sicherheitsschleuse vor dem Release.

1. Job Orchestration Architecture (Master-Worker)

Wenn eine Stage getriggert wird, kommandiert der GitLab/Jenkins Master. Der Master führt den Code nicht aus! Er agiert aus Sicherheits- und Stabilitätsgründen als reiner Disponent. Er wählt aus dem Runner-Pool einen passenden Executor (Worker) basierend auf Tags (z.B. "GPU", "Docker_Allowed"). Der Worker greift mittels Long-Polling die Job-Payload als JSON auf. Die gesamte Stage-Logik (Git Clone, Build, Upload Cache, Cleanup) läuft auf der rohen OS-Ebene des Workers mittels des Bash/PowerShell Sub-Prozesses. Ist die "Deploy"-Stage beendet, sendet der Runner den Exit-Code an den Master und committet Suizid (Ephemeral Runner Re-Provisioning), während der Master die Nachfolge-Pipeline-Stages evaluiert.

2. Cross-Project Pipelines & Rest API Trigger

Monolithen sind einfach. Was aber bei Microservices? Service A (Frontend) ist in Repository A. Service B (Backend API) in Repo B. Ein Commit im Frontend bringt nichts, wenn die Backend-API nicht mit-deployt und Integrations-getestet wird (End-To-End). Hier springen Downstream Pipelines ein. Die "Trigger"-Stage im Repo A generiert mittels der CI/CD REST-API und eines Pipeline-Tokens einen Callback an das GitLab-Backend von Repo B. Das stößt die externe Pipeline an. Repo A wartet synchron ("strategy: depend") auf das Success-Signal der externen Repo-Pipeline, erst dann gilt die gesamte Architektur als valide getestet. Multi-Project-Orchestration at scale!

3. Dynamic Matrix Builds (Fan-Out/Fan-In)

Du bist Library-Autor. Dein Code (1 Modul) muss auf 3 OS (Linux, Windows, Mac), in 3 Node-Versionen (14, 16, 18) mit 2 Datenbanken (Postgres, MySQL) laufen. Statt 18 getrennte Jobs manuell ins YAML zu frickeln, erzeugst du eine Matrix Stage. Du deklarierst nur Arrays (os: [lin, win, mac], node: [14, 16, 18]). Der CI-Server multipliziert bei Start die Arrays als kartesisches Produkt auf (Fan-Out) und feuert dynamisch 18 Server in exakt dieser Stage in der Cloud hoch. Fällt ein einzelner Build (Windows, Node 14, MySQL) fehlerhaft zurück, färbt die gesamte Stage augenblicklich rot, stoppt den Rest (Fail-Fast-Strategie) und schützt das Artefakt (Fan-In Collect).

Quick-Check

Fail-Fast?
Wenn ein Job in der "Build" Stage crasht, bricht die ganze Pipeline sofort ab. Keine nachfolgenden Stages laufen. Das spart Rechenzeit (Cloud-Kosten). Ausnahme: allow_failure: true (für unwichtige Jobs wie "Check Spelling").
Parallel Matrix?
Eine Stage kann einen Job 10x starten ("Split Testing"). Test Node 14, Test Node 16, Test Node 18. Sie laufen alle parallel in der gleichen Stage.
Cache vs Artifact?
Cache ist für Dependencies (node_modules), die man wiederverwenden kann, aber nicht muss (Speedup). Artifacts sind für Ergebnisse (app.dist), die man zwingend braucht. Cache ist pro Runner, Artifacts sind global.