Feature flag: loslassen, ohne den Atem anzuhalten

spinny:~/writing $ vim 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~

NORMAL · openfeature-feature-flags-progressive-delivery.md [readonly]131 lines · :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}

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~