CI/CD (Continuous Integration / Continuous Delivery)

Continuous Integration bedeutet, dass jeder Entwickler häufig (idealerweise mehrmals täglich) Code in den gemeinsamen Hauptzweig committet, anstatt in langlebigen Zweigen zu arbeiten. Jeder Commit löst eine automatisierte Pipeline aus, die: den Code kompiliert, die vollständige Unit- und Integrationstest-Suite ausführt, statische Analyse und Linting durchführt, ein bereitstellbares Artefakt erstellt und Erfolg oder Misserfolg innerhalb von Minuten meldet. Die entscheidende kulturelle Regel von CI: Fehlerhafte Builds haben für das Team höchste Priorität – ein fehlerhafter Hauptzweig blockiert alle und meldet sofort die Bereitstellungsbereitschaft des Teams. CI verhindert die "Integrationshölle", die entsteht, wenn Entwickler wochenlang in isolierten Zweigen arbeiten und dann alle ihre Änderungen gleichzeitig zusammenführen müssen, was zu Konflikten und Fehlern führt, deren Behebung Tage dauert. Product Ops unterstützt CI, indem es sicherstellt, dass Produktspezifikationen klare, testbare Kriterien enthalten, die Ingenieure in automatisierte Tests umwandeln können.

Beide umfassen die automatisierte Vorbereitung von Release-Artefakten, nachdem CI erfolgreich war, unterscheiden sich jedoch im letzten Schritt. Continuous Delivery bedeutet, dass die Software immer in einem bereitstellbaren Zustand ist – alle automatisierten Prüfungen bestanden, verpackt und versandbereit – aber ein Mensch trifft die explizite Entscheidung, in die Produktion bereitzustellen. Eine Bereitstellung ist eine Ein-Klick-Aktion, die ausgeführt wird, wenn das Unternehmen bereit ist. Continuous Deployment geht einen Schritt weiter: Jeder Commit, der die CI-Pipeline durchläuft, wird ohne menschliches Eingreifen automatisch in die Produktion bereitgestellt. Die meisten SaaS-Unternehmen verwenden Continuous Delivery (vom Menschen ausgelöste Bereitstellung) in Kombination mit Feature Flags für eine kontrollierte Einführung. Continuous Deployment wird von Teams mit extrem ausgereifter Testinfrastruktur und Überwachung eingesetzt. Product Ops beeinflusst die Kadenz der Bereitstellungsentscheidungen – indem es den Bereitstellungszeitpunkt mit dem Release-Kalender abstimmt, um sicherzustellen, dass die GTM-Bereitschaft mit den Produktionsänderungen einhergeht.

Eine produktionsreife CI/CD-Pipeline (implementiert in GitHub Actions, CircleCI, GitLab CI oder Jenkins) umfasst diese Phasen: Trigger (bei jedem Pull Request und Merge in den Hauptzweig); Build (Quellcode kompilieren, Abhängigkeiten auflösen, Docker-Image erstellen); Unit Tests (schnelle Tests, die einzelne Funktionen und Komponenten abdecken, Ziel-Laufzeit < 5 Minuten); Integration Tests (Test der Interaktionen zwischen Komponenten, einige externe Dienste gemockt, Ziel < 15 Minuten); End-to-End Tests (Browser-Automatisierungstests kritischer Benutzerflüsse gegen eine Staging-Umgebung, Ziel < 30 Minuten); Security Scan (SAST-Tools scannen nach anfälligen Abhängigkeiten und Sicherheitsproblemen auf Code-Ebene); Artifact Build and Push (produktionsreifes Artefakt wird in die Container-Registry gepusht); Staging Deployment (automatische Bereitstellung in die Staging-Umgebung zur manuellen QA-Verifizierung); und Production Deployment (manueller Trigger oder vollautomatisch, mit Feature Flag-Aktivierung als Rollout-Kontrolle). Product Ops überwacht Pipeline-Gesundheitsmetriken (Build-Erfolgsrate, Pipeline-Dauer-Trends) als Indikatoren für die Engineering-Geschwindigkeit.