Canary-Deploys, die tatsächlich die Fehlerrate beobachten, nicht nur einen Timer

Ein Standard-Deploy ist binär: Das neue Release besteht seinen Health-Check, und der gesamte Traffic wechselt sofort zu ihm. Das ist in Ordnung, bis das, was kaputtgeht, kein Absturz beim Booten ist, sondern ein langsames Leck, das sich erst unter 100% der Produktionslast zeigt – bis es offensichtlich ist, hat schon jeder die schlechte Version. Genau für diese Lücke gibt es Canary-Deploys.

Was tatsächlich passiert

Schalte es unter Settings → General → Deploy strategy ein, wähle Canary, und setze einen Canary-Anteil (1–99%): Dieser Prozentsatz neuer Besucher bekommt das neue Release, das direkt neben dem aktuellen läuft, es aber noch nicht ersetzt. Ein Cookie hält jeden Besucher für einen Tag auf der Version, auf der er zuerst gelandet ist – niemand wird mitten in einer Session zwischen alt und neu hin- und hergeworfen.

Von da an entscheiden drei Einstellungen, wie vorsichtig der Rollout ist:

• Ramp-Schritte, eine aufsteigende Liste wie 5, 25, 50 – jeder Schritt ist sein eigener Canary, genauso beobachtet, und das Abschließen des letzten befördert auf 100%. Lass es leer für einen einzigen Schritt, den du von Hand beförderst.
• Verweildauer pro Schritt, in Minuten – lass es leer und du beförderst jeden Schritt selbst; setze es, und Railyard geht automatisch weiter, sobald ein Schritt so lange gelaufen ist, ohne die nächste Einstellung auszulösen.
• Zurückrollen über einer 5xx-Rate (%) – der Teil, der daraus mehr als nur einen Traffic-Splitting-Schalter macht. Wenn die Fehlerrate eines Schritts diesen Schwellenwert überschreitet, rollt Railyard ihn eigenständig zurück. Niemand muss um 2 Uhr nachts ein Dashboard beobachten, damit das ein schlechtes Release abfängt.

Während er läuft, zeigt die Deploy-Seite die Anfragenzahl, die 5xx-Rate und die p95-Latenz des Canarys direkt neben denen des Rests der App – der tatsächliche Vergleich, der über eine Beförderung entscheidet, kein Bauchgefühl.

Was trotzdem als Standard-Deploy laufen muss

Ein paar Fälle überspringen Canary immer komplett, und sie vorher zu kennen vermeidet spätere Verwirrung: der allererste Deploy einer App, ein Deploy während des Wartungsmodus, eine reine Worker-App (nichts, auf das sich Traffic aufteilen ließe), und eine App mit einem Daten-Volume. Der Release-Befehl – typischerweise Migrationen – läuft trotzdem einmal, bevor der Canary startet, was bedeutet, dass Migrationen gleichzeitig gegen den alten und den neuen Code funktionieren müssen, für die gesamte Dauer des Canary-Laufs. Das ist keine Railyard-spezifische Einschränkung; es ist der tatsächliche Tradeoff, den jedes Canary-Deploy-System macht – hier klar ausgesprochen statt schöngeredet.

Kombiniert mit einem Deploy-Fenster

Canary beantwortet “wie schnell erreicht ein neues Release alle”. Eine separate, kombinierbare Einstellung – Deploy-Fenster – beantwortet “wann dürfen Deploys überhaupt passieren”:

railyard deploy-window my-app mon,tue,wed,thu,fri 09:00 17:00 America/Toronto

Pushes außerhalb des Fensters stellen sich in eine Warteschlange und gehen gemeinsam heraus, wenn es öffnet; ein manueller Deploy außerhalb fragt zuerst nach. Die beiden Features interagieren nicht über das hinaus – ein Canary, der mitten in der Rampe ist, wenn ein Fenster schließt, läuft genau wie konfiguriert weiter, weil das Hochfahren eines bereits gestarteten Canarys nicht dieselbe Aktion ist wie das Starten eines neuen Deploys.

Warum das wichtiger wird, sobald dir die Server gehören

Ein Canary mit automatischem Rollback ist einer der Punkte, an denen “self-hosted” durchaus “weniger Schutzmechanismen als eine verwaltete Plattform” bedeuten könnte – und das hier ist der Beweis, dass es nicht so sein muss. Der Mechanismus ist derselbe, egal wem die Maschine gehört: beobachte die echte Fehlerrate gegen einen echten Schwellenwert, keinen festen Timer, und lass das System sich selbst schützen, bevor ein Mensch eingreifen muss.

Vollständige Referenz, einschließlich geplanter Deploys und Deploy-Notizen: Canary-Deploys und Deploy-Fenster.