Was ist ein Feature-Rollout?

Was ist ein Feature-Rollout?

Ein Feature-Rollout bedeutet, ein neues Feature in Stufen statt für alle Nutzer auf einmal freizugeben. Sie beginnen mit Mitarbeitenden oder einem kleinen Teil des Traffics, beobachten Fehlerraten, Latenz und Geschäftskennzahlen und erweitern den Kreis nur, solange diese stabil bleiben. So werden Deployment und Release getrennt: Ein Problem trifft 1 % der Nutzer statt 100 %, und die Lösung ist oft ein Schalter statt eines neuen Deployments.

Gängige Rollout-Strategien

• Prozentualer Rollout: Das Feature wird für 1 %, dann 10 %, 25 %, 50 % und 100 % der Nutzer aktiviert, mit einer Pause pro Stufe. Meist über Feature Flags umgesetzt.
• Canary Release: Ein kleiner Teil des Traffics geht an die neue Version, die neben der alten läuft. Martin Fowler beschreibt den Rollback schlicht als Umleiten der Nutzer zurück auf die alte Version. Siehe den Leitfaden zum Canary Deployment (auf Englisch).
• Ring-Deployment: Die Freigabe erfolgt in Ringen nacheinander, etwa interne Mitarbeitende, dann Beta-Nutzer, dann alle.
• Blue/Green-Deployment: Zwei Umgebungen laufen parallel, der gesamte Traffic wird von einer auf die andere umgeschaltet. Das ist nicht schrittweise, bietet aber einen schnellen Rückweg. Schwierig sind Datenbank-Schemaänderungen: Liefern Sie sie getrennt aus und halten Sie sie mit beiden Versionen kompatibel.
• Dark Launch: Der neue Code läuft in Produktion, sein Ergebnis bleibt für Nutzer unsichtbar. So beobachten Sie Last und Verhalten, bevor jemand das Feature sieht.
• A/B-Test: Zwei Varianten laufen parallel, um die Wirkung auf eine Kennzahl zu messen. Er beantwortet "welche ist besser", nicht "ist es sicher".

Ein Beispiel Schritt für Schritt

1. Der neue Checkout wird hinter einem Flag gemergt, das für alle ausgeschaltet ist.
2. Schalten Sie es für das eigene Team ein und beobachten Sie einen Tag lang.
3. Erhöhen Sie auf 5 % der Nutzer. Vergleichen Sie Fehlerrate, Checkout-Abschlüsse und p95-Antwortzeit zwischen beiden Gruppen.
4. Halten die Werte, geht es weiter auf 25 %, 50 % und 100 %, mit einer Wartezeit pro Stufe, die dazu passt, wie schnell Probleme sichtbar würden.
5. Steigen Fehler oder Latenz in einer Stufe sprunghaft, setzen Sie das Flag auf 0 % zurück und suchen die Ursache.
6. Nach einer stabilen Phase bei 100 % entfernen Sie Flag und alten Codepfad.

Häufige Rollout-Fehler

• Keine Erfolgskriterien. Legen Sie vorab fest, welche Kennzahlen in welchen Grenzen bleiben müssen und wer sie beobachtet.
• Rollout nach Zeitplan. Ein Plan ohne Monitoring verlangsamt den Fehler nur.
• Nutzer wechseln zwischen alt und neu. Nutzen Sie Sticky Bucketing, damit ein Nutzer über Sitzungen hinweg dieselbe Variante behält.
• Ein Rollback, der gar nicht möglich ist. Eine Datenmigration, die hinter dem Flag lief, lässt sich eventuell nicht umkehren. Planen Sie den Datenpfad vor dem Codepfad.
• Liegengebliebene Flags. Jedes Flag braucht einen Verantwortlichen und ein Entfernungsdatum.
• Ungetesteter Aus-Zustand. Ist der alte Pfad defekt, rettet Sie das Zurückschalten nicht.

Feature-Rollouts, Lasttests und Monitoring

Ein Rollout prüft eine Änderung an echten Nutzern, doch es sollte nicht das erste Mal sein, dass der neue Pfad echtem Traffic-Volumen begegnet. Führen Sie vor der ersten Prozentstufe einen Lasttest für den neuen Codepfad durch. LoadFocus führt JMeter- und k6-Tests aus 25 Cloud-Regionen aus, der Free-Plan enthält bis zu 10 virtuelle Nutzer. Während des Rollouts prüft API-Monitoring Statuscode, Body und Antwortzeit planmäßig weiter (im Free-Plan alle 5 Minuten), sodass eine Regression auffällt, solange ein Rollback noch günstig ist. Siehe LoadFocus API-Monitoring.

Häufige Fragen: Feature-Rollouts

Was ist der Unterschied zwischen Feature-Rollout und Feature Flag?

Der Rollout ist der Prozess der stufenweisen Freigabe. Ein Feature Flag ist ein gängiges Werkzeug dafür, weil Sie damit ändern können, wer ein Feature sieht, ohne Code auszuliefern. Sie können auch ohne Flags per Canary-Routing oder Ring-Deployment ausrollen.

Was ist der Unterschied zwischen Canary und Blue/Green?

Ein Canary Release verschiebt Nutzer schrittweise auf die neue Version. Blue/Green hält zwei vollständige Umgebungen vor und schaltet den gesamten Traffic auf einmal um, die alte Umgebung dient als schneller Rollback.

Wie lange sollte ein Rollout dauern?

Das hängt von Risiko und Traffic ab. Pro Stufe brauchen Sie genug Traffic, um ein Problem zu sehen, daher brauchen Features mit wenig Traffic längere Stufen. Riskante Änderungen wie Zahlungen oder Datenmigrationen verdienen kleinere Schritte und längere Wartezeiten.

Was sollte ich während eines Rollouts überwachen?

Fehlerrate, Latenz-Perzentile und ein bis zwei Geschäftskennzahlen, verglichen zwischen neuer und alter Variante statt nur insgesamt. Alarme sollten vor der ersten Stufe eingerichtet sein.

Sollte jedes Feature schrittweise ausgerollt werden?

Nein. Textänderungen und risikoarme Fixes können direkt live gehen. Nutzen Sie gestufte Rollouts für Änderungen an Zahlungen, Daten, Authentifizierung oder stark belasteten Pfaden.