Was sind Feature Flags? Definition, Einsatzfälle, Fallstricke

Was sind Feature Flags?

Ein Feature Flag (auch Feature Toggle, Feature Gate oder Release Toggle) ist eine Bedingung im Code, die ein Verhalten zur Laufzeit ein- oder ausschaltet, ohne neues Deployment. Der Wert stammt aus einem Flag-Dienst oder Konfigurationsspeicher und kann pro Nutzer, Traffic-Anteil oder Kohorte unterschiedlich sein. Die Kernidee: Deployment und Release werden zwei getrennte Schritte. Der Code geht unsichtbar hinter einem Flag live und wird dann schrittweise aktiviert.

if (flags.isEnabled("new-checkout", user)) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

Die vier typischen Einsatzfälle

Release-Toggles

Der Code wird ausgeschaltet ausgeliefert und dann für Mitarbeitende, eine Beta-Gruppe, 1 % des Traffics, 10 % und schließlich alle aktiviert. Steigen Fehler oder Latenz in einer Stufe, schalten Sie das Flag zurück, statt ein Release zurückzurollen. Das ist die Flag-Variante des Feature Rollouts und passt gut zu einem Canary Deployment (Artikel auf Englisch).

Experiment-Toggles

Die eine Hälfte der Nutzer sieht Variante A, die andere Variante B. Sie erfassen, wer was gesehen hat, und vergleichen die Kennzahlen, auf die es ankommt.

Berechtigungs-Toggles

Ein Feature wird nur bestimmten Tarifen, Organisationen oder Rollen angezeigt. Für einfache Tarifsteuerung ist das in Ordnung; für komplexe Rechtemodelle gehört ein eigenes Autorisierungssystem her.

Kill Switches

Riskante oder teure Pfade, etwa ein Drittanbieter-Aufruf oder ein aufwendiger Empfehlungsschritt, werden gekapselt. So lassen sie sich bei einem Vorfall abschalten und durch etwas Einfacheres ersetzen.

So funktioniert ein Flag-System

• Zentrale Definitionen. Ein Dashboard oder eine API hält jedes Flag samt Targeting-Regeln.
• Ein SDK in Ihrer Anwendung. Es holt Flag-Werte beim Start oder pro Request und hält sie in einem lokalen Cache, sodass eine Abfrage kaum etwas kostet.
• Aktualisierungen. Änderungen erreichen laufende Anwendungen je nach Tool per Polling oder per Push-Stream.
• Ein Audit-Trail. Gute Tools protokollieren, wer welches Flag wann geändert hat und welche Variante jeder Request bekam.

Sie können das bei einem Anbieter kaufen, ein Open-Source-Tool nutzen oder einen kleinen eigenen Dienst bauen. Die Wahl hängt von Targeting-Anforderungen, Datenresidenz und dem Wartungsaufwand ab, den Ihr Team tragen will.

Häufige Fallstricke

• Flags, die nie entfernt werden. Jedes Flag braucht einen Verantwortlichen und ein Ablaufdatum; den toten Codepfad zu entfernen gehört zum Abschluss des Features.
• Versteckte Abhängigkeiten zwischen Flags. Flag A funktioniert nur, wenn Flag B an ist. Dokumentieren Sie das oder bilden Sie es als Voraussetzung ab.
• Zu viele Kombinationen zum Testen. Zehn unabhängige boolesche Flags ergeben 1.024 Kombinationen. Testen Sie je Flag An und Aus sowie die Kombinationen, die in Produktion wirklich vorkommen.
• Der Flag-Dienst als Single Point of Failure. Ihre Anwendung muss mit gecachten oder Standardwerten weiterlaufen, wenn der Dienst nicht erreichbar ist. Testen Sie das durch Blockieren, nehmen Sie es nicht einfach an.
• Langsamer erster Abruf. Werten Sie Flags aus einem lokalen Cache aus, nicht mit einem Netzwerkaufruf pro Request.
• Flags mit Konfiguration vermischt. Feature Flags tragen Produkt- und Release-Entscheidungen und ändern sich zur Laufzeit. Konfiguration (Timeouts, Verbindungsstrings) und Umgebungsvariablen sind Betriebseinstellungen, die sich meist nur mit Deployment oder Neustart ändern.

Feature Flags, Lasttests und Monitoring

Ein Flag-Wechsel ändert, welcher Code läuft, und damit auch die Last: Ein neuer Codepfad kann eine Datenbank oder einen Endpoint ganz anders ansprechen als der alte. Führen Sie einen Lasttest gegen den neuen Pfad aus, bevor Sie den Prozentsatz erhöhen; LoadFocus führt JMeter- und k6-Tests aus 25 Cloud-Regionen aus, der kostenlose Tarif umfasst bis zu 10 virtuelle Nutzer. Während des Rollouts prüft API-Monitoring Statuscode, Body und Antwortzeit nach Zeitplan (im kostenlosen Tarif alle 5 Minuten), sodass eine Regression auffällt, solange Sie das Flag noch zurückschalten können. Beobachten Sie die Latenz je Variante, nicht nur insgesamt.

Häufige Fragen zu Feature Flags

Sind Feature Flags für kleine Teams übertrieben?

Meist nicht. Schon ein Ein-Personen-Team profitiert von einem Kill Switch und davon, ein Feature zuerst nur für sich selbst zu aktivieren. Ein einfaches, konfigurationsbasiertes Flag reicht für den Anfang; einen vollständigen Flag-Dienst brauchen Sie bei Targeting und Audit-Trail.

Was ist der Unterschied zwischen Feature Flags und Trunk-Based Development?

Sie ergänzen sich. Bei Trunk-Based Development landen kleine Änderungen laufend im Hauptzweig; Feature Flags erlauben es, dass unfertige Arbeit dort liegt, ohne dass Nutzer sie sehen.

Wie wirken sich Feature Flags auf das Testen aus?

Testen Sie Ein- und Aus-Pfad jedes Flags und die Kombinationen, die in Produktion vorkommen. Machen Sie den Flag-Zustand zu einer expliziten Eingabe der Tests, damit die Ergebnisse reproduzierbar sind.

Können Feature Flags meine Anwendung ausbremsen?

Nur bei schlechter Umsetzung, etwa mit einem Netzwerkaufruf bei jedem Request. Werten Sie aus einem Cache im Arbeitsspeicher aus, der im Hintergrund aktualisiert wird, und greifen Sie bei Ausfall des Dienstes auf einen sicheren Standardwert zurück.

Sollte ich Feature Flags für Berechtigungen nutzen?

Für einfachen tarifbasierten Zugriff ja. Für feingranulare Zugriffskontrolle mit Audit-Anforderungen nutzen Sie ein eigenes Autorisierungssystem und lassen Flags für Rollout-Entscheidungen.

Sollte ich den Flag-Zustand an Analytics senden?

Ja. Hängen Sie das aktive Flag oder die Variante an Ihre Events, damit Sie Kennzahlen je Variante vergleichen und einen Flag-Effekt von Rauschen unterscheiden können.