Was ist Progressive Delivery? Canary, Blue-Green und Flags

Was ist progressive delivery? Es ist eine Methode, Software in kleinen, kontrollierten Schritten in die Produktion zu bringen. Jeder Schritt wird anhand echter Metriken geprüft, bevor der nächste beginnt. Zeigen die Zahlen Probleme, stoppt die Auslieferung oder rollt sich automatisch zurück. Sie setzen dabei nicht mehr die gesamte Nutzerbasis auf ein einziges Deployment.

Die Situation kennen Sie vermutlich. Ein Pull Request ist freigegeben, die CI ist grün, das Deployment geht an einem Dienstagnachmittag raus, und zwanzig Minuten später fragt jemand im Slack, warum sich die Checkout-Latenz verdoppelt hat. Progressive Delivery soll dieses Gespräch kürzer machen und dafür sorgen, dass der Fehler 5% des Traffics trifft statt 100%.

Was ändert Progressive Delivery tatsächlich?

Klassisches Continuous Delivery beantwortet eine Frage: Können wir das sicher in die Produktion bringen? Progressive Delivery ergänzt eine zweite: Wer sieht es zuerst, und was sagt uns, dass wir anhalten müssen?

Der Kern ist die Trennung von Deployen und Releasen. Deployen heißt, der neue Code läuft auf den Servern. Releasen heißt, Nutzer werden ihm ausgesetzt. Sobald beides entkoppelt ist, können Sie am Mittwoch um 14 Uhr deployen und das Release in Ihrem Tempo an eine gewählte Zielgruppe ausliefern, mit einem Weg zurück.

Die meisten Quellen nennen drei Bausteine: die schrittweise Verlagerung des Traffics (Canary), parallele Umgebungen (Blue-Green) und Feature Flags. Sie sind keine Konkurrenten. Reife Teams nutzen alle drei auf unterschiedlichen Ebenen.

Canary Releases: Wie viel Traffic, und wer entscheidet?

Ein Canary Release schickt einen kleinen Teil des Traffics, etwa 5%, auf die neue Version, während der Rest auf der alten bleibt. Bleiben Fehlerrate, Latenz und Sättigung innerhalb Ihrer Schwellenwerte, wächst der Anteil: 5%, 25%, 50%, 100%. Falls nicht, geht der Traffic zurück.

Der Haken: Feine Aufteilungen brauchen etwas, das den Traffic verteilen kann. Die Dokumentation von Argo Rollouts beschreibt, dass präzise Canary-Anteile einen Traffic-Manager wie ein Service Mesh oder einen Ingress-Controller erfordern. Ohne einen solchen gibt es nur grobe Steuerung über die Replikazahlen. Dann bedeutet "5%" womöglich "ein Pod von zwanzig".

So sieht ein gestufter Canary in einem Argo-Rollouts-Manifest aus. Bewusst kurz gehalten:

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 10m }   # Dashboards prüfen oder Analyse laufen lassen
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 100

Ein Canary lohnt sich nicht überall. Bei Services mit so wenig Traffic, dass 5% ein paar Requests pro Stunde sind, warten Sie ewig auf ein Signal, oder Sie halten Rauschen für Sicherheit. Bei wenig frequentierten Services ist ein Feature Flag für interne Nutzer die bessere erste Hürde.

Blue-Green Deployments: Wann lohnt sich eine komplette zweite Umgebung?

Blue-Green betreibt zwei vollständige Produktionsumgebungen. Blue bedient die Nutzer. Green erhält die neue Version und wird im Leerlauf getestet. Sind Sie zufrieden, wird der Traffic von der einen auf die andere umgeschaltet.

Laut der Dokumentation von Argo Rollouts erfolgt der Wechsel auf einen Schlag: Die alte Version behält den gesamten Produktionstraffic, bis die neue verifiziert ist, und dann springt die Aufteilung von 0% auf 100%. Das ist Stärke und Schwäche zugleich. Der Rollback ist ein einziger Umschalter und damit schnell. Dafür findet der Test statt, bevor echte Nutzer kommen, und die Kosten sind doppelte Infrastruktur, solange beide Seiten laufen.

Sinnvoll ist das bei zustandsbehafteten oder kritischen Services, bei denen ein Teil-Rollout verwirrend wäre, etwa bei einem Zahlungspfad, auf dem zwei Versionen niemals gleichzeitig Anfragen bearbeiten dürfen. Verzichten Sie darauf, wenn Ihre Datenbankmigration nicht auf beiden Versionen gleichzeitig laufen kann, denn dann ist der "sofortige Rollback" eine Fiktion.

Wo passen Feature Flags hinein?

Canary und Blue-Green arbeiten auf Infrastrukturebene. Feature Flags arbeiten innerhalb der Anwendung. Ein Flag umschließt einen Codepfad mit einer Bedingung, die sich zur Laufzeit ändern lässt, ohne ein neues Deployment.

Damit sind Flags das feinkörnigste Werkzeug. Sie können ein Feature zuerst Mitarbeitenden zeigen, dann 1% der Accounts, dann einem Kundensegment, und es in Sekunden abschalten, falls es sich schlecht verhält. Manche Teams sehen Flags als eine Technik unter mehreren, andere als Voraussetzung des ganzen Ansatzes. In der Praxis hält die zweite Sicht stand: Sobald Sie nach Zielgruppe statt nach Server ausliefern wollen, brauchen Sie ein Flag.

Flags haben aber ihren Preis. Jedes Flag ist ein Zweig, den Ihre Tests abdecken müssen, und ein Aufräumticket, das irgendjemand schließen muss. Die ausführliche Fassung zu Mechanik und Schulden finden Sie in Was ist ein Feature Flag. Behandeln Sie jedes Flag standardmäßig als kurzlebig, mit einem Verantwortlichen und einem Löschdatum.

Tools wie LaunchDarkly und Statsig verkaufen die Verwaltungsebene: Targeting-Regeln, Audit-Logs, schrittweise Prozent-Rollouts und Experimente.

Was macht einen Rollout progressiv und nicht nur langsam?

Automatisierung. Ein Rollout, der zehn Minuten pausiert, während ein Mensch auf ein Dashboard starrt, ist nur ein langsames Deployment. Progressive Delivery wird daraus, wenn eine Maschine die Metriken prüft und die Entscheidung trifft.

Das Muster ist überall gleich:

1. Definieren Sie vor dem Release die Signale: Fehlerrate, p95-Latenz und eine Geschäftskennzahl wie den Checkout-Abschluss.

2. Definieren Sie Schwellenwerte, die "Stopp" bedeuten, und halten Sie sie in der Konfiguration fest, nicht im Kopf einzelner Personen.

3. Lassen Sie den Controller anhand dieser Signale befördern, halten oder zurückrollen.

Argo Rollouts bindet Metrikquellen ein, sodass ein Rollout automatisch befördert oder abgebrochen werden kann, je nachdem, ob die Prüfungen bestehen. Eine der Quellen, die wir gelesen haben, formuliert es unmissverständlich: Progressive Delivery ohne automatischen Rollback ist nur ein langsames Deployment. Dem stimmen wir zu.

Welche Metriken sollten einen Rollout steuern?

Halten Sie die Liste klein. Drei oder vier Signale, denen Sie bereits vertrauen, schlagen zwanzig, die nie einen Alarm ausgelöst haben.

Ein brauchbarer Startsatz: die HTTP-5xx-Rate des Canary im Vergleich zur Baseline, die p95-Latenz des Canary im Vergleich zur Baseline, die Sättigung (CPU, Speicher, Queue-Tiefe) und eine Produktmetrik. Vergleichen Sie Canary und Baseline im selben Moment, nicht den Canary mit "letzter Woche", weil sich Traffic-Muster verschieben.

Hier wird Ihr Observability-Stack unverzichtbar. Wenn Sie Metriken nicht nach Version oder Flag-Variante aufschlüsseln können, lässt sich der Canary nicht von der Baseline unterscheiden, und der ganze Ansatz bricht zusammen. Unser Einstieg Was ist Observability zeigt, wie Sie dorthin kommen.

Wie hängt Progressive Delivery mit Trunk-Based Development zusammen?

Die beiden passen gut zusammen. Trunk-Based Development hält Branches kurz und führt kleine Änderungen oft zusammen. Das Risiko: Unfertige oder ungetestete Arbeit landet häufiger im Hauptzweig. Progressive Delivery macht das sicher. Der Code landet auf dem Trunk, wird hinter einem Flag versteckt und schrittweise freigegeben.

Kleine Batches und schrittweise Exposition machen außerdem das Debugging günstiger. Scheitert ein Canary, umfasst die Verdachtsliste eine Änderung statt vierzig. Wer um 23 Uhr eine Woche gemergter Commits mit git bisect durchsucht hat, weiß, was das wert ist.

Was ist ein realistischer erster Schritt für ein Team mit 10 bis 30 Entwicklern?

Installieren Sie nicht als Erstes ein Service Mesh. Beginnen Sie mit dem kleinsten Mittel, das Ihnen einen Stopp-Knopf gibt.

• Woche 1: Setzen Sie ein riskantes Feature hinter ein Flag und geben Sie es zuerst dem eigenen Team frei.

• Woche 2: Richten Sie Dashboards pro Version für Fehlerrate und Latenz ein. Kann Ihr Tooling nicht nach Version aufteilen, beheben Sie das zuerst.

• Woche 3 und danach: Verschieben Sie einen zustandslosen Service auf einen Canary-Controller mit zwei oder drei Schritten und einem automatischen Abbruch bei steigender Fehlerrate.

Messen Sie in Stunden, nicht im "Gefühl der Sicherheit". Zählen Sie, wie viele Vorfälle auf einen kleinen Nutzeranteil begrenzt blieben, und wie lange der Rollback dauerte. Diese beiden Zahlen zeigen, ob es für Ihr Team funktioniert.

Wo brechen progressive Rollouts meist?

An drei Stellen, und keine davon ist der Controller.

Datenbankmigrationen. Ein Canary bedeutet, dass zwei Versionen Ihres Codes gleichzeitig auf dieselbe Datenbank zugreifen. Entfernt Version N+1 eine Spalte oder benennt sie um, die Version N noch liest, reißt der Canary die Baseline mit. Die langweilige Lösung ist Expand and Contract: Zuerst die neue Spalte anlegen, Code ausliefern, der beide schreibt, nachfüllen, Lesezugriffe umstellen und erst später die alte Spalte entfernen.

Sticky Sessions und Caches. Wechselt ein Nutzer bei jeder Anfrage zwischen alter und neuer Version, entstehen Fehler, die niemand reproduzieren kann. Fixieren Sie Nutzer für die Dauer des Rollouts auf eine Variante, über Cookie, Account-ID oder Flag-Auswertung.

Verzögerte Metriken. Eine Conversion-Metrik, die stündlich aktualisiert wird, kann einen zehnminütigen Canary-Schritt nicht steuern. Steuern Sie den Rollout über schnelle Signale wie Fehler und Latenz, und prüfen Sie die langsame Geschäftsmetrik, bevor Sie von 50% auf 100% gehen.

Wie behalten Sie im Repo den Überblick, was live ist?

Progressive Delivery verteilt einen Release über Konfigurationsdateien, Flag-Definitionen, Rollout-Manifeste und Dashboards. Nach einigen Monaten wird aus der Frage "Welches Flag schützt den neuen Billing-Pfad, und wem gehört es?" die übliche Routine: grep, blame, und dann jemanden fragen.

Das ist ein Problem des Code-Lesens, kein Tooling-Problem. Die Suche im Repo nach dem Flag-Schlüssel und das Verfolgen jeder Referenz bis zur Aufrufstelle findet tote Flags und halbfertige Rollouts am schnellsten. Ein Werkzeug, das aus Ihrem tatsächlichen Code beantwortet, wo ein Flag ausgewertet wird und was passiert, wenn es ausgeschaltet ist, spart hier mehr Zeit als das nächste Dashboard.

Worauf wir verzichten würden

Verzichten Sie auf Blue-Green überall, wenn Ihre Infrastrukturrechnung ohnehin ein Thema ist. Verzichten Sie auf Canaries bei Services mit kaum Traffic. Verzichten Sie auf Rollout-Tooling, das im Team niemand um drei Uhr nachts debuggen kann.

Das eigentliche Problem ist nicht die gewählte Strategie. Es ist die Lücke zwischen dem Ausliefern von Code und dem Wissen, was er in der Produktion tut. Progressive Delivery verkleinert diese Lücke Scheibe für Scheibe Traffic. Entscheidend ist die erste Scheibe: Machen Sie sie klein, machen Sie sie beobachtbar, und geben Sie ihr einen Ausschalter.