CI/CD (Continuous Integration/Continuous Deployment)

CI/CD steht für Continuous Integration (kontinuierliche Integration) und Continuous Deployment (kontinuierliche Bereitstellung) - zwei verbundene DevOps-Praktiken. CI bedeutet, dass Code-Änderungen mehrmals täglich in ein gemeinsames Repository integriert und automatisch getestet werden. CD geht weiter: Nach erfolgreichen Tests wird der Code automatisch auf Staging- oder Produktiv-Umgebungen deployed.

Der typische CI/CD-Workflow: Entwickler pusht Code zu Git → CI-Server (GitHub Actions, GitLab CI, Jenkins) startet automatisch → Code wird gebaut (Build) → Automatisierte Tests laufen (Unit, Integration, E2E) → Bei Erfolg: Deployment auf Staging → Optional: Manuelle Freigabe → Production Deployment. Der gesamte Prozess dauert Minuten statt Stunden oder Tage bei manuellen Releases.

Die Vorteile sind transformativ: Bugs werden früh erkannt (nicht erst beim manuellen Testen Wochen später), Releases sind klein und risikoarm (statt großer Big-Bang-Releases), Teams können täglich oder mehrmals täglich deployen und Rollbacks bei Problemen sind einfach. Moderne Hosting-Plattformen wie Vercel und Netlify bieten CI/CD out-of-the-box: Git-Push löst automatisch Build und Deployment aus.

In der Abkürzung steckt eine oft verwechselte Doppelbedeutung des zweiten C: Continuous Delivery bedeutet, dass jede Änderung automatisch bis zu einem release-fähigen Zustand gebracht wird, der letzte Schritt in die Produktion aber ein manueller Klick bleibt; Continuous Deployment geht weiter und rollt ohne menschliches Eingreifen bis in die Produktion aus. Für risikoarme Auslieferung haben sich mehrere Strategien etabliert: Blue-Green-Deployment hält zwei identische Umgebungen bereit und schaltet nach dem Test schlagartig um; Canary Releases leiten zunächst nur einen kleinen Prozentsatz des Traffics auf die neue Version, um Fehler früh und mit begrenztem Schaden zu erkennen; Rolling Updates tauschen Instanzen nach und nach aus.

Eine gute Pipeline ist schnell und reproduzierbar. Beschleunigt wird sie durch Caching von Abhängigkeiten und Build-Artefakten sowie durch Monorepo-Werkzeuge, die nur die tatsächlich betroffenen Teile bauen. Genau so arbeitet das Nexus-Monorepo hinter HEADON.pro: GitHub Actions baut per turbo --affected ausschließlich geänderte Apps, verpackt sie als Docker-Images in der GitHub Container Registry und deployt sie per SSH auf den Server, abgesichert durch einen Health-Check nach dem Rollout. Kritisch sind dabei zwei Dinge: sauberes Secret-Management (Zugangsdaten gehören in verschlüsselte CI-Variablen, niemals ins Repository) und aussagekräftige automatisierte Tests - denn eine Pipeline automatisiert das Ausliefern von gutem wie von fehlerhaftem Code gleichermaßen zuverlässig.