Feature-Flag-Management

Feature-Flags dienen fünf verschiedenen operativen Anwendungsfällen, oft gleichzeitig. (1) Gestaffelter Rollout: Eine Funktion am ersten Tag für 5 % der Benutzer freigeben und in der folgenden Woche auf 25 %, 50 % und 100 % erweitern. Dies wandelt jede Bereitstellung von einem Alles-oder-Nichts-Risiko in eine gemessene, beobachtbare Expansion um. (2) A/B-Testing: Benutzer deterministisch (derselbe Benutzer sieht immer dieselbe Variante) zu einer von zwei Varianten leiten, um einen statistischen Vergleich zu ermöglichen. (3) Beta-Programme: Eine Funktion nur für Konten aktivieren, die explizit für die Beta angemeldet sind, ohne eine separate Beta-Umgebung bereitzustellen. (4) Kill Switch: Eine problematische Funktion in der Produktion sofort deaktivieren, ohne einen Code-Rollback – das schnellste verfügbare Tool zur Incident Response. (5) Ops Feature Gates: Nicht-kritische Funktionen während eines Incidents deaktivieren, um die Systemlast zu reduzieren (z. B. teure Analyseabfragen während einer Leistungsbeeinträchtigung deaktivieren). Die Disziplin des Feature-Flag-Managements – Namenskonventionen, Lifecycle-Richtlinien und Bereinigung – liegt bei Product Ops in Zusammenarbeit mit dem Engineering.

Spezialisierte Feature-Flag-Plattformen bieten kritische Funktionen, die über einfache if/else-Codeblöcke hinausgehen: Targeting-Regeln (Aktivierung für bestimmte Konten, Benutzerattribute oder einen Prozentsatz des Traffics), Analyseintegration (Messung von Metrikunterschieden zwischen Kohorten), schrittweise Rollout-Kontrollen und Audit-Logs. Führende Plattformen: LaunchDarkly (Enterprise-Standard, reichhaltigste Targeting-Funktionen, integrierte Experimente); Statsig (kombiniert Feature-Flags mit Experimenten und Produktanalysen, beliebt bei Scale-up-SaaS); Split.io (hochentwickelte Experimentierplattform mit tiefer Analyseintegration); Unleash (Open-Source, selbst gehostete Option für Unternehmen mit starken Anforderungen an die Datenhoheit); GrowthBook (Open-Source, experimentierfokussiert). Für sehr frühe Teams kann eine einfache datenbankgestützte Flag-Tabelle, die über ein Admin-Panel verwaltet wird, ausreichen – aber die Investition in eine Plattform zahlt sich aus, wenn das Team 10+ gleichzeitige Flags benötigt, die Targeting und Analysen erfordern.

Technische Schulden bei Feature-Flags sind eine der häufigsten und am wenigsten sichtbaren Formen technischer Schulden. Jedes Flag fügt einen bedingten Codepfad hinzu, der mit zunehmender Anzahl von Flags schwerer zu verstehen wird – eine Codebasis mit 200 aktiven Flags hat theoretisch 2^200 mögliche Zustände, was das Testen und Debuggen exponentiell komplex macht. Prävention erfordert eine Flag-Lifecycle-Richtlinie: Jedes Flag wird mit einem Ablaufdatum erstellt (dem Zieldatum, bis zu dem es entfernt wird); Flags, die vollständig ausgerollt wurden (100 % der Benutzer, keine weiteren A/B-Tests), werden innerhalb eines Sprints zur Bereinigung markiert; Flags, die mit Funktionen verbunden sind, die eingestellt wurden, werden sofort entfernt. Product Ops pflegt das Feature Flag Registry – eine zentralisierte Aufzeichnung aller aktiven Flags, ihres Besitzers, Zwecks, aktuellen Rollout-Prozentsatzes und Ablaufdatums. Eine monatliche Flag Cleanup Sprint-Aufgabe stellt sicher, dass das Register aktuell ist und Flags, deren Ablaufdatum überschritten ist, zur sofortigen Entfernung eskaliert werden. „Dead Flag“-PRs, die Flag-Code nach vollständigem Rollout entfernen, werden gefeiert – sie reduzieren die Komplexität, ohne neue Fehler hinzuzufügen.