Was ist ein Feature Flag: Verwaltung und Best Practice

Ein Feature Flag ist eine bedingte Anweisung in Ihrem Code, die zur Laufzeit entscheidet, ob ein bestimmtes Verhalten aktiviert oder deaktiviert ist – ohne dass eine neue Version deployt werden muss. Das ist die ganze Idee. Was ist ein Feature Flag in der Praxis? Eine if-Anweisung, deren Antwort aus einer Konfiguration, einer Datenbankzeile oder einem Flag-Service kommt statt hardcodiert zu sein.

Das Konzept ist einfach. Mit 200 solcher Flags in einem Repository zu leben ist das nicht, und genau dieser zweite Teil ist das Thema dieses Leitfadens.

Wie sieht ein Feature Flag im Code aus?

Hier ist die kleinste nützliche Version:

```ts if (flags.isEnabled("new-checkout", { userId })) { return renderNewCheckout(); } return renderOldCheckout(); ```

Beide Codepfade werden im gleichen Build ausgeliefert. Der Flag-Wert lebt an einem Ort, den Sie ändern können, ohne neu zu deployen: eine Umgebungsvariable, eine JSON-Datei, eine Tabelle oder ein gehosteter Service. Ändern Sie den Wert, und das Verhalten ändert sich bei der nächsten Auswertung.

Diese Trennung ist der Kern der Sache. Deployment bedeutet, Code auf Server zu bringen. Release bedeutet, dass Benutzer ihn sehen. Flags trennen diese beiden Ereignisse, sodass das Mergen in main nicht länger bedeutet: "Das bekommt jetzt jeder."

Warum verwenden Teams Feature Flags überhaupt?

Drei Gründe tauchen immer wieder in echten Teams mit 5 bis 50 Ingenieuren auf.

• Unfertige Arbeit sicher mergen. Sie committen die halb gebaute Funktion hinter einem ausgeschalteten Flag, und Ihr Branch lebt keine drei Wochen. Das macht Trunk-based Development überhaupt machbar.

• Schrittweise ausrollen. Schalten Sie eine Änderung für interne Benutzer an, dann 5% des Verkehrs, dann für alle. Wenn die Fehlerquote steigt, können Sie es in Sekunden wieder ausschalten.

• Schnell etwas beenden. Wenn ein Zahlungsanbieter um 2 Uhr nachts spinnt, können Sie mit einem Flag ein Feature degradieren, statt ein ganzes Release zurückzurollen.

Keines dieser Szenarien erfordert einen Vendor. Ein Flag kann ein Boolean in einer Konfigurationstabelle sein. Überspringen Sie die Plattform, bis Sie prozentuale Rollouts, Audit-Trails oder Nicht-Ingenieure benötigen, die Dinge umschalten.

Was sind die vier Arten von Feature Flags?

Pete Hodgsons vielzitierte Feature Toggles in martinfowler.com/articles/feature-toggles.html ordnet Flags danach, wie lange sie leben und wie oft die Entscheidung sich ändert. Die Kategorien sind immer noch das klarste mentale Modell.

• Release: lebt Tage bis Wochen, wird von Ingenieuren umgeschaltet. Beispiel: ein unfertiges Checkout-Redesign verstecken.

• Experiment: lebt Wochen, wird von Product und Data umgeschaltet. Beispiel: ein A/B-Test zweier Pricing-Seiten.

• Ops: lebt Stunden bis ewig, wird vom On-Call-Team umgeschaltet. Beispiel: ein Kill-Switch für einen langsamen Empfehlungsservice.

• Permission: lebt Monate bis Jahre, wird von Product und Support umgeschaltet. Beispiel: Beta-Zugang oder Premium-Only-Features.

Die Lebensdauer ist am wichtigsten. Ein Release-Flag, das sein Release überlebt, ist ein Bug, den Sie noch nicht gefunden haben. Ein Permission-Flag, das in einem Cleanup-Sprint gelöscht wird, ist ein Ausfall, den Sie noch nicht hatten.

Benennen und beschriften Sie den Typ, wenn Sie das Flag erstellen. Sechs Monate später erinnert sich niemand, in welche Kategorie "new-nav-v2" gehörte.

Wie rollen Sie einen Flag aus, ohne Benutzer zu verletzen?

Die langweilige Abfolge funktioniert am besten.

1. Pushen Sie den Code mit dem Flag aus. Vergewissern Sie sich, dass sich nichts geändert hat.

2. Aktivieren Sie ihn für Ihr eigenes Team in der Produktion. Nutzen Sie ihn einen Tag lang.

3. Aktivieren Sie ihn für 1–5% der Benutzer, sortiert nach Benutzer-ID, damit niemand während einer Sitzung zwischen Varianten hin- und herwechselt.

4. Beobachten Sie Fehlerquote, Latenz und eine Geschäftsmetrik. Entscheiden Sie die Schwelle, bevor Sie anfangen, nicht während Sie auf ein Dashboard starren.

5. Fahren Sie auf 100% hoch, warten Sie eine definierte Frist, dann entfernen Sie das Flag.

Schritt fünf ist derjenige, den Teams überspringen. Wir werden später sehen, warum das mehr kostet, als Sie denken.

Ein praktischer Hinweis zur Auswertung: machen Sie Flag-Reads günstig und ausfallsicher. Wenn der Flag-Service ausfällt, braucht Ihr Code einen Standard. Wählen Sie den Standard pro Flag bewusst. Ein Kill-Switch sollte auf "Sicherheit" ausfallen, während ein neues Feature auf "aus" ausfallen sollte.

Warum werden Feature Flags zu technischer Schuld?

Jedes Flag ist eine Verzweigung in Ihrem Code. Zwei Flags ergeben vier mögliche Pfade, zehn Flags ergeben 1024, und Sie haben wahrscheinlich nur eine Handvoll davon getestet. GrowthBooks Leitfaden zu Flag-Schuld zitiert Forschung, die zeigt, dass etwa 75% der Toggle-Komponenten auch 49 Wochen nach ihrer Einführung noch in Codebases vorhanden waren, obwohl die meisten Entwickler sagten, sie planten, sie zu entfernen.

Hodgson sagt es gut im gleichen Fowler-Artikel: kluge Teams behandeln Toggles als Bestand mit Haltekosten und arbeiten daran, diesen Bestand niedrig zu halten.

Die klassische Horror-Story ist Knight Capital 2012. Ein veraltetes Flag eines Features wurde wiederverwendet für neues Verhalten, während alter Code immer noch auf einem Server saß. Diese Diskrepanz trug zu ungefähr 460 Millionen Dollar Verlust in unter einer Stunde bei. Ihr altes Flag wird das wahrscheinlich nicht tun. Es wird etwas Leisereres tun: ein Refactor, der einen Branch bricht, von dem niemand wusste, dass er existiert, oder ein neuer Mitarbeiter verbringt einen Nachmittag damit zu herausfinden, welcher von zwei Checkout-Pfaden real ist.

Wie finden Sie jedes Flag in einem bestehenden Codebase?

Das ist die Frage, die die Vendor-Dokumentation überspringt, und hier bleiben die meisten Teams stecken. Das Flag-Dashboard zeigt Ihnen, was konfiguriert ist. Es zeigt Ihnen nicht, wo jedes Flag im Code gelesen wird, oder ob der Codepfad hinter einem "aus"-Flag noch erreichbar ist.

Beginnen Sie mit dem günstigen Ansatz:

```bash

alle literalen Flag-Keys, die über Ihren Wrapper gelesen werden

rg -n 'isEnabled("' src/ | sort

Flags definiert, aber nie referenziert

comm -23 <(jq -r 'keys[]' flags.json | sort)
<(rg -o 'isEnabled("([^"]+)"' -r '$1' src/ | sort -u) ```

Das bricht schnell zusammen. Flag-Keys, die aus String-Verkettung gebaut werden, tauchen nicht in grep auf. Flags, die durch Hilfsfunktionen weitergegeben werden, verstecken ihre Aufrufstellen. Monorepos und Multi-Repo-Setups vervielfachen das Problem, weil der gleiche Key von drei Services gelesen werden kann.

Hier hilft das Lesen des Codes mit Werkzeugen. Code-Such-Tools, die Ihr Repo verstehen, können auf die Frage "Wo wird new-checkout ausgewertet, und was hängt vom Ergebnis ab?" in einer Abfrage statt einem Nachmittag grep antworten. Cursor und GitHub Copilot handhaben das innerhalb eines Repos angemessen. Über mehrere Repos hinweg brauchen Sie einen Index, der alle abdeckt – das ist der Fall, für den wir codebasechat gebaut haben.

Wie sieht ein vernünftiger Flag-Bereinigungsprozess aus?

Behandeln Sie die Entfernung als Teil der Arbeit, nicht als spätere Aufgabe.

• Erstellen Sie das Entfernungs-Ticket mit dem Flag. Verlinken Sie es in der Flag-Beschreibung. Wenn das Ticket nicht existiert, wird das Flag nicht ausgeliefert.

• Legen Sie einen Eigentümer und ein Ablaufdatum auf jedem nicht-permanenten Flag fest. Etwa 90 Tage ohne Änderung ist ein angemessener Trigger zur Überprüfung.

• Entfernen Sie in zwei Pull Requests. Löschen Sie zunächst die Flag-Prüfung und behalten Sie den gewinnenden Pfad. Löschen Sie dann den toten Branch und seine Tests. Kleine Diffs sind überprüfbare Diffs.

• Fügen Sie einen Time-Bomb-Test hinzu. Ein Test, der fehlschlägt, wenn ein Release-Flag sein Ablaufdatum überschreitet, verwandelt eine gute Absicht in einen roten Build.

• Setzen Sie eine Obergrenze. Wenn Sie 40 aktive Flags haben und das Limit 40 ist, bedeutet das Hinzufügen von eins, dass Sie eins entfernen müssen.

Statische Analyse hilft auch hier. Ein Tool wie CodeScene kann zeigen, welche Dateien die verwickeltste bedingte Logik tragen – meist dort, wo alte Flags klumpen. SonarQube kennzeichnet unerreichbaren und toten Code, nachdem Sie eine Prüfung entfernen.

Wie testen Sie Code, der hinter einem Flag sitzt?

Das Testen ist der Teil, für den niemand budgetiert. Mit zwei Pfaden pro Flag muss Ihre Test-Suite beide abdecken, zumindest für die Flags, die riskantes Verhalten schützen.

Halten Sie es praktisch. Testen Sie die an- und ausgeschalteten Zustände jedes Release-Flags in Unit-Tests, indem Sie den Flag-Wert injizieren, anstatt einen Live-Service zu lesen. Führen Sie eine End-to-End-Suite gegen die Standard-Produktionskonfiguration aus, weil das ist, was Benutzer heute bekommen. Führen Sie dann einen zweiten Durchlauf mit dem Flag an für das Feature, das Sie ausrollen wollen.

Versuchen Sie nicht, jede Kombination zu testen. Mit zehn Flags können Sie das nicht. Halten Sie stattdessen Flags unabhängig: ein Flag, das Verhalten nur ändert, wenn auch ein anderes Flag an ist, ist ein Design-Problem, und es ist das Erste, das Sie entwirren müssen.

Was machen neue Ingenieure falsch mit Flags?

Anfänger neigen dazu, die gleichen drei Fehler zu machen, und jeder ist günstig zu verhindern in der Review.

• Flags verschachteln. Ein Flag im anderen schafft einen Pfad, der nur existiert, wenn beide an sind. Fragen Sie stattdessen nach einem einzigen Flag mit einem klaren Namen.

• Logik in den Flag-Namen stecken. Ein Key wie "show-new-nav-to-premium-users-in-eu" codiert eine Targeting-Regel, die in den Flag-Service gehört, nicht in einen String.

• Den Standard vergessen. Wenn das Flag-Lookup fehlschlägt, was passiert? Lassen Sie den Autor die Antwort in der Pull-Request-Beschreibung schreiben.

Die erste Woche nach Einstellung eines neuen Mitarbeiters ist genau der Moment, in dem sie auf alte Flags ohne Eigentümer stoßen. Ein kurzes Flag-Register mit einem Typ, einem Eigentümer und einem Ablaufdatum für jeden Eintrag spart mehrere Stunden Fragen.

Wann sollten Sie Feature Flags überspringen?

Flags sind nicht kostenlos, daher überspringen Sie sie, wenn:

• Die Änderung ist klein, reversibel und ein Deploy weg von einem Rollback. Ein Flag fügt einen Codepfad ohne Gewinn hinzu.

• Die Änderung berührt ein Datenbankschema auf eine Weise, die ein Flag nicht verbergen kann. Nutzen Sie stattdessen Expand-and-Contract-Migrationen.

• Ihr Team hat keinen Prozess zum Entfernen von Flags. Beheben Sie das zuerst, sonst leihen Sie gegen zukünftige Lesbarkeit.

Und nutzen Sie sie ohne Zögern, wenn eine Änderung riskant, benutzergewandt und schwer zu reversialisieren ist durch neu deployen. Payment-Flows, Auth-Änderungen und alles mit einer Datenmigration dahinter qualifizieren sich alle.

Was würden wir auf einem Team mit zehn Personen wirklich tun

Beginnen Sie mit einem Boolean in der Konfiguration und einer Wrapper-Funktion, sodass jedes Flag-Read durch einen Ort geht. Dieser einzelne Engpass macht die Flag-Liste grep-bar, auditable und leicht zu migrieren zu einem gehosteten Service später.

Beschriften Sie jedes Flag nach Typ, geben Sie ihm einen Eigentümer und datieren Sie das Entfernungs-Ticket auf Tag eins. Überprüfen Sie die Liste monatlich für zehn Minuten. Löschen Sie die Flags, die die letzten zwei Wochen bei 100% sind.

Ein Feature Flag ist ein Darlehen. Nehmen Sie es, wenn es Ihnen einen riskanten Release spart, und zahlen Sie es zurück, bevor die Zinsen in Ihrem nächsten Refactor erscheinen.