CI/CD-Pipeline

Kurz: Ein automatisierter Ablauf, der bei jeder Code-Änderung Tests, Build und Auslieferung der Software durchführt — Continuous Integration / Continuous Delivery (oder Deployment).

Genauer: CI steht dafür, dass Änderungen häufig und automatisiert getestet und zusammengeführt werden (statt seltener, großer manueller Integrationen). CD baut darauf auf und liefert getestete Änderungen automatisiert in eine Test- oder Produktivumgebung aus. Läuft meist auf jeden Git-Push oder Pull Request.

Im Detail

Pipeline-Stufen

Eine typische Pipeline besteht aus mehreren aufeinanderfolgenden Stufen (Stages), die jeweils automatisch abgebrochen werden, sobald eine fehlschlägt — spart Zeit, da nicht sinnlos weitergemacht wird, wenn schon der erste Schritt scheitert:

1. Build: Code kompilieren/bündeln, Abhängigkeiten installieren.
2. Test: automatisierte Tests ausführen (Unit-Tests, Integrationstests).
3. Lint/Static Analysis: Code-Qualität und -Stil automatisch prüfen, oft auch Sicherheitsscans.
4. Deploy: die geprüfte Version tatsächlich ausliefern (Test-, Staging- oder Produktivumgebung).

Eine minimale Konfiguration (z. B. für GitHub Actions) sieht so aus:

on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test
      - run: npm run build

CI vs. CD vs. Continuous Deployment

Der Kerngedanke hinter Continuous Integration ist, Integrationsprobleme früh und in kleinen Häppchen aufzudecken, statt sie erst kurz vor einer großen Release anzugehen (“Integration Hell” — ein historisch berüchtigtes Problem, wenn mehrere Entwickler wochenlang isoliert an Features arbeiten und ihre Änderungen am Ende mühsam zusammenführen müssen). Continuous Delivery bedeutet, dass jede erfolgreich getestete Änderung jederzeit auslieferbar wäre (der letzte Schritt bleibt aber oft ein manueller Klick, z. B. weil ein Release-Zeitpunkt bewusst gesteuert werden soll); Continuous Deployment geht noch einen Schritt weiter und liefert automatisch ohne manuellen Freigabeschritt aus, sobald alle Prüfungen grün sind — die konsequenteste Form, die aber sehr zuverlässige automatisierte Tests voraussetzt, um riskant zu sein.

Praktischer Nutzen

Der wirtschaftliche Kern von CI/CD: je später ein Fehler entdeckt wird, desto teurer ist seine Behebung — ein Tippfehler, der schon beim lokalen Testen auffällt, kostet Sekunden; derselbe Fehler, der erst nach einem Produktiv-Deployment durch Kundenbeschwerden auffällt, kann Stunden oder Tage an Untersuchung und Reputationsschaden kosten. CI/CD-Pipelines verschieben die Fehlerentdeckung so früh wie möglich im Entwicklungsprozess.

Caching und Parallelisierung

Bei größeren Projekten wird die Pipeline-Laufzeit selbst zum Thema: Abhängigkeiten (z. B. node_modules) werden zwischen Läufen gecacht statt jedes Mal neu heruntergeladen, und unabhängige Stufen (z. B. Linting und Unit-Tests) laufen parallel statt sequenziell, um die Wartezeit bis zum Ergebnis zu verkürzen — bei häufigen Commits summiert sich selbst eine kleine Zeitersparnis pro Lauf schnell zu spürbar produktiverer Entwicklung.

Siehe auch: Git, GitHub