Vom Commit zum vollständigen Rollout: Aufbau einer Progressive-Delivery-Pipeline

Du mergest deinen Code in den Hauptbranch. Die CI-Pipeline wird grün. Das Artefakt ist fertig. Und jetzt?

In den meisten Teams ist der nächste Schritt einfach: Deployment in die Produktion. Aber wenn du schon einmal zugesehen hast, wie ein Deployment schiefging – ein Bug, der erst unter echtem Traffic auftaucht, eine Performance-Regression, die sich unbemerkt einschleicht, eine Funktion, die Nutzer verwirrt – dann weißt du: „Auf einmal an alle Nutzer ausrollen“ ist ein Glücksspiel, das du nicht eingehen musst.

Progressive Delivery ändert das. Statt eines großen Schalters rollst du Änderungen schrittweise aus, nutzt Traffic-Routing, Feature Flags und automatisiertes Monitoring, um bei jedem Schritt zu entscheiden, ob es weitergeht oder zurückgerollt wird. Dieser Artikel zeigt, wie du eine vollständige Progressive-Delivery-Pipeline zusammenbaust – vom Moment des Merges bis zur vollständigen und stabilen Auslieferung.

Das folgende Flussdiagramm zeigt die Phasen der Pipeline auf einen Blick:

Der Build und die grundlegenden Tests

Die Pipeline startet wie jede andere. Wenn ein Entwickler Code in den Hauptbranch merged, führt die Pipeline Unit-Tests, Integrationstests und Sicherheitsscans durch. Das sind die gleichen Checks, die du bereits hast – noch nichts Besonderes.

Wenn alles bestanden ist, erzeugt die Pipeline ein deploybares Artefakt. Hier beginnt sich Progressive Delivery von einer Standard-Pipeline zu unterscheiden. Das Artefakt geht nicht direkt an alle Nutzer. Es tritt in den ersten Deployment-Ring ein, der typischerweise Canary-Ring genannt wird.

Der Canary-Ring: Dein erster echter Test

Der Canary-Ring erhält einen kleinen Bruchteil des Traffics – sagen wir, ein Prozent aller Anfragen. Die Pipeline deployed die neue Version auf die Server, die diesen Ring bedienen. Dann aktiviert sie die relevanten Feature Flags für Nutzer, die in diesen Ring fallen.

Hier ist ein GitLab-CI-Beispiel, das den Canary-Ring und die gestaffelten Rollout-Schritte definiert:

stages:
  - canary
  - staged-rollout
  - full-rollout

canary-deploy:
  stage: canary
  script:
    - kubectl set image deployment/my-app canary=my-app:$CI_COMMIT_SHA
    - kubectl scale deployment/my-app --replicas=1
  environment:
    name: production/canary
    url: https://canary.example.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

auto-promote:
  stage: staged-rollout
  script:
    - sleep 600  # 10-minütiges Monitoring-Fenster
    - ./check-metrics.sh  # Fehlerrate, Latenz innerhalb SLO prüfen
    - kubectl set image deployment/my-app-10pct my-app=my-app:$CI_COMMIT_SHA
    - kubectl scale deployment/my-app-10pct --replicas=2
  needs: ["canary-deploy"]
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

rollout-50pct:
  stage: staged-rollout
  script:
    - ./check-metrics.sh
    - kubectl set image deployment/my-app-50pct my-app=my-app:$CI_COMMIT_SHA
  needs: ["auto-promote"]
  when: manual  # erfordert manuelle Freigabe

rollout-100pct:
  stage: full-rollout
  script:
    - ./check-metrics.sh
    - kubectl set image deployment/my-app my-app=$CI_COMMIT_SHA
  needs: ["rollout-50pct"]
  when: manual

Feature Flags bieten hier eine zusätzliche Kontrollebene. Auch wenn die neue Version läuft, können bestimmte Funktionen nur für bestimmte Nutzer im Canary-Ring aktiviert werden. So kannst du nicht nur die Stabilität der neuen Version testen, sondern auch das Verhalten einer bestimmten Funktion an echten Nutzern, ohne alle dem auszusetzen.

Während die neue Version im Canary-Ring läuft, setzt die Observability ein. Die Pipeline überwacht Fehlerrate, Latenz und andere Metriken, die in deinen Service Level Objectives (SLOs) definiert sind. Bleiben alle Metriken für einen festgelegten Zeitraum – sagen wir zehn Minuten – innerhalb der akzeptablen Grenzen, fährt die Pipeline automatisch mit der nächsten Stufe fort. Verletzt eine Metrik den Schwellenwert, löst die Pipeline einen automatischen Rollback aus: Der Traffic wird zurück zur alten Version umgeleitet, Feature Flags werden deaktiviert und das Team wird benachrichtigt.

Gestaffelter Rollout: Das Publikum erweitern

Die nächste Stufe ist ein breiterer Ring, der vielleicht zehn Prozent der Nutzer bedient. Der Prozess wiederholt sich: deployen, Flags aktivieren, überwachen, entscheiden. Aber jetzt hast du mehr Spielraum, um mit Feature Flags zu experimentieren. Du könntest die neue Funktion zum Beispiel nur für Nutzer aktivieren, die sich als Beta-Tester registriert haben. Das liefert dir echte Daten von echten Nutzern, ohne alle zu beeinträchtigen.

Die Pipeline erweitert das Publikum schrittweise: von zehn Prozent auf fünfundzwanzig Prozent, dann auf fünfzig Prozent und schließlich auf einhundert Prozent. Jedes Mal, wenn die Pipeline zum nächsten Ring übergeht, durchläuft sie ein Promotion-Gate. Dieses Gate kann eine automatisierte Prüfung auf Basis von Metriken sein oder auf eine manuelle Freigabe durch das Team warten. Viele Teams verwenden eine Kombination: automatisierte Gates für schnelle Entscheidungen und manuelle Freigaben für kritische Phasen, wie zum Beispiel vor dem Wechsel auf einhundert Prozent der Nutzer.

Bereinigung von Feature Flags

Sobald die neue Version alle Nutzer bedient, ist die Pipeline noch nicht fertig. Feature Flags, die jetzt für alle aktiv sind, müssen bereinigt werden. Die Pipeline kann eine Aufgabe ausführen, die prüft, ob ein Flag noch verwendet wird, und dann einen Pull Request erstellt, um den Flag-Code aus dem Repository zu entfernen. Das verhindert, dass sich in deiner Codebasis tote Flags ansammeln, an die sich niemand mehr erinnert.

Was diese Pipeline anders macht

Eine Progressive-Delivery-Pipeline ist nicht nur eine Abfolge von Deployments. Sie ist ein System, das Traffic-Management, Feature-Steuerung, automatisiertes Monitoring und datengetriebene Entscheidungen in einem einzigen Ablauf vereint, der vom Commit bis zum vollständigen Rollout reicht. Jede Stufe ist eine Sicherheitsschicht, die sicherstellt, dass Änderungen nicht plötzlich die Benutzererfahrung beeinträchtigen.

Der Hauptunterschied zu einer traditionellen Pipeline ist, dass du nicht fragst: „War der Build erfolgreich?“ Du fragst: „Ist die Änderung sicher genug, um sie mehr Nutzern zu zeigen?“ Diese Frage kann nicht allein durch Unit-Tests beantwortet werden. Sie erfordert echten Traffic, echte Nutzer und echte Metriken.

Praktische Checkliste für deine Pipeline

Wenn du eine Progressive-Delivery-Pipeline aufbaust, überprüfe diese Komponenten in jeder Phase:

• Canary-Ring: Erhält er einen kleinen, messbaren Bruchteil des Traffics? Kannst du Nutzer konsistent routen, sodass derselbe Nutzer im selben Ring bleibt?
• Feature Flags: Sind Flags auf bestimmte Nutzer oder Gruppen beschränkt? Kannst du sie unabhängig vom Deployment umschalten?
• Observability: Werden Fehlerrate, Latenz und Geschäftsmetriken überwacht? Basieren die Schwellenwerte auf deinen SLOs, nicht auf willkürlichen Annahmen?
• Promotion-Gates: Hat jeder Ring eine klare Bedingung für den Fortschritt? Gibt es einen manuellen Freigabeschritt für kritische Erweiterungen?
• Rollback: Ist der Rollback automatisiert, wenn Metriken Schwellenwerte verletzen? Umfasst er sowohl Traffic-Routing als auch die Deaktivierung von Flags?
• Flag-Bereinigung: Gibt es einen Prozess, um Flags nach dem vollständigen Rollout zu entfernen? Erstellt die Pipeline einen Pull Request oder benachrichtigt sie das Team?

Das Fazit

Eine Progressive-Delivery-Pipeline verwandelt das Deployment von einem binären Ereignis in einen abgestuften Prozess. Du veröffentlichst eine Änderung nicht und hoffst auf das Beste. Du veröffentlichst sie für eine kleine Gruppe, beobachtest, was passiert, und entscheidest, ob du weitermachst. Wenn etwas schiefgeht, ist nur ein winziger Bruchteil der Nutzer betroffen, und das System erholt sich automatisch.

Bei der Pipeline geht es nicht darum, Komplexität hinzuzufügen. Es geht darum, Kontrolle hinzuzufügen. Jeder Ring, jedes Gate, jede Metrikprüfung ist eine Chance, ein Problem zu erkennen, bevor es zu einem Vorfall wird. Baue deine Pipeline mit diesem Gedanken, und du wirst nach jedem Merge besser schlafen.