Feature flag: släpp utan att hålla andan

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

1 
2Implementering är när koden kommer i produktion. Release är när någon faktiskt kan använda den. Att blanda ihop de två är ett av de snabbaste sätten att göra varje distribution till ett lite spänt ögonblick.
3 
4feature flag tjänar till att sätta utrymme mellan dessa två ögonblick. Du kan distribuera idag, starta imorgon för det interna teamet, sedan för en pilotkund och sedan för 10 % av användarna. Om något går fel, stäng av flaggan. Du behöver inte nödvändigtvis återställa hela versionen.
5 
6## Flaggan är inte bara ett om
7 
8Tekniskt sett är det ofta en `if`. Kulturellt är det mycket mer.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18Den lilla `if` kan representera en gradvis utbyggnad, ett experiment, en migration, ett företagstillstånd eller en operativ kill switch. Problemet är att om man inte sköter det bra kan det också bli tekniska skulder som stannar i koden i två år.
19 
20## Var kommer OpenFeature in
21 
22OpenFeature är en öppen specifikation för att utvärdera feature flag med en gemensam API. Tanken är enkel: din applikationskod bör inte bero direkt på leverantören eller det interna systemet du använder för flaggor.
23 
24Appen frågar:
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 
34Leverantören bestämmer var reglerna kommer ifrån: SaaS, fil, intern tjänst, flagd, GitOps-konfiguration. Om du en dag byter funktionsflaggande backend behöver applikationen inte skrivas om överallt.
35 
36Denna separation verkar vara en arkitektonisk detalj, men det känns när projektet växer.
37 
38## Sammanhang är halva striden
39 
40En på eller av-flagga för alla är användbar, men begränsad. Progressiva leveranslivslängder i sammanhang:
41 
42- intern eller extern användare;
43- gratis eller företagsplan;
44- by;
45- organisation;
46- appversion;
47- stabil andel av trafiken.
48 
49Den viktiga nyckeln är `targetingKey`: den måste vara stabil. Om det ändras med varje begäran kan en användare hamna en gång i variant A och en gång i variant B. För ett experiment är det fruktansvärt, för en kassa kan det vara katastrofalt.
50 
51## En vettig utbyggnad
52 
53Ett flöde jag gillar är detta:
54 
551. distribuera med flaggan avstängd;
562. tändning för utvecklare och QA;
573. påslagning för en pilotkund eller hyresgäst;
584. 5 % utbyggnad;
595. utbyggnad vid 25 %;
606. 100 % utrullning;
617. borttagning av gammal kod och flagga.
62 
63Den ofta bortglömda punkten är den sista. En tillfällig flagga måste ha ett dödsdatum. Om den stannar för alltid kommer varje framtida refactor att behöva fråga: "men är den här grenen fortfarande användbar?".
64 
65## Kill switch: förbered dem först
66 
67kill switch är flaggan som räddar dig när ett externt beroende börjar bråka med dig, ett jobb förbrukar för mycket resurser eller ny logik ger konstiga fel.
68 
69En bra kill switch måste vara:
70 
71- lätt att hitta;
72- dokumenterad i runbook;
73- testas ibland;
74- observerbar när den är aktiverad;
75- oberoende, så långt det är möjligt, från den del som kan gå sönder.
76 
77Det värsta är att under olyckan upptäcka att flaggan finns, men ingen vet om den fortfarande fungerar.
78 
79## Observerbarhet eller inte progressiv leverans
80 
81Att aktivera en funktion på 10 % utan att titta på mätvärden är bara optimism med flera steg.
82 
83Varje utrullning ska svara på enkla frågor:
84 
85- har felen ökat?
86- har latensen förändrats?
87- slutför användare flödet?
88- finns det fler biljetter eller omförsök?
89- påverkar en variant bara ett segment?
90 
91OpenFeature stöder krokar kring flaggutvärdering. De är användbara för att logga fel, lägga till mätvärden eller länka betyget till en trace.
92 
93## Namngivning och ägande
94 
95Namn spelar roll. `new_ui` säger ingenting. `checkout.v2.enabled` säger mycket mer.
96 
97För varje flagga skulle jag markera minst:
98 
99- namn;
100- beskrivning;
101- ägare;
102- säker standard;
103- anledningen till att den existerar;
104- datum eller skick för avlägsnande.
105 
106En ägarelös flagga är nästan alltid en flagga som ingen kommer att rensa.
107 
108## Var man ska utvärdera dem
109 
110Frontend, backend eller kant? Beror på.
111 
112Om flaggan är för layout, kopiering eller onboarding är frontend bra. Om det gäller behörigheter, fakturering, gränser eller känsliga uppgifter måste det finnas på backend. Om det involverar routing eller experiment med hög trafik kan kanten vara vettig.
113 
114Den enkla regeln: frontend kan förbättra upplevelsen, men det borde inte vara den enda säkerhetsbarriären.
115 
116## Slutsats
117 
118De feature flag bra gjort förändrar förhållandet till produktionen. De eliminerar inte risken, men de gör den mindre och mer hanterbar. Du kan släppa i skivor, observera, stanna, gå tillbaka, lära dig.
119 
120OpenFeature lägger till en ren grund: en gemensam API, utbytbara leverantörer och ett snyggare sätt att växa systemet. Men disciplinen förblir din: säkra standardinställningar, tydliga namn, mätvärden, ägare och renlighet.
121 
122Den bästa flaggan är den som hjälper dig att släppa lugnt och sedan försvinner när den inte längre behövs.
123 
124## Källor
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: släpp utan att hålla andanlines 1-131 (END) — press q to close

2Implementering är när koden kommer i produktion. Release är när någon faktiskt kan använda den. Att blanda ihop de två är ett av de snabbaste sätten att göra varje distribution till ett lite spänt ögonblick.

4feature flag tjänar till att sätta utrymme mellan dessa två ögonblick. Du kan distribuera idag, starta imorgon för det interna teamet, sedan för en pilotkund och sedan för 10 % av användarna. Om något går fel, stäng av flaggan. Du behöver inte nödvändigtvis återställa hela versionen.

6## Flaggan är inte bara ett om

8Tekniskt sett är det ofta en `if`. Kulturellt är det mycket mer.

10```typescript

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

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18Den lilla `if` kan representera en gradvis utbyggnad, ett experiment, en migration, ett företagstillstånd eller en operativ kill switch. Problemet är att om man inte sköter det bra kan det också bli tekniska skulder som stannar i koden i två år.

20## Var kommer OpenFeature in

22OpenFeature är en öppen specifikation för att utvärdera feature flag med en gemensam API. Tanken är enkel: din applikationskod bör inte bero direkt på leverantören eller det interna systemet du använder för flaggor.

24Appen frågar:

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```

34Leverantören bestämmer var reglerna kommer ifrån: SaaS, fil, intern tjänst, flagd, GitOps-konfiguration. Om du en dag byter funktionsflaggande backend behöver applikationen inte skrivas om överallt.

36Denna separation verkar vara en arkitektonisk detalj, men det känns när projektet växer.

38## Sammanhang är halva striden

40En på eller av-flagga för alla är användbar, men begränsad. Progressiva leveranslivslängder i sammanhang:

42- intern eller extern användare;

43- gratis eller företagsplan;

44- by;

45- organisation;

46- appversion;

47- stabil andel av trafiken.

49Den viktiga nyckeln är `targetingKey`: den måste vara stabil. Om det ändras med varje begäran kan en användare hamna en gång i variant A och en gång i variant B. För ett experiment är det fruktansvärt, för en kassa kan det vara katastrofalt.

51## En vettig utbyggnad

53Ett flöde jag gillar är detta:

551. distribuera med flaggan avstängd;

562. tändning för utvecklare och QA;

573. påslagning för en pilotkund eller hyresgäst;

584. 5 % utbyggnad;

595. utbyggnad vid 25 %;

606. 100 % utrullning;

617. borttagning av gammal kod och flagga.

63Den ofta bortglömda punkten är den sista. En tillfällig flagga måste ha ett dödsdatum. Om den stannar för alltid kommer varje framtida refactor att behöva fråga: "men är den här grenen fortfarande användbar?".

65## Kill switch: förbered dem först

67kill switch är flaggan som räddar dig när ett externt beroende börjar bråka med dig, ett jobb förbrukar för mycket resurser eller ny logik ger konstiga fel.

69En bra kill switch måste vara:

71- lätt att hitta;

72- dokumenterad i runbook;

73- testas ibland;

74- observerbar när den är aktiverad;

75- oberoende, så långt det är möjligt, från den del som kan gå sönder.

77Det värsta är att under olyckan upptäcka att flaggan finns, men ingen vet om den fortfarande fungerar.

79## Observerbarhet eller inte progressiv leverans

81Att aktivera en funktion på 10 % utan att titta på mätvärden är bara optimism med flera steg.

83Varje utrullning ska svara på enkla frågor:

85- har felen ökat?

86- har latensen förändrats?

87- slutför användare flödet?

88- finns det fler biljetter eller omförsök?

89- påverkar en variant bara ett segment?

91OpenFeature stöder krokar kring flaggutvärdering. De är användbara för att logga fel, lägga till mätvärden eller länka betyget till en trace.

93## Namngivning och ägande

95Namn spelar roll. `new_ui` säger ingenting. `checkout.v2.enabled` säger mycket mer.

97För varje flagga skulle jag markera minst:

99- namn;

100- beskrivning;

101- ägare;

102- säker standard;

103- anledningen till att den existerar;

104- datum eller skick för avlägsnande.

105

106En ägarelös flagga är nästan alltid en flagga som ingen kommer att rensa.

107

108## Var man ska utvärdera dem

109

110Frontend, backend eller kant? Beror på.

111

112Om flaggan är för layout, kopiering eller onboarding är frontend bra. Om det gäller behörigheter, fakturering, gränser eller känsliga uppgifter måste det finnas på backend. Om det involverar routing eller experiment med hög trafik kan kanten vara vettig.

113

114Den enkla regeln: frontend kan förbättra upplevelsen, men det borde inte vara den enda säkerhetsbarriären.

115

116## Slutsats

117

118De feature flag bra gjort förändrar förhållandet till produktionen. De eliminerar inte risken, men de gör den mindre och mer hanterbar. Du kan släppa i skivor, observera, stanna, gå tillbaka, lära dig.

119

120OpenFeature lägger till en ren grund: en gemensam API, utbytbara leverantörer och ett snyggare sätt att växa systemet. Men disciplinen förblir din: säkra standardinställningar, tydliga namn, mätvärden, ägare och renlighet.

121

122Den bästa flaggan är den som hjälper dig att släppa lugnt och sedan försvinner när den inte längre behövs.

123

124## Källor

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