Die Bereitstellung erfolgt, wenn der Code in der Produktion ankommt. Release ist, wenn jemand es tatsächlich nutzen kann. Die beiden zu verwechseln ist eine der schnellsten Möglichkeiten, jeden Einsatz zu einem etwas angespannten Moment zu machen.
Die feature flag dienen dazu, zwischen diesen beiden Momenten Platz zu schaffen. Sie können es heute bereitstellen, morgen für das interne Team starten, dann für einen Pilotkunden und dann für 10 % der Benutzer. Wenn etwas schief geht, schalten Sie die Flagge aus. Sie müssen nicht unbedingt die gesamte Version zurücksetzen.
Die Flagge ist nicht nur ein Wenn
Technisch gesehen ist es oft ein if. Kulturell ist es viel mehr.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Dieses kleine if kann eine schrittweise Einführung, ein Experiment, eine Migration, eine Unternehmensgenehmigung oder ein betriebsbereites kill switch darstellen. Das Problem ist, dass es, wenn man es nicht gut hinbekommt, auch zu technischen Schulden kommen kann, die zwei Jahre lang im Code verbleiben.
Wo kommt OpenFeature ins Spiel?
OpenFeature ist eine offene Spezifikation zur Bewertung von feature flag mit einem gemeinsamen API. Die Idee ist einfach: Ihr Anwendungscode sollte nicht direkt vom Anbieter oder internen System abhängen, das Sie für Flags verwenden.
Die App fragt:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Der Anbieter entscheidet, woher die Regeln kommen: SaaS, Datei, interner Dienst, Flagd, GitOps-Konfiguration. Wenn Sie eines Tages das Feature-Flagging-Backend ändern, muss die Anwendung nicht überall neu geschrieben werden.
Diese Trennung scheint ein architektonisches Detail zu sein, aber sie wird spürbar, wenn das Projekt wächst.
Der Kontext ist die halbe Miete
Eine Ein- oder Aus-Flagge für alle ist nützlich, aber begrenzt. Progressive Lieferung lebt im Kontext:
- interner oder externer Benutzer;
- kostenloser oder Enterprise-Plan;
- Dorf;
- Organisation;
- App-Version;
- stabiler Verkehrsanteil.
Der wichtige Schlüssel ist targetingKey: Er muss stabil sein. Wenn es sich bei jeder Anfrage ändert, kann ein Benutzer einmal in Variante A und einmal in Variante B landen. Für ein Experiment ist es schrecklich, für einen Checkout kann es katastrophal sein.
Ein sinnvoller Rollout
Ein Flow, der mir gefällt, ist dieser:
- Bereitstellung mit ausgeschalteter Flagge;
- Zündung für Entwickler und Qualitätssicherung;
- Einschaltung für einen Pilotkunden oder Mieter;
- 5 % Einführung;
- Rollout bei 25 %;
- 100 % Einführung;
- Entfernen des alten Codes und der Markierung.
Der oft vergessene Punkt ist der letzte. Eine temporäre Flagge muss ein Sterbedatum haben. Wenn es für immer so bleibt, muss sich jeder zukünftige Refactor fragen: „Aber ist dieser Zweig noch nützlich?“.
Kill switch: Bereiten Sie sie zuerst vor
Das kill switch ist das Flag, das Sie rettet, wenn eine externe Abhängigkeit anfängt, Sie zu stören, ein Job zu viele Ressourcen verbraucht oder eine neue Logik seltsame Fehler erzeugt.
Eine gute kill switch muss sein:
- leicht zu finden;
- im Runbook dokumentiert;
- gelegentlich getestet;
- bei Aktivierung beobachtbar;
- weitestgehend unabhängig von dem Teil, das brechen könnte.
Das Schlimmste ist, während des Unfalls festzustellen, dass die Flagge existiert, aber niemand weiß, ob sie noch funktioniert.
Beobachtbarkeit oder nicht progressive Lieferung
Eine Funktion bei 10 % zu aktivieren, ohne sich die Metriken anzusehen, ist nur Optimismus mit mehreren Schritten.
Jeder Rollout sollte einfache Fragen beantworten:
- Haben die Fehler zugenommen?
- Hat sich die Latenz geändert?
- Schließen Benutzer den Flow ab?
- Gibt es weitere Tickets oder Wiederholungsversuche?
- Betrifft eine Variante nur ein Segment?
OpenFeature unterstützt Hooks rund um die Flag-Auswertung. Sie sind nützlich, um Fehler zu protokollieren, Metriken hinzuzufügen oder die Bewertung mit einer trace zu verknüpfen.
Benennung und Eigentum
Namen sind wichtig. new_ui sagt nichts. checkout.v2.enabled sagt viel mehr.
Für jede Flagge würde ich mindestens Folgendes markieren:
- Name;
- Beschreibung;
- Eigentümer;
- sicherer Standard;
- Grund, warum es existiert;
- Datum oder Zustand der Entfernung.
Eine herrenlose Flagge ist fast immer eine Flagge, die niemand löschen kann.
Wo man sie bewerten kann
Frontend, Backend oder Edge? Kommt darauf an.
Wenn es sich bei der Flagge um Layout, Kopie oder Onboarding handelt, ist das Frontend in Ordnung. Wenn es um Berechtigungen, Abrechnungen, Limits oder sensible Daten geht, muss es im Backend erfolgen. Wenn es um Routing oder Experimente mit hohem Datenverkehr geht, kann der Edge sinnvoll sein.
Die einfache Regel: Das Frontend kann das Erlebnis verbessern, sollte aber nicht die einzige Sicherheitsbarriere sein.
Fazit
Die gut gemachten feature flag verändern die Beziehung zur Produktion. Sie beseitigen das Risiko nicht, machen es aber kleiner und beherrschbarer. Sie können in Scheiben loslassen, beobachten, anhalten, zurückgehen, lernen.
OpenFeature fügt eine saubere Grundlage hinzu: ein gemeinsames API, austauschbare Anbieter und eine sauberere Möglichkeit, das System zu erweitern. Aber die Disziplin bleibt bei Ihnen: sichere Standardeinstellungen, klare Namen, Metriken, Eigentümer und Sauberkeit.
Die beste Flagge ist diejenige, die Ihnen hilft, ruhig loszulassen und dann verschwindet, wenn sie nicht mehr benötigt wird.