Feature Flag: Funktionsweise, Flag-Typen und Verwaltungsprinzipien
Feature Flag ist eine Entwicklungstechnik, bei der die Funktionalität einer Anwendung zur Laufzeit über bedingte Schalter aktiviert oder deaktiviert wird, ohne neuen Code bereitzustellen. Anstelle des traditionellen Ansatzes „commit — deploy“ ermöglichen Feature Flags, den Zeitpunkt der Bereitstellung vom Zeitpunkt der Funktionsaktivierung zu trennen. Laut LaunchDarkly (2024) reduzieren Teams, die Feature Flags verwenden, die Zeit für die Einführung neuer Funktionen um 40%. Feature Flags sind zu einem wesentlichen Element von CI/CD für moderne mobile und Web-Anwendungen geworden.
Wichtige Punkte
- Feature Flag — ein bedingter Schalter, der die Verfügbarkeit von Funktionalität zur Laufzeit steuert
- Vier Typen von Flags: Release-, Experiment-, Ops- und Permission-Toggles mit unterschiedlichen Zielen und Lebenszyklen
- Flag-Verwaltung erfordert ein Speichersystem, eine Konfigurations-UI und Nutzungsüberwachung
- Plattformen LaunchDarkly, Unleash und Split bieten SDKs für alle gängigen Sprachen und Plattformen
- Technische Schulden durch nicht entfernte Flags — das Hauptrisiko: veraltete Flags müssen regelmäßig überprüft und entfernt werden
Was ist ein Feature Flag
Feature Flag (Feature Toggle) ist ein Mechanismus, der es ermöglicht, das Verhalten einer Anwendung zu ändern, ohne den Code zu modifizieren. In seiner einfachsten Form ist es eine bedingte Anweisung, die den Wert des Flags überprüft, bevor neue Funktionalität ausgeführt wird. Das Flag kann in einer Konfigurationsdatei, Datenbank oder einem externen Dienst gespeichert und in Echtzeit geändert werden. Dieser Ansatz gibt Teams die Möglichkeit, unfertigen Code in den Hauptzweig zu committen, ohne befürchten zu müssen, dass er vor Abschluss der Entwicklung an die Benutzer gelangt.
Definition und Zweck
Der Hauptzweck von Feature Flags ist die Trennung von Bereitstellung und Veröffentlichung. Die Bereitstellung ist der Prozess des Platzierens von Code auf einem Server oder in einem App Store. Die Veröffentlichung ist der Moment, in dem die Funktionalität für den Benutzer verfügbar wird. Ohne Feature Flags fallen diese Ereignisse zusammen: Code geht in Produktion — Benutzer sehen ihn. Mit Feature Flags kann Code Wochen vor der Veröffentlichung in Produktion bereitgestellt, für interne Tests aktiviert oder schrittweise an das Publikum ausgerollt werden. Dies ist entscheidend für trunk-based Development und Continuous Delivery.
Einfaches Flag-Beispiel
Betrachten Sie eine grundlegende Feature-Flag-Implementierung in einer mobilen Kotlin-Anwendung. Das Flag wird in Firebase Remote Config gespeichert und beim Start der App geladen. Abhängig vom Wert des Flags wird der alte oder der neue Profilbildschirm angezeigt. Diese Implementierung ermöglicht die Veröffentlichung einer neuen Profilversion ohne Veröffentlichung eines App Store-Updates — ändern Sie einfach den Wert in der Firebase-Konsole.
kotlin
class ProfileFeature {
private val flags = FeatureFlagProvider()
private val profileFlag = FlagKey("new_profile_enabled")
fun getProfileScreen(): Screen {
return if (flags.isEnabled(profileFlag)) {
NewProfileScreen()
} else {
LegacyProfileScreen()
}
}
}
class FeatureFlagProvider {
fun isEnabled(key: FlagKey): Boolean {
val raw = Firebase.remoteConfig.getString(key.name)
return raw.toBoolean()
}
}Arten von Feature Flags
Nicht alle Feature Flags sind gleich. Martin Fowlers Klassifikation identifiziert vier Typen von Flags, die sich im Verwendungszweck, der Lebensdauer und den Verwaltungsanforderungen unterscheiden. Eine richtige Klassifikation der Flags hilft, die geeignete Infrastruktur auszuwählen und typische Probleme zu vermeiden.
Release Toggles
Release Toggles sind die häufigste Art von Flags. Sie werden verwendet, um unfertige Funktionalität in der Produktion zu verbergen. Der Entwickler committet Code, der in ein Flag gewickelt ist, in den Hauptzweig und vervollständigt die Funktionalität schrittweise. Nach Abschluss und Tests wird das Flag für alle Benutzer aktiviert. Der Lebenszyklus eines solchen Flags reicht von einigen Tagen bis zu zwei Wochen. Nach dem vollständigen Rollout wird das Flag aus dem Code entfernt. Release Toggles sind die Grundlage von trunk-based Development.
Experiment- und Ops-Toggles
Experiment Toggles arbeiten in Verbindung mit A/B-Tests. Sie schalten Funktionalität nicht einfach ein oder aus, sondern leiten den Benutzer in eine der experimentellen Gruppen. Solche Flags unterstützen oft komplexe Targeting-Regeln (nach Region, OS-Version, Abonnement) und die Integration mit Analysesystemen. Ops Toggles werden für die Betriebskontrolle verwendet — zum Beispiel zum Deaktivieren einer schweren Funktion unter hoher Last oder zum vorübergehenden Ausschalten eines problematischen Moduls ohne sofortige Bereitstellung. Ops Toggles müssen so schnell und zuverlässig wie möglich sein, da die Stabilität des Dienstes von ihnen abhängt.
| Typ | Dauer | Dynamik | Zweck |
|---|---|---|---|
| Release | Tage-Wochen | Statisch | Unfertigen Code verbergen |
| Experiment | Tage-Monate | Dynamisch | A/B-Tests und Rollout |
| Ops | Stunden-Tage | Dynamisch | Betriebskontrolle |
| Permission | Monate+ | Statisch | Zugriffskontrolle |
Verwaltung von Feature Flags
Die Verwaltung von Feature Flags ist eine eigene Disziplin, die Speicherung, Konfiguration, Überwachung und Prüfung von Flags umfasst. Ohne ein Verwaltungssystem werden Flags zu unkontrollierbaren technischen Schulden, die die Entwicklung verlangsamen. Betrachten wir die wichtigsten Aspekte der Verwaltung am Beispiel eines Produktionssystems.
Flag-Lebenszyklus
Jedes Feature Flag durchläuft vier Phasen: Erstellung, Nutzung, Stabilisierung und Entfernung. In der Erstellungsphase werden der Flag-Schlüssel, der Typ und der Standardwert definiert. Während der Nutzung überwacht das Team, wer das Flag für welche Zielgruppe und zu welchem Zweck aktiviert hat. Nach der Stabilisierung (Funktionalität ist vollständig bereit und getestet) muss das Flag aus dem Code entfernt werden. Der Entfernungsprozess wird durch Code-Review automatisiert: CI prüft, ob alle Flags, die für 100% der Benutzer aktiviert sind, eine Entfernungsaufgabe haben.
Zentrale Speicherung
Feature Flags sollten zentral gespeichert werden, nicht verteilt über Konfigurationsdateien jedes Dienstes. Ideal ist ein dedizierter Dienst mit UI (LaunchDarkly, Unleash). Eine minimal akzeptable Option ist eine JSON-Konfiguration im Repository mit Code-Review für Änderungen. Eine Datenbank zur Speicherung von Flags ist weniger bevorzugt, da sie eine separate Verwaltungsschnittstelle erfordert. Jedes Flag sollte einen Besitzer (Team oder bestimmten Entwickler), eine Beschreibung und eine Lebensdauer (TTL) haben. Die regelmäßige Prüfung veralteter Flags ist eine obligatorische Praxis, die durch eine CI-Aufgabe automatisiert wird, die Flags überprüft, die länger als N Tage unverändert sind.
Werkzeuge für Feature Flags
Der Markt für Feature-Flag-Verwaltungstools umfasst sowohl kommerzielle Plattformen mit vollständigem Verwaltungszyklus als auch Open-Source-Lösungen für die Selbstbereitstellung. Die Wahl des Tools hängt von der Teamgröße, den Latenzanforderungen und der Compliance ab.
Kommerzielle Plattformen
LaunchDarkly ist der Marktführer mit SDKs für alle gängigen Sprachen und Plattformen (iOS, Android, Web, Backend). Es unterstützt Multi-Umgebungen, regelbasiertes Targeting, A/B-Experimente und automatische Flag-Entfernung. Split ist eine Alternative mit Fokus auf Enterprise-Funktionen: rollenbasierter Zugriff, Audit-Logs und Compliance (SOC2, HIPAA). ConfigCat ist eine leichtere und erschwinglichere Lösung, die für kleine Teams geeignet ist. Alle Plattformen bieten SDKs mit Zwischenspeicherung von Werten und minimalen Auswirkungen auf die Anwendungslatenz.
Open-Source-Lösungen
Unleash ist die beliebteste Open-Source-Lösung mit UI, API und SDKs für alle wichtigen Plattformen. Es unterstützt Aktivierungsstrategien, benutzerdefinierte Kontexte und die Integration mit Prometheus zur Überwachung. Flagsmith ist eine Alternative mit integrierten A/B-Tests und Umgebungsverwaltung. Open-Source-Lösungen erfordern die Bereitstellung und Wartung der Infrastruktur, bieten aber die vollständige Kontrolle über die Daten und haben keine Lizenzbeschränkungen. Für mobile Anwendungen bieten beide Lösungen native SDKs mit离线-Flag-Wert-Zwischenspeicherung.
Bewährte Verfahren
Feature Flags sind ein mächtiges Werkzeug, aber ohne Disziplin erzeugen sie technische Schulden und verkomplizieren den Code. Martin Fowler und die Ingenieure von LaunchDarkly haben eine Reihe von Praktiken formuliert, die helfen, den größten Nutzen aus Feature Flags ohne negative Folgen zu ziehen. Betrachten wir die wichtigsten Empfehlungen für Produktionssysteme.
Vermeidung technischer Schulden
Jedes Feature Flag, das nach Abschluss des Rollouts nicht entfernt wurde, wird zu technischen Schulden. Eine Studie von LaunchDarkly (2024) zeigte, dass durchschnittlich 30–40% der Flags im Code verbleiben, nachdem sie nicht mehr benötigt werden. Lösung: Führen Sie die Regel „Ein Flag — eine Aufgabe“ ein. Beim Erstellen eines Flags wird im Task-Tracker eine Entfernungsaufgabe mit einer Frist erstellt. CI prüft, ob es keine Flags gibt, die länger als 30 Tage zu 100% aktiviert sind. Code-Reviews sollten nicht nur das Hinzufügen, sondern auch das Entfernen von Flags überprüfen.
Testen mit Flags
Feature Flags erzeugen kombinatorische Komplexität für Tests: Jedes Flag verdoppelt die Anzahl der möglichen Anwendungszustände. Zur Verwaltung dieser Komplexität werden Matrixtests, die alle Flag-Kombinationen überprüfen, und Integrationstests zum Umschalten von Flags verwendet. Dem CI-Pipeline wird ein Schritt hinzugefügt, der Tests mit verschiedenen Kombinationen von Flag-Werten ausführt. Für kritische Flags (Ops Toggles) sind Auslastungstests obligatorisch, um zu überprüfen, dass das Umschalten des Flags keine Latenzspitzen oder Fehler verursacht.
python
class FeatureFlagService:
def __init__(self, storage):
self.storage = storage
def is_enabled(self, flag_key, user_context):
flag = self.storage.get(flag_key)
if not flag:
return False
for rule in flag["rules"]:
if self._match_rule(rule, user_context):
return rule["value"]
return flag["default"]
def _match_rule(self, rule, context):
return (
rule["percentage"] > self._hash(context.user_id)
)Häufig gestellte Fragen
Was ist der Unterschied zwischen Feature Flag und Feature Toggle?
Die Begriffe werden oft synonym verwendet, aber es gibt eine Nuance: Feature Flag bezeichnet in der Regel ein ausgereifteres System mit zentraler Verwaltung, UI und SDKs, während Feature Toggle ein einfacher binärer Schalter im Code ist. Martin Fowler verwendet Feature Toggle als allgemeinen Begriff, aber in der Industrie wird Feature Flag häufiger mit kommerziellen Plattformen (LaunchDarkly, Split) assoziiert.
Wie wirken sich Feature Flags auf die Leistung aus?
Die Auswirkung auf die Leistung ist bei richtiger Implementierung minimal. Bewährte Verfahren: Flag-Werte mit einer TTL von 30–60 Sekunden im Arbeitsspeicher zwischenspeichern, synchrone HTTP-Aufrufe bei der Überprüfung eines Flags vermeiden, SDKs mit lokalem Cache und Hintergrundsynchronisierung verwenden. Laut LaunchDarkly beträgt die p99-Latenz ihres SDK weniger als 5 ms, was für die meisten Anwendungen vernachlässigbar ist.
Wann sollte man keine Feature Flags verwenden?
Feature Flags werden nicht empfohlen, um Geschäftslogik in kritischen Finanzoperationen zu ändern, bei denen es wichtig ist, genau zu wissen, welcher Code ausgeführt wird. Vermeiden Sie auch Flags für Sicherheitsfunktionen (Autorisierung, Verschlüsselung) — das Deaktivieren eines solchen Flags erzeugt eine Sicherheitslücke. Für Infrastrukturänderungen (Datenbankmigration, Migration auf eine neue Architektur) sind Feature Flags nützlich, erfordern aber besonders gründliche Tests.
Wie testet man Code mit Feature Flags?
Der Hauptansatz ist das Matrixtesten: Ausführen von Tests mit allen Flag-Kombinationen. Für CI/CD kann dies zu teuer sein (2^n Kombinationen), daher werden in der Praxis alle Flags einzeln in beiden Zuständen (an/aus) getestet und nur kritische Kombinationen getestet. Unit-Tests sollten den Flag-Wert mocken. Integrationstests überprüfen spezifische Szenarien mit bekannten Flag-Werten. E2E-Tests decken die wahrscheinlichsten Kombinationen ab.
Wie entfernt man alte Feature Flags?
Der Entfernungsprozess: 1) Stellen Sie sicher, dass das Flag zu 100% für alle Benutzer aktiviert ist und nicht im Experiment-Modus verwendet wird; 2) Entfernen Sie alle bedingten Prüfungen des Flags aus dem Code und behalten Sie nur den „neuen“ Zweig; 3) Entfernen Sie die Flag-Definition aus dem Verwaltungssystem; 4) Aktualisieren Sie die Tests, indem Sie Mocks für das entfernte Flag entfernen. Es wird empfohlen, diesen Prozess durch CI zu automatisieren: Flags, die länger als N Tage unverändert sind, werden als veraltet markiert und erfordern eine Bestätigung zur Entfernung.
Zusammenfassung
- Feature Flag — ein bedingter Schalter, der den Zeitpunkt der Bereitstellung vom Zeitpunkt der Funktionsfreigabe trennt
- Vier Typen von Flags (Release, Experiment, Ops, Permission) haben unterschiedliche Zwecke, Lebensdauern und Anforderungen
- Flag-Verwaltung erfordert zentrale Speicherung, Konfigurations-UI und regelmäßige Überprüfung veralteter Flags
- Werkzeuge: LaunchDarkly und Split für Unternehmen, Unleash und Flagsmith für Open-Source-Projekte
- Technische Schulden durch nicht entfernte Flags sind das Hauptrisiko; Entfernungsaufgaben sind bei der Erstellung jedes Flags obligatorisch
- Testen mit Flags erfordert einen Matrix-Ansatz und das Mocken von Flag-Werten in Unit-Tests
- Leistung wird bei Verwendung von Caching und lokalen SDKs minimal beeinträchtigt
Wir entwickeln eine mobile Applikation schlüsselfertig
IT Sectr entwickelt seit 2017 iOS- und Android-Apps für Startups und Unternehmen. Wir beraten Sie und schlagen die beste Lösung vor.
Lesen Sie auch