CI/CD Pipeline

A CI/CD pipeline is the assembly line that takes a commit and turns it into running software — automatically. Every push runs the same ordered stages, so shipping becomes a repeatable process instead of a hand-crafted ritual.

Where you meet it

GitHub Actions (.github/workflows/*.yml), GitLab CI (.gitlab-ci.yml), Jenkins, CircleCI.
The green check (or red X) on a pull request before it can merge.
A merge that lands in production minutes later, with nobody running deploy commands by hand.

What it does

It chains build → test → deploy into one automated flow triggered by your commits. Each stage is a gate: the next one only starts if the one before it passed. The first failure halts the run and everything downstream is skipped — so broken code never reaches production.

A green pipeline doesn't mean bug-free — it only proves the checks you bothered to write actually passed.

How it works

You push. A runner picks up the job, builds the code, runs the automated tests, and — only if everything is green — deploys. The two halves split like this:

CI (Continuous Integration) — integrate small changes often and test each one immediately, so conflicts and bugs surface within minutes.
CD (Continuous Delivery / Deployment) — keep every green build releasable. Delivery = always ready to ship (one manual click); Deployment = ship to production automatically.

Pipelines are declared as YAML. Stages run in order; a job only enters a stage once the previous stage is green:

stages: [build, test, deploy]

build:
  stage: build
  script: npm ci && npm run build

test:
  stage: test
  script: npm test          # red here halts the pipeline

deploy:
  stage: deploy
  script: ./deploy.sh prod  # only runs if test passed
  only: [main]

Watch out

Slow or flaky tests poison the well. Aim for fast builds (~10 minutes); a test that fails at random trains the team to ignore red — and then real failures slip through.
Secrets never go in the log. Use the platform's encrypted secrets/variables, not plaintext in the YAML or echo statements that leak into build output.
Delivery is not deployment. "Continuous Delivery" means ready to release; "Continuous Deployment" means it actually goes live on its own. Know which one you have.
A green pipeline is not "bug-free". It only proves the checks you wrote passed — coverage gaps and missing test cases still ship.

Go deeper

Eine CI/CD-Pipeline ist das Fließband, das aus einem Commit automatisch laufende Software macht. Jeder Push durchläuft dieselben Stufen in derselben Reihenfolge — Ausliefern wird ein wiederholbarer Prozess statt Handarbeit.

Wo es vorkommt

GitHub Actions (.github/workflows/*.yml), GitLab CI (.gitlab-ci.yml), Jenkins, CircleCI.
Der grüne Haken (oder das rote X) an einem Pull Request, bevor er gemerged werden darf.
Ein Merge, der Minuten später in Produktion landet — ohne dass jemand Deploy-Befehle von Hand tippt.

Was es tut

Es verkettet Build → Test → Deploy zu einem automatischen Ablauf, den deine Commits auslösen. Jede Stufe ist ein Gate: die nächste startet nur, wenn die davor bestanden hat. Der erste Fehlschlag stoppt den Lauf, alles dahinter wird übersprungen — kaputter Code erreicht so nie die Produktion.

Grüne Pipeline heißt nicht fehlerfrei — sie beweist nur, dass die Checks bestanden haben, die du überhaupt geschrieben hast.

Wie es funktioniert

Du pushst. Ein Runner nimmt den Job, baut den Code, führt die automatisierten Tests aus und deployt — nur wenn alles grün ist. Die zwei Hälften teilen sich so auf:

CI (Continuous Integration) — kleine Änderungen häufig integrieren und jede sofort testen, damit Konflikte und Bugs binnen Minuten auffallen.
CD (Continuous Delivery / Deployment) — jeden grünen Build releasebar halten. Delivery = jederzeit auslieferbar (ein manueller Klick); Deployment = automatisch in Produktion.

Pipelines werden als YAML deklariert. Stages laufen der Reihe nach; ein Job betritt eine Stage erst, wenn die vorige grün ist:

stages: [build, test, deploy]

build:
  stage: build
  script: npm ci && npm run build

test:
  stage: test
  script: npm test          # rot hier stoppt die Pipeline

deploy:
  stage: deploy
  script: ./deploy.sh prod  # läuft nur, wenn test bestanden hat
  only: [main]

Worauf achten

Langsame oder flaky Tests vergiften alles. Ziel sind schnelle Builds (~10 Minuten); ein Test, der zufällig fehlschlägt, gewöhnt das Team daran, Rot zu ignorieren — und echte Fehler rutschen durch.
Secrets gehören nie ins Log. Nutze die verschlüsselten Secrets/Variablen der Plattform, kein Klartext im YAML oder echo-Statements, die in die Build-Ausgabe lecken.
Delivery ist nicht Deployment. „Continuous Delivery" heißt releasebereit; „Continuous Deployment" heißt, es geht von selbst live. Wissen, was man hat.
Eine grüne Pipeline heißt nicht „fehlerfrei". Sie beweist nur, dass deine Checks bestanden haben — Lücken in der Abdeckung und fehlende Testfälle gehen trotzdem mit raus.