Feature flag: loslassen, ohne den Atem anzuhalten

spinny:~/writing $ less openfeature-feature-flags-progressive-delivery.md

1 
2Die 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.
3 
4Die 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.
5 
6## Die Flagge ist nicht nur ein Wenn
7 
8Technisch gesehen ist es oft ein `if`. Kulturell ist es viel mehr.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18Dieses 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.
19 
20## Wo kommt OpenFeature ins Spiel?
21 
22OpenFeature 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.
23 
24Die App fragt:
25 
26```typescript
27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
28  targetingKey: user.id,
29  plan: user.plan,
30  country: user.country,
31});
32```
33 
34Der 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.
35 
36Diese Trennung scheint ein architektonisches Detail zu sein, aber sie wird spürbar, wenn das Projekt wächst.
37 
38## Der Kontext ist die halbe Miete
39 
40Eine Ein- oder Aus-Flagge für alle ist nützlich, aber begrenzt. Progressive Lieferung lebt im Kontext:
41 
42- interner oder externer Benutzer;
43- kostenloser oder Enterprise-Plan;
44- Dorf;
45- Organisation;
46- App-Version;
47- stabiler Verkehrsanteil.
48 
49Der 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.
50 
51## Ein sinnvoller Rollout
52 
53Ein Flow, der mir gefällt, ist dieser:
54 
551. Bereitstellung mit ausgeschalteter Flagge;
562. Zündung für Entwickler und Qualitätssicherung;
573. Einschaltung für einen Pilotkunden oder Mieter;
584. 5 % Einführung;
595. Rollout bei 25 %;
606. 100 % Einführung;
617. Entfernen des alten Codes und der Markierung.
62 
63Der 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?“.
64 
65## Kill switch: Bereiten Sie sie zuerst vor
66 
67Das 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.
68 
69Eine gute kill switch muss sein:
70 
71- leicht zu finden;
72- im Runbook dokumentiert;
73- gelegentlich getestet;
74- bei Aktivierung beobachtbar;
75- weitestgehend unabhängig von dem Teil, das brechen könnte.
76 
77Das Schlimmste ist, während des Unfalls festzustellen, dass die Flagge existiert, aber niemand weiß, ob sie noch funktioniert.
78 
79## Beobachtbarkeit oder nicht progressive Lieferung
80 
81Eine Funktion bei 10 % zu aktivieren, ohne sich die Metriken anzusehen, ist nur Optimismus mit mehreren Schritten.
82 
83Jeder Rollout sollte einfache Fragen beantworten:
84 
85- Haben die Fehler zugenommen?
86- Hat sich die Latenz geändert?
87- Schließen Benutzer den Flow ab?
88- Gibt es weitere Tickets oder Wiederholungsversuche?
89- Betrifft eine Variante nur ein Segment?
90 
91OpenFeature 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.
92 
93## Benennung und Eigentum
94 
95Namen sind wichtig. `new_ui` sagt nichts. `checkout.v2.enabled` sagt viel mehr.
96 
97Für jede Flagge würde ich mindestens Folgendes markieren:
98 
99- Name;
100- Beschreibung;
101- Eigentümer;
102- sicherer Standard;
103- Grund, warum es existiert;
104- Datum oder Zustand der Entfernung.
105 
106Eine herrenlose Flagge ist fast immer eine Flagge, die niemand löschen kann.
107 
108## Wo man sie bewerten kann
109 
110Frontend, Backend oder Edge? Kommt darauf an.
111 
112Wenn 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.
113 
114Die einfache Regel: Das Frontend kann das Erlebnis verbessern, sollte aber nicht die einzige Sicherheitsbarriere sein.
115 
116## Fazit
117 
118Die 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.
119 
120OpenFeature 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.
121 
122Die beste Flagge ist diejenige, die Ihnen hilft, ruhig loszulassen und dann verschwindet, wenn sie nicht mehr benötigt wird.
123 
124## Quellen
125 
126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)
127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)
128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)
129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)
130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)
131

:Feature flag: loslassen, ohne den Atem anzuhaltenlines 1-131 (END) — press q to close

2Die 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.

4Die 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.

6## Die Flagge ist nicht nur ein Wenn

8Technisch gesehen ist es oft ein `if`. Kulturell ist es viel mehr.

10```typescript

11if (await flags.isEnabled('checkout.v2.enabled', context)) {

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18Dieses 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.

20## Wo kommt OpenFeature ins Spiel?

22OpenFeature 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.

24Die App fragt:

26```typescript

27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {

28 targetingKey: user.id,

29 plan: user.plan,

30 country: user.country,

31});

32```

34Der 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.

36Diese Trennung scheint ein architektonisches Detail zu sein, aber sie wird spürbar, wenn das Projekt wächst.

38## Der Kontext ist die halbe Miete

40Eine Ein- oder Aus-Flagge für alle ist nützlich, aber begrenzt. Progressive Lieferung lebt im Kontext:

42- interner oder externer Benutzer;

43- kostenloser oder Enterprise-Plan;

44- Dorf;

45- Organisation;

46- App-Version;

47- stabiler Verkehrsanteil.

49Der 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.

51## Ein sinnvoller Rollout

53Ein Flow, der mir gefällt, ist dieser:

551. Bereitstellung mit ausgeschalteter Flagge;

562. Zündung für Entwickler und Qualitätssicherung;

573. Einschaltung für einen Pilotkunden oder Mieter;

584. 5 % Einführung;

595. Rollout bei 25 %;

606. 100 % Einführung;

617. Entfernen des alten Codes und der Markierung.

63Der 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?“.

65## Kill switch: Bereiten Sie sie zuerst vor

67Das 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.

69Eine gute kill switch muss sein:

71- leicht zu finden;

72- im Runbook dokumentiert;

73- gelegentlich getestet;

74- bei Aktivierung beobachtbar;

75- weitestgehend unabhängig von dem Teil, das brechen könnte.

77Das Schlimmste ist, während des Unfalls festzustellen, dass die Flagge existiert, aber niemand weiß, ob sie noch funktioniert.

79## Beobachtbarkeit oder nicht progressive Lieferung

81Eine Funktion bei 10 % zu aktivieren, ohne sich die Metriken anzusehen, ist nur Optimismus mit mehreren Schritten.

83Jeder Rollout sollte einfache Fragen beantworten:

85- Haben die Fehler zugenommen?

86- Hat sich die Latenz geändert?

87- Schließen Benutzer den Flow ab?

88- Gibt es weitere Tickets oder Wiederholungsversuche?

89- Betrifft eine Variante nur ein Segment?

91OpenFeature 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.

93## Benennung und Eigentum

95Namen sind wichtig. `new_ui` sagt nichts. `checkout.v2.enabled` sagt viel mehr.

97Für jede Flagge würde ich mindestens Folgendes markieren:

99- Name;

100- Beschreibung;

101- Eigentümer;

102- sicherer Standard;

103- Grund, warum es existiert;

104- Datum oder Zustand der Entfernung.

105

106Eine herrenlose Flagge ist fast immer eine Flagge, die niemand löschen kann.

107

108## Wo man sie bewerten kann

109

110Frontend, Backend oder Edge? Kommt darauf an.

111

112Wenn 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.

113

114Die einfache Regel: Das Frontend kann das Erlebnis verbessern, sollte aber nicht die einzige Sicherheitsbarriere sein.

115

116## Fazit

117

118Die 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.

119

120OpenFeature 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.

121

122Die beste Flagge ist diejenige, die Ihnen hilft, ruhig loszulassen und dann verschwindet, wenn sie nicht mehr benötigt wird.

123

124## Quellen

125

126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)

127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)

128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)

129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)

130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)

131