Was ist ein Canary Release?
Ein Canary Release, auch Canary Rollout oder Canary Deployment genannt, rollt eine neue Softwareversion zunächst nur für einen kleinen Teil der Nutzer aus, typisch 1 bis 5 %. Bleiben Fehlerrate und Latenz der Canary-Version stabil, wächst der Anteil schrittweise bis 100 %; bei Auffälligkeiten erfolgt der Rollback, bevor alle Nutzer betroffen sind. Der Name leitet sich von Kanarienvögeln im Bergbau ab.
Auch bekannt als: Canary Rollout · Canary Deployment · Canary-Version · Canary-Bereitstellung
Ist Canary Release bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Ein Canary Release senkt das Risiko eines Deployments, indem die neue Version zuerst nur einen kleinen Teil der Nutzer oder des Traffics bekommt. Zeigt diese Teilmenge keine Auffälligkeiten, steigt der Anteil schrittweise, bis die neue Version den gesamten Traffic bedient. Der Name geht auf die Kanarienvögel zurück, die Bergleute unter Tage mitnahmen, weil sie früher als der Mensch auf giftige Gase reagierten.
Ohne Beobachtbarkeit ist ein Canary blind. Während des Rollouts vergleicht ein Werkzeug Fehlerrate, Latenz und Ressourcenverbrauch der Canary-Version mit denen der stabilen Version. Überschreiten die Werte definierte Schwellen, rollt es zurück, bevor die Mehrheit der Nutzer betroffen ist. Wie das ohne getrennte Messung ausgeht, zeigt ein typischer Fall: Die Canary lief eine Stunde ohne einen einzigen Alarm, weil niemand die Fehlerrate der neuen Version getrennt von der alten gemessen hatte. Als die ersten Tickets kamen, stand der Rollout längst bei 100 Prozent.
Das Metrik-Gate jeder Stufe hat zwei Stellschrauben. Die erste ist das Zeitfenster, häufig fünf bis dreißig Minuten, damit genug Anfragen für eine Aussage zusammenkommen. Die zweite ist der Vergleichsmaßstab. Verglichen wird die Canary mit der stabilen Version, nicht mit einem absoluten Grenzwert, typischerweise bei der Latenz im p95 oder p99. Nur so fällt eine neue Version auf, die zwar unter der Alarmschwelle bleibt, aber doppelt so viele Fehler macht wie die alte. Fällt die Canary durch, lenkt das Werkzeug den Traffic vollständig zurück und baut sie ab, ohne dass jemand um zwei Uhr nachts entscheiden muss.
Im Kubernetes-Umfeld automatisieren zwei Werkzeuge diesen Ablauf: Argo Rollouts aus dem Argo-Projekt und Flagger aus dem Flux-Projekt. Argo Rollouts ersetzt das Deployment-Objekt durch eine eigene Rollout-Ressource und entscheidet über AnalysisTemplates gegen Prometheus, Datadog oder Webhooks. Flagger arbeitet mit dem vorhandenen Deployment und steuert den Traffic über Service Mesh oder Ingress. Beide können die Kubernetes Gateway API als Ebene für die Traffic-Aufteilung nutzen, Argo Rollouts über ein Plugin. Ein Canary ist damit nicht mehr an einen bestimmten Ingress-Controller gebunden. Dieses datengetriebene Ausweiten des Rollouts heißt Progressive Delivery.
Blue-Green schaltet auf einen Schlag von einer Umgebung auf die andere um, Canary tastet sich prozentweise heran. Blue-Green ist die einfachere Wahl, wenn zwei Versionen nicht parallel arbeiten dürfen, etwa weil ein Datenbank-Schema nicht abwärtskompatibel ist. Canary passt, wenn ein vollständiges Umschalten zu riskant wäre oder echtes Nutzerverhalten unter realer Last beobachtet werden soll. Feature Flags steuern dagegen, welche Funktion innerhalb einer Version sichtbar ist, und ergänzen einen Canary. Beim Canary laufen immer zwei Versionen gleichzeitig, deshalb müssen Datenbank-Schemata, APIs und Nachrichtenformate beide bedienen können.
Automatischer Rollback in der Nacht, ohne dass jemand geweckt wird
Ein Plattform-Team rollt neue Service-Versionen über Argo Rollouts aus. Ein AnalysisTemplate prüft Fehlerrate und Latenz gegen Prometheus und stoppt den Rollout bei einer Schwellwert-Verletzung. Vom ersten automatischen Rollback erfährt das Team am nächsten Morgen aus dem Log. Niemand wurde geweckt, und außerhalb der Fünf-Prozent-Gruppe hat kein Nutzer etwas bemerkt.
Fehlerhaftes Firmware-Update erreicht ein Prozent der Flotte
Ein Hersteller vernetzter Maschinen verteilte Updates früher an alle Anlagen zugleich. Heute geht ein Firmware-Update zuerst an ein Prozent der Flotte. Bleibt die Telemetrie stabil, wächst die Ausrollquote in Stufen. Ein fehlerhaftes Update trifft damit nie die gesamte Flotte auf einmal.
Ist ein Canary Release der richtige Weg?
Ein Canary Release testet neue Versionen an einem kleinen Nutzeranteil — das setzt aber Metriken und etwas Werkzeug voraus. Zwei Klicks zeigen, ob das zu Ihnen passt oder eine schlichtere Strategie reicht.
Wie wollen Sie neue Versionen ausrollen?
- Was bedeutet Canary?
- Canary ist das englische Wort für Kanarienvogel und steht in der Softwareauslieferung für eine Frühwarn-Instanz: die neue Version, die als Erste echten Traffic bekommt und an deren Verhalten sich entscheidet, ob der Rest folgt. Der Begriff stammt aus dem Bergbau, wo Kanarienvögel unter Tage früher auf giftige Gase reagierten als der Mensch. Im DevOps-Sprachgebrauch sind Canary Release, Canary Rollout und Canary Deployment Synonyme. Bei Browsern wie Chrome heißt Canary Build die täglich gebaute Vorabversion, die vor allen anderen ausgeliefert wird.
- Warum heißt es Canary Release?
- Der Name stammt vom Kanarienvogel im Bergbau: Der Vogel reagierte auf giftige Gase früher als der Mensch und diente unter Tage als Frühwarnsystem. Genauso ist die Canary-Instanz das Frühwarnsystem des Deployments. Sie erhält zunächst nur einen kleinen Teil des Traffics, typisch 1–5 %, und wird anhand von Live-Metriken bewertet. Bleiben Fehlerrate und Latenz stabil, wächst der Anteil schrittweise. Überschreiten sie definierte Schwellwerte, rollt das Werkzeug automatisch zurück, bevor die Mehrheit der Nutzer betroffen ist.
- Was ist eine Canary-Version?
- Die Canary-Version ist die neue Ausgabe der Software, die während des Rollouts parallel zur stabilen Version läuft und zunächst nur einen kleinen Teil des Traffics erhält. An ihren Live-Metriken entscheidet sich, ob das Release schrittweise ausgeweitet oder zurückgerollt wird.
- Ist Canary Deployment dasselbe wie Canary Release?
- Ja. Canary Deployment und Canary Rollout sind gängige Synonyme für Canary Release; alle drei bezeichnen dasselbe schrittweise Ausrollen an zunächst 1 bis 5 Prozent der Nutzer. Deployment betont die technische Auslieferung, Release den Freigabeschritt. Am Ablauf mit Metrik-Gate und automatischem Rollback ändert das nichts.
- Wie läuft ein Canary Rollout ab?
- In fünf Schritten: Die neue Version wird parallel zur stabilen deployt und erhält zunächst 1–5 % des Traffics. Dann vergleicht ein Werkzeug Fehlerrate, Latenz und Ressourcenverbrauch der Canary-Version mit der stabilen Version. Bleiben die Metriken unter den Schwellwerten, wächst der Anteil stufenweise, etwa über 5, 25 und 50 auf 100 %. Bei einer Schwellwert-Verletzung rollt das Werkzeug automatisch zurück, und nach Erreichen von 100 % wird die alte Version abgebaut. Tools wie Argo Rollouts oder Flagger automatisieren alle fünf Schritte.
- Canary Deployment oder Blue-Green: Wann nehme ich was?
- Canary ist die bessere Wahl, wenn echtes Nutzerverhalten unter realer Last beobachtet werden soll oder ein vollständiges Umschalten zu riskant ist. Ein Fehler trifft dann von vornherein nur eine kleine Nutzergruppe. Blue-Green passt besser, wenn alte und neue Version nicht gleichzeitig laufen dürfen oder ein Rollback in Sekunden wichtiger ist als die feine Dosierung.
- Was brauche ich, damit ein Canary automatisch zurückrollt?
- Sie brauchen getrennt messbare Metriken der neuen Version, definierte Schwellwerte und ein Werkzeug, das über Promotion und Rollback entscheidet. Im Kubernetes-Umfeld ist das etwa Argo Rollouts mit einem AnalysisTemplate gegen Prometheus oder Datadog.
- Welche Probleme entstehen, weil bei Canary zwei Versionen parallel laufen?
- API- und Datenbank-Kompatibilität müssen gewährleistet sein, damit alte und neue Version dieselben Daten teilen können. Ein neues Pflichtfeld, das die alte Version nicht schreibt, bricht sonst die Hälfte der Anfragen. Feature Flags helfen zusätzlich, neue Funktionen gezielt nur für die Canary-Gruppe zu aktivieren.
Wo steht Ihr Team bei Canary Release?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Canary Release: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Martin FowlerCanary Release(externe Seite, öffnet in neuem Tab)
Grundlagenartikel zur schrittweisen Freigabe an einen kleinen Nutzerkreis.
- /02Argo ProjectCanary Strategy(externe Seite, öffnet in neuem Tab)
Schrittfolge, Traffic-Anteile und metrikbasierte Freigabe in Kubernetes.
- /03KubernetesWorkload-Verwaltung(externe Seite, öffnet in neuem Tab)
Zeigt Canary-Deployments mit Labels und parallelen ReplicaSets ohne Zusatzwerkzeug.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance