Feature flag: loslaten zonder je adem in te houden

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

1~
2Implementatie vindt plaats wanneer de code in productie komt. Vrijgave is wanneer iemand het daadwerkelijk kan gebruiken. Het verwarren van deze twee is een van de snelste manieren om van elke inzet een spannend moment te maken.
3~
4De feature flag dienen om ruimte tussen deze twee momenten te creëren. U kunt vandaag implementeren, morgen starten voor het interne team, vervolgens voor een pilotklant en vervolgens voor 10% van de gebruikers. Als er iets misgaat, zet dan de vlag uit. U hoeft niet noodzakelijkerwijs de hele release terug te draaien.
5~
6## De vlag is niet alleen een als
7~
8Technisch gezien is het vaak een `if`. Cultureel gezien is het veel meer.
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18Dat kleine `if` kan een geleidelijke uitrol, een experiment, een migratie, een ondernemingsvergunning of een operationele kill switch vertegenwoordigen. Het probleem is dat als je het niet goed beheert, het ook technische schulden kunnen worden die twee jaar in de code blijven staan.
19~
20## Waar komt OpenFeature binnen?
21~
22OpenFeature is een open specificatie voor het evalueren van feature flag met een gemeenschappelijke API. Het idee is simpel: uw applicatiecode mag niet rechtstreeks afhankelijk zijn van de leverancier of het interne systeem dat u voor vlaggen gebruikt.
23~
24De app vraagt:
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~
34De provider bepaalt waar de regels vandaan komen: SaaS, bestand, interne service, flagd, GitOps-configuratie. Als u op een dag de backend met functiemarkeringen wijzigt, hoeft de applicatie niet overal opnieuw te worden geschreven.
35~
36Deze scheiding lijkt een architectonisch detail, maar wordt voelbaar naarmate het project groeit.
37~
38## Context is het halve werk
39~
40Een aan- of uitvlag voor iedereen is handig, maar beperkt. Progressieve bezorging leeft in context:
41~
42- interne of externe gebruiker;
43- gratis of ondernemingsplan;
44- dorp;
45- organisatie;
46- app-versie;
47- stabiel percentage verkeer.
48~
49De belangrijke sleutel is `targetingKey`: deze moet stabiel zijn. Als het bij iedere aanvraag verandert, kan een gebruiker één keer in variant A terechtkomen en één keer in variant B. Voor een experiment is het verschrikkelijk, voor een kassa kan het desastreus zijn.
50~
51## Een verstandige uitrol
52~
53Een flow die ik leuk vind is deze:
54~
551. inzetten met uitgeschakelde vlag;
562. ontsteking voor ontwikkelaars en QA;
573. inschakelen voor een pilotklant of huurder;
584. Uitrol van 5%;
595. uitrol op 25%;
606. 100% uitrol;
617. verwijdering van oude code en vlag.
62~
63Het vaak vergeten punt is het laatste. Een tijdelijke vlag moet een overlijdensdatum hebben. Als het voor altijd blijft, zal elke toekomstige refactor zich moeten afvragen: "maar is deze tak nog bruikbaar?".
64~
65## Kill switch: bereid ze eerst voor
66~
67De kill switch is de vlag die u redt wanneer een externe afhankelijkheid u in de war brengt, een taak te veel bronnen verbruikt of nieuwe logica vreemde fouten oplevert.
68~
69Een goede kill switch moet zijn:
70~
71- gemakkelijk te vinden;
72- gedocumenteerd in het runbook;
73- af en toe getest;
74- waarneembaar wanneer geactiveerd;
75- voor zover mogelijk onafhankelijk van het onderdeel dat kapot zou kunnen gaan.
76~
77Het ergste is om tijdens het ongeval te ontdekken dat de vlag bestaat, maar niemand weet of hij nog werkt.
78~
79## Waarneembaarheid of niet progressieve levering
80~
81Een functie op 10% inschakelen zonder naar de statistieken te kijken is slechts optimisme met meerdere stappen.
82~
83Elke uitrol moet eenvoudige vragen beantwoorden:
84~
85- zijn de fouten toegenomen?
86- is de latentie veranderd?
87- voltooien gebruikers de stroom?
88- zijn er meer tickets of nieuwe pogingen?
89- heeft een variant slechts invloed op één segment?
90~
91OpenFeature ondersteunt haken rond vlagevaluatie. Ze zijn handig voor het loggen van fouten, het toevoegen van statistieken of het koppelen van de beoordeling aan een trace.
92~
93## Naamgeving en eigendom
94~
95Namen zijn belangrijk. `new_ui` zegt niets. `checkout.v2.enabled` zegt veel meer.
96~
97Voor elke vlag zou ik minimaal het volgende markeren:
98~
99- naam;
100- beschrijving;
101- eigenaar;
102- veilige standaard;
103- reden waarom het bestaat;
104- datum of voorwaarde van verwijdering.
105~
106Een vlag zonder eigenaar is bijna altijd een vlag die niemand zal ontruimen.
107~
108## Waar je ze kunt evalueren
109~
110Frontend, backend of edge? Hangt ervan af.
111~
112Als de vlag bedoeld is voor lay-out, kopiëren of onboarding, is de frontend prima. Als het om machtigingen, facturering, limieten of gevoelige gegevens gaat, moet dit op de backend staan. Als het gaat om routing of experimenten met veel verkeer, kan de edge zinvol zijn.
113~
114De simpele regel: de frontend kan de ervaring verbeteren, maar mag niet de enige beveiligingsbarrière zijn.
115~
116## Conclusie
117~
118De feature flag die goed zijn gedaan, veranderen de relatie met de productie. Ze elimineren het risico niet, maar maken het kleiner en beter beheersbaar. Je kunt in stukjes loslaten, observeren, stoppen, teruggaan, leren.
119~
120OpenFeature voegt een schone basis toe: een gemeenschappelijke API, uitwisselbare providers en een nettere manier om het systeem te laten groeien. Maar de discipline blijft van jou: veilige standaardwaarden, duidelijke namen, statistieken, eigenaren en netheid.
121~
122De beste vlag is degene die je helpt rustig los te laten en vervolgens verdwijnt als hij niet langer nodig is.
123~
124## Bronnen
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

2Implementatie vindt plaats wanneer de code in productie komt. Vrijgave is wanneer iemand het daadwerkelijk kan gebruiken. Het verwarren van deze twee is een van de snelste manieren om van elke inzet een spannend moment te maken.

4De feature flag dienen om ruimte tussen deze twee momenten te creëren. U kunt vandaag implementeren, morgen starten voor het interne team, vervolgens voor een pilotklant en vervolgens voor 10% van de gebruikers. Als er iets misgaat, zet dan de vlag uit. U hoeft niet noodzakelijkerwijs de hele release terug te draaien.

6## De vlag is niet alleen een als

8Technisch gezien is het vaak een `if`. Cultureel gezien is het veel meer.

10```typescript

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

12 return newCheckout(input);

13}

14~

15return oldCheckout(input);

16```

17~

18Dat kleine `if` kan een geleidelijke uitrol, een experiment, een migratie, een ondernemingsvergunning of een operationele kill switch vertegenwoordigen. Het probleem is dat als je het niet goed beheert, het ook technische schulden kunnen worden die twee jaar in de code blijven staan.

19~

20## Waar komt OpenFeature binnen?

21~

22OpenFeature is een open specificatie voor het evalueren van feature flag met een gemeenschappelijke API. Het idee is simpel: uw applicatiecode mag niet rechtstreeks afhankelijk zijn van de leverancier of het interne systeem dat u voor vlaggen gebruikt.

23~

24De app vraagt:

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~

34De provider bepaalt waar de regels vandaan komen: SaaS, bestand, interne service, flagd, GitOps-configuratie. Als u op een dag de backend met functiemarkeringen wijzigt, hoeft de applicatie niet overal opnieuw te worden geschreven.

35~

36Deze scheiding lijkt een architectonisch detail, maar wordt voelbaar naarmate het project groeit.

37~

38## Context is het halve werk

39~

40Een aan- of uitvlag voor iedereen is handig, maar beperkt. Progressieve bezorging leeft in context:

41~

42- interne of externe gebruiker;

43- gratis of ondernemingsplan;

44- dorp;

45- organisatie;

46- app-versie;

47- stabiel percentage verkeer.

48~

49De belangrijke sleutel is `targetingKey`: deze moet stabiel zijn. Als het bij iedere aanvraag verandert, kan een gebruiker één keer in variant A terechtkomen en één keer in variant B. Voor een experiment is het verschrikkelijk, voor een kassa kan het desastreus zijn.

50~

51## Een verstandige uitrol

52~

53Een flow die ik leuk vind is deze:

54~

551. inzetten met uitgeschakelde vlag;

562. ontsteking voor ontwikkelaars en QA;

573. inschakelen voor een pilotklant of huurder;

584. Uitrol van 5%;

595. uitrol op 25%;

606. 100% uitrol;

617. verwijdering van oude code en vlag.

62~

63Het vaak vergeten punt is het laatste. Een tijdelijke vlag moet een overlijdensdatum hebben. Als het voor altijd blijft, zal elke toekomstige refactor zich moeten afvragen: "maar is deze tak nog bruikbaar?".

64~

65## Kill switch: bereid ze eerst voor

66~

67De kill switch is de vlag die u redt wanneer een externe afhankelijkheid u in de war brengt, een taak te veel bronnen verbruikt of nieuwe logica vreemde fouten oplevert.

68~

69Een goede kill switch moet zijn:

70~

71- gemakkelijk te vinden;

72- gedocumenteerd in het runbook;

73- af en toe getest;

74- waarneembaar wanneer geactiveerd;

75- voor zover mogelijk onafhankelijk van het onderdeel dat kapot zou kunnen gaan.

76~

77Het ergste is om tijdens het ongeval te ontdekken dat de vlag bestaat, maar niemand weet of hij nog werkt.

78~

79## Waarneembaarheid of niet progressieve levering

80~

81Een functie op 10% inschakelen zonder naar de statistieken te kijken is slechts optimisme met meerdere stappen.

82~

83Elke uitrol moet eenvoudige vragen beantwoorden:

84~

85- zijn de fouten toegenomen?

86- is de latentie veranderd?

87- voltooien gebruikers de stroom?

88- zijn er meer tickets of nieuwe pogingen?

89- heeft een variant slechts invloed op één segment?

90~

91OpenFeature ondersteunt haken rond vlagevaluatie. Ze zijn handig voor het loggen van fouten, het toevoegen van statistieken of het koppelen van de beoordeling aan een trace.

92~

93## Naamgeving en eigendom

94~

95Namen zijn belangrijk. `new_ui` zegt niets. `checkout.v2.enabled` zegt veel meer.

96~

97Voor elke vlag zou ik minimaal het volgende markeren:

98~

99- naam;

100- beschrijving;

101- eigenaar;

102- veilige standaard;

103- reden waarom het bestaat;

104- datum of voorwaarde van verwijdering.

105~

106Een vlag zonder eigenaar is bijna altijd een vlag die niemand zal ontruimen.

107~

108## Waar je ze kunt evalueren

109~

110Frontend, backend of edge? Hangt ervan af.

111~

112Als de vlag bedoeld is voor lay-out, kopiëren of onboarding, is de frontend prima. Als het om machtigingen, facturering, limieten of gevoelige gegevens gaat, moet dit op de backend staan. Als het gaat om routing of experimenten met veel verkeer, kan de edge zinvol zijn.

113~

114De simpele regel: de frontend kan de ervaring verbeteren, maar mag niet de enige beveiligingsbarrière zijn.

115~

116## Conclusie

117~

118De feature flag die goed zijn gedaan, veranderen de relatie met de productie. Ze elimineren het risico niet, maar maken het kleiner en beter beheersbaar. Je kunt in stukjes loslaten, observeren, stoppen, teruggaan, leren.

119~

120OpenFeature voegt een schone basis toe: een gemeenschappelijke API, uitwisselbare providers en een nettere manier om het systeem te laten groeien. Maar de discipline blijft van jou: veilige standaardwaarden, duidelijke namen, statistieken, eigenaren en netheid.

121~

122De beste vlag is degene die je helpt rustig los te laten en vervolgens verdwijnt als hij niet langer nodig is.

123~

124## Bronnen

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~