DevOps & CI/CD

Entstehung und Beteiligte

Der Begriff DevOps verbreitete sich 2009 durch Patrick Debois und die ersten DevOpsDays. Continuous Integration wurde zuvor durch Extreme Programming und Martin Fowler bekannt; Continuous Delivery wurde 2010 durch Jez Humble und David Farley systematisiert.

Welches Problem sollte gelöst werden?

Entwicklung und Betrieb arbeiteten oft mit gegensätzlichen Zielen. Seltene große Releases verursachten riskante Übergaben. Kleine automatisierte Änderungen sollten schneller und nachvollziehbarer in Produktion gelangen.

Technische Hürden und Lösungen

Werkzeuge allein verändern keine Verantwortlichkeiten. Tests, sichere Artefakte, Datenbankmigrationen, Rollback und Beobachtung müssen zusammenspielen. Zu viele parallele Pipelines können Lieferkettenrisiken vergrößern.

Standardisierung und Einordnung

Cloud- und Plattformtechnik entstand aus Rechenzentrum, Virtualisierung, verteilten Systemen und automatisierter Softwareauslieferung. Die grundlegenden Probleme sind nicht neu: Ressourcen müssen geteilt, Ausfälle abgefangen, Änderungen reproduzierbar und Lastspitzen bewältigt werden. Neu ist die hohe Automatisierung und die Möglichkeit, Infrastruktur über Programmierschnittstellen in kurzer Zeit zu erzeugen oder zu verwerfen.

Technik im praktischen Betrieb

Im praktischen Cloudbetrieb müssen Automatisierung und Kosten gemeinsam beobachtet werden. Ressourcen entstehen schnell, verschwinden aber nicht immer automatisch. Tags, Limits, Richtlinien und getrennte Konten oder Projekte schaffen Verantwortlichkeit. Verfügbarkeit sollte über mehrere Fehlerdomänen geplant und mit realen Wiederanlaufproben belegt werden. Ein Anbieter übernimmt Gebäude, Hardware und Teile der Plattform; Konfiguration, Identitäten, Daten, Anwendungen und Backups bleiben je nach Dienstmodell ganz oder teilweise beim Kunden.

Warum das Thema heute noch relevant ist

Viele Cloudbegriffe klingen neu, beschreiben aber bekannte verteilte Systeme unter stärkerer Automatisierung. Die Geschichte hilft, Marketing und Architektur zu trennen. Ein Dienst bleibt von Netz, Speicher, Konsens und Identitäten abhängig, auch wenn diese Schichten nicht sichtbar sind. Betreiber sollten deshalb Ausfallmodelle, Datenexport und Abhängigkeiten dokumentieren. Je bequemer ein verwalteter Dienst ist, desto wichtiger wird die Frage, welche Kontrolle bewusst an den Anbieter abgegeben wurde.

Daten und Meilensteine

• 2009 finden die ersten DevOpsDays in Gent statt.
• CI integriert Änderungen häufig und automatisiert Tests.
• Continuous Delivery hält Software auslieferbar.
• Continuous Deployment liefert erfolgreiche Änderungen automatisch produktiv aus.

Was ist DevOps?

DevOps ist eine Kultur, Philosophie und Sammlung von Praktiken, die Softwareentwicklung (Dev) und IT-Betrieb (Ops) näher zusammenbringt. Ziel ist es, die Zeit zwischen einem Commit und dem produktiven Einsatz zu verkürzen, bei gleichzeitig höherer Qualität und Stabilität.

Das Kernprinzip: Automatisierung von allem. Manuelles Deployment ist fehleranfällig, langsam und nicht reproduzierbar. "If it hurts, do it more often" – je häufiger du deployest, desto kleiner und sicherer werden die Änderungen.

CI – Continuous Integration

Continuous Integration bedeutet, dass jeder Entwickler mindestens täglich seinen Code in den gemeinsamen Branch integriert. Eine automatisierte Pipeline läuft bei jedem Commit:

1. Code-Commit triggert die CI-Pipeline (z.B. GitHub Actions, GitLab CI)
2. Build: Code wird kompiliert, Docker-Image gebaut
3. Unit Tests: Schnelle Einzelkomponenten-Tests (Ziel: <5 Minuten)
4. Integration Tests: Tests zwischen Komponenten
5. Code Quality: Linting, Static Analysis, Code Coverage
6. Security Scanning: SAST (Static), Dependency-Checks, Secrets-Scanning

CD – Continuous Delivery & Deployment

Continuous Delivery stellt sicher, dass jede Codeänderung jederzeit produktionsbereit ist. Ein Mensch entscheidet final über das Deployment. Continuous Deployment geht weiter: Nach erfolgreich durchlaufener Pipeline geht alles automatisch in Produktion – kein manueller Schritt mehr.

Deployment-Strategien: Blue/Green (zwei identische Environments, sofortiger Switch), Canary (5% → 20% → 100% des Traffics), Rolling Update (Instanz für Instanz aktualisieren), Feature Flags (Code deployed, Feature für bestimmte User aktivieren).

DORA-Metriken

Das DORA-Team (DevOps Research & Assessment, jetzt Google) hat vier Kernmetriken für DevOps-Performance definiert:

Deployment Frequency: Wie oft deployest du? Elite: mehrmals täglich. Low: monatlich oder seltener. Lead Time for Changes: Zeit vom Commit bis Produktion. Elite: <1 Stunde. Change Failure Rate: % der Deploys, die einen Incident verursachen. Elite: 0–15%. MTTR (Mean Time to Restore): Zeit bis zur Wiederherstellung nach Incident. Elite: <1 Stunde.