CI/CD
Wiederholbare Auslieferung statt Ad-hoc-Releases
Continuous Integration (CI) und Continuous Deployment (CD) machen Software-Auslieferung wiederholbar: Code wird automatisch gebaut, geprüft und bei passender Freigabe ausgeliefert. Ziel ist eine Pipeline, die jede Änderung nachvollziehbar validiert und manuelle Varianz reduziert.
Automatisierung reduziert Wiederholarbeit, macht Prüfungen konsistenter und verkürzt den Weg von einer geprüften Änderung bis zur Auslieferung.
Anti-Patterns: Manuelle Release-Angst
- Deployment-Wochenenden: Teams arbeiten Nächte durch, um Software manuell auf Server zu kopieren, was regelmässig zu Fehlern und Ausfällen führt.
- Mangelnde Test-Abdeckung: Tests werden erst am Ende des Zyklus manuell durchgeführt, wodurch Fehler erst sehr spät (und teuer) gefunden werden.
- Inkonsistente Umgebungen: Die Software funktioniert in der Entwicklung, aber scheitert auf dem Produktionsserver ("But it works on my machine!").
Lösungsansatz: Die automatisierte Pipeline
- Continuous Integration (CI): Automatisches Bauen und Testen des Codes bei jedem Commit. Fehler werden innerhalb von Minuten erkannt.
- Automated Testing: Integration von Unit-, Integrations- und End-to-End-Tests direkt in die Pipeline (Shift-Left Testing).
- Continuous Deployment (CD): Vollautomatischer Rollout auf Test- und Produktionsumgebungen ohne manuelles Eingreifen.
- Infrastructure as Code (IaC): Auch die Server-Infrastruktur wird automatisiert über Skripte erstellt und aktualisiert, was die Reproduzierbarkeit der Umgebungen deutlich erhöht. Configuration Drift, Provider-Defaults, Secrets und manuelle Eingriffe bleiben jedoch mögliche Abweichungsquellen.
- Monitoring und Rollback: Automatische Überwachung neuer Releases und sofortiger automatischer Rückzug (Rollback), falls Fehler im Live-Betrieb auftreten.
Der Fokus: Geschwindigkeit durch Vertrauen
Entwickler können sich stärker auf den Code konzentrieren, da die Pipeline hilft, Fehler früher zu erkennen und die Auslieferung verlässlicher und wiederholbarer zu machen. Eine Garantie für Fehlerfreiheit oder Sicherheit ist sie nicht.
FAQ
CEO: "Ist es nicht gefährlich, wenn Code vollautomatisch live geht?"
Antwort: Manuelle Eingriffe sind eine häufige Fehlerquelle. Eine automatisierte Pipeline führt die definierten Schritte konsistent aus und reduziert manuelle Varianz. Sie ist aber nur so gut wie die konfigurierten Prüfungen und kann übersehen, was sie nicht testen soll.
Manager: "Wie viel Zeit müssen wir in den Aufbau dieser Pipelines investieren?"
Antwort: Ob und wann sich das Investment rechnet, hängt vom konkreten Kontext ab: Release-Frequenz, Aufwand für manuelle Tests, Incident-Kosten und Fehlerrate. Bei häufigen Releases ist die eingesparte Zeit für manuelle Tests und Fehlerbehebungen oft erheblich.
Referenzen
- Kim, Gene et al. The DevOps Handbook. Kulturelle und technische Umsetzung von DevOps. (2016). itrevolution.com/product/the-devops-handbook-second-edition/
- Humble, Jez; Farley, David Continuous Delivery. Grundlagen der Pipeline-Automatisierung. (2010). continuousdelivery.com
- GitLab CI/CD Documentation. Praxisreferenz für moderne Pipelines. docs.gitlab.com/ci/