Feature flag: lélegzetvisszatartás nélkül engedje el

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

1 
2Az üzembe helyezés az, amikor a kód megérkezik az éles rendszerbe. A kiadás az, amikor valaki ténylegesen használhatja. A kettő összekeverése az egyik leggyorsabb módja annak, hogy minden telepítést egy kicsit feszült pillanatokká varázsoljunk.
3 
4A feature flag arra szolgál, hogy helyet tegyen e két pillanat közé. Ma telepítheti, holnap elindíthatja a belső csapatot, majd egy kísérleti ügyfélnél, majd a felhasználók 10%-ánál. Ha valami elromlik, kapcsolja ki a zászlót. Nem feltétlenül kell visszaállítania a teljes kiadást.
5 
6## A zászló nem csak egy ha
7 
8Technikailag gyakran `if`. Kulturálisan ez sokkal több.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18Ez a kis `if` jelenthet fokozatos bevezetést, kísérletet, migrációt, vállalkozási engedélyt vagy működési kill switch-t. A probléma az, hogy ha nem jól kezeled, akkor technikai adósság is lehet belőle, ami két évig a kódban marad.
19 
20## Hol jön be az OpenFeature?
21 
22A OpenFeature egy nyílt specifikáció a feature flag kiértékeléséhez egy közös API-vel. Az ötlet egyszerű: az alkalmazás kódja nem függhet közvetlenül a jelzőkhöz használt szállítótól vagy belső rendszertől.
23 
24Az alkalmazás megkérdezi:
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 
34A szolgáltató dönti el, honnan származnak a szabályok: SaaS, fájl, belső szolgáltatás, megjelölt, GitOps konfiguráció. Ha egy nap megváltoztatja a funkciójelző háttérrendszert, az alkalmazást nem kell mindenhol átírni.
35 
36Ez az elválasztás építészeti részletnek tűnik, de a projekt növekedésével érezhető.
37 
38## A kontextus fél siker
39 
40A be- vagy kikapcsolási jelző mindenki számára hasznos, de korlátozott. A progresszív szállítás a következő összefüggésekben él:
41 
42- belső vagy külső felhasználó;
43- ingyenes vagy vállalati csomag;
44- falu;
45- szervezés;
46- az alkalmazás verziója;
47- stabil százalékos forgalom.
48 
49A fontos kulcs a `targetingKey`: stabilnak kell lennie. Ha minden kéréssel változik, a felhasználó egyszer az A változatba, egyszer pedig a B változatba kerülhet. Egy kísérletnél ez szörnyű, egy fizetésnél katasztrofális lehet.
50 
51## Ésszerű bevezetés
52 
53Egy áramlás, amit szeretek, ez:
54 
551. telepítés kikapcsolt jelzővel;
562. gyújtás a fejlesztőknek és a minőségbiztosításnak;
573. bekapcsolás kísérleti ügyfél vagy bérlő számára;
584. 5%-os bevezetés;
595. 25%-os bevezetés;
606. 100%-os bevezetés;
617. a régi kód és zászló eltávolítása.
62 
63A gyakran elfelejtett pont az utolsó. Az ideiglenes zászlónak tartalmaznia kell a halál dátumát. Ha ez örökre megmarad, minden leendő refaktornak meg kell kérdeznie: "de hasznos-e még ez az ág?".
64 
65## Kill switch: először készítse elő őket
66 
67A kill switch az a jelző, amely megmenti Önt, ha egy külső függőség zavarja Önt, egy feladat túl sok erőforrást fogyaszt, vagy az új logika furcsa hibákat produkál.
68 
69A jó kill switch-nek a következőnek kell lennie:
70 
71- könnyen megtalálható;
72- a runbookban dokumentálva;
73- alkalmanként tesztelve;
74- aktivált állapotban megfigyelhető;
75- lehetőség szerint független attól a résztől, amely eltörhet.
76 
77A legrosszabb az, ha a baleset során felfedezzük, hogy a zászló létezik, de senki sem tudja, működik-e még.
78 
79## Megfigyelhetőség vagy nem progresszív szállítás
80 
81Egy funkció 10%-os bekapcsolása a mutatók megtekintése nélkül csak optimizmus, több lépéssel.
82 
83Minden kiadásnak meg kell válaszolnia az egyszerű kérdéseket:
84 
85- nőtt a hibák száma?
86- változott a késleltetés?
87- a felhasználók befejezik a folyamatot?
88- van több jegy vagy próbálkozás?
89- egy változat csak egy szegmenst érint?
90 
91A OpenFeature támogatja a zászlóértékelés körüli horgokat. Hasznosak a hibák naplózásához, mérőszámok hozzáadásához vagy az értékelés trace-hez való kapcsolásához.
92 
93## Elnevezés és tulajdonjog
94 
95A nevek számítanak. `new_ui` nem mond semmit. `checkout.v2.enabled` sokkal többet mond.
96 
97Minden zászlónál legalább a következőket jelölném:
98 
99- név;
100- leírás;
101- tulajdonos;
102- biztonságos alapértelmezett;
103- a létezés oka;
104- az eltávolítás dátuma vagy feltétele.
105 
106A gazdátlan zászló szinte mindig olyan zászló, amelyet senki sem fog letörölni.
107 
108## Hol kell értékelni őket
109 
110Frontend, backend vagy edge? attól függ.
111 
112Ha a zászló az elrendezésre, a másolásra vagy a beépítésre vonatkozik, az előtér rendben van. Ha engedélyekre, számlázásra, korlátokra vagy bizalmas adatokra vonatkozik, akkor a háttérben kell lennie. Ha ez útválasztást vagy nagy forgalmú kísérleteket foglal magában, az élnek lehet értelme.
113 
114Az egyszerű szabály: a frontend javíthatja az élményt, de nem ez lehet az egyetlen biztonsági akadály.
115 
116## Következtetés
117 
118A jól sikerült feature flag megváltoztatja a termeléshez való viszonyt. Nem szüntetik meg a kockázatot, de kisebbé és kezelhetőbbé teszik. Lehet szeletekben elengedni, megfigyelni, megállni, visszamenni, tanulni.
119 
120Az OpenFeature tiszta alapot ad: egy közös API, cserélhető szolgáltatókat és egy rendezettebb módszert a rendszer bővítésére. De a fegyelem a tiéd marad: biztonságos alapértelmezések, egyértelmű nevek, mutatók, tulajdonosok és tisztaság.
121 
122A legjobb zászló az, amely segít nyugodtan elengedni, majd eltűnik, amikor már nincs rá szükség.
123 
124## Források
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: lélegzetvisszatartás nélkül engedje ellines 1-131 (END) — press q to close

2Az üzembe helyezés az, amikor a kód megérkezik az éles rendszerbe. A kiadás az, amikor valaki ténylegesen használhatja. A kettő összekeverése az egyik leggyorsabb módja annak, hogy minden telepítést egy kicsit feszült pillanatokká varázsoljunk.

4A feature flag arra szolgál, hogy helyet tegyen e két pillanat közé. Ma telepítheti, holnap elindíthatja a belső csapatot, majd egy kísérleti ügyfélnél, majd a felhasználók 10%-ánál. Ha valami elromlik, kapcsolja ki a zászlót. Nem feltétlenül kell visszaállítania a teljes kiadást.

6## A zászló nem csak egy ha

8Technikailag gyakran `if`. Kulturálisan ez sokkal több.

10```typescript

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

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18Ez a kis `if` jelenthet fokozatos bevezetést, kísérletet, migrációt, vállalkozási engedélyt vagy működési kill switch-t. A probléma az, hogy ha nem jól kezeled, akkor technikai adósság is lehet belőle, ami két évig a kódban marad.

20## Hol jön be az OpenFeature?

22A OpenFeature egy nyílt specifikáció a feature flag kiértékeléséhez egy közös API-vel. Az ötlet egyszerű: az alkalmazás kódja nem függhet közvetlenül a jelzőkhöz használt szállítótól vagy belső rendszertől.

24Az alkalmazás megkérdezi:

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

34A szolgáltató dönti el, honnan származnak a szabályok: SaaS, fájl, belső szolgáltatás, megjelölt, GitOps konfiguráció. Ha egy nap megváltoztatja a funkciójelző háttérrendszert, az alkalmazást nem kell mindenhol átírni.

36Ez az elválasztás építészeti részletnek tűnik, de a projekt növekedésével érezhető.

38## A kontextus fél siker

40A be- vagy kikapcsolási jelző mindenki számára hasznos, de korlátozott. A progresszív szállítás a következő összefüggésekben él:

42- belső vagy külső felhasználó;

43- ingyenes vagy vállalati csomag;

44- falu;

45- szervezés;

46- az alkalmazás verziója;

47- stabil százalékos forgalom.

49A fontos kulcs a `targetingKey`: stabilnak kell lennie. Ha minden kéréssel változik, a felhasználó egyszer az A változatba, egyszer pedig a B változatba kerülhet. Egy kísérletnél ez szörnyű, egy fizetésnél katasztrofális lehet.

51## Ésszerű bevezetés

53Egy áramlás, amit szeretek, ez:

551. telepítés kikapcsolt jelzővel;

562. gyújtás a fejlesztőknek és a minőségbiztosításnak;

573. bekapcsolás kísérleti ügyfél vagy bérlő számára;

584. 5%-os bevezetés;

595. 25%-os bevezetés;

606. 100%-os bevezetés;

617. a régi kód és zászló eltávolítása.

63A gyakran elfelejtett pont az utolsó. Az ideiglenes zászlónak tartalmaznia kell a halál dátumát. Ha ez örökre megmarad, minden leendő refaktornak meg kell kérdeznie: "de hasznos-e még ez az ág?".

65## Kill switch: először készítse elő őket

67A kill switch az a jelző, amely megmenti Önt, ha egy külső függőség zavarja Önt, egy feladat túl sok erőforrást fogyaszt, vagy az új logika furcsa hibákat produkál.

69A jó kill switch-nek a következőnek kell lennie:

71- könnyen megtalálható;

72- a runbookban dokumentálva;

73- alkalmanként tesztelve;

74- aktivált állapotban megfigyelhető;

75- lehetőség szerint független attól a résztől, amely eltörhet.

77A legrosszabb az, ha a baleset során felfedezzük, hogy a zászló létezik, de senki sem tudja, működik-e még.

79## Megfigyelhetőség vagy nem progresszív szállítás

81Egy funkció 10%-os bekapcsolása a mutatók megtekintése nélkül csak optimizmus, több lépéssel.

83Minden kiadásnak meg kell válaszolnia az egyszerű kérdéseket:

85- nőtt a hibák száma?

86- változott a késleltetés?

87- a felhasználók befejezik a folyamatot?

88- van több jegy vagy próbálkozás?

89- egy változat csak egy szegmenst érint?

91A OpenFeature támogatja a zászlóértékelés körüli horgokat. Hasznosak a hibák naplózásához, mérőszámok hozzáadásához vagy az értékelés trace-hez való kapcsolásához.

93## Elnevezés és tulajdonjog

95A nevek számítanak. `new_ui` nem mond semmit. `checkout.v2.enabled` sokkal többet mond.

97Minden zászlónál legalább a következőket jelölném:

99- név;

100- leírás;

101- tulajdonos;

102- biztonságos alapértelmezett;

103- a létezés oka;

104- az eltávolítás dátuma vagy feltétele.

105

106A gazdátlan zászló szinte mindig olyan zászló, amelyet senki sem fog letörölni.

107

108## Hol kell értékelni őket

109

110Frontend, backend vagy edge? attól függ.

111

112Ha a zászló az elrendezésre, a másolásra vagy a beépítésre vonatkozik, az előtér rendben van. Ha engedélyekre, számlázásra, korlátokra vagy bizalmas adatokra vonatkozik, akkor a háttérben kell lennie. Ha ez útválasztást vagy nagy forgalmú kísérleteket foglal magában, az élnek lehet értelme.

113

114Az egyszerű szabály: a frontend javíthatja az élményt, de nem ez lehet az egyetlen biztonsági akadály.

115

116## Következtetés

117

118A jól sikerült feature flag megváltoztatja a termeléshez való viszonyt. Nem szüntetik meg a kockázatot, de kisebbé és kezelhetőbbé teszik. Lehet szeletekben elengedni, megfigyelni, megállni, visszamenni, tanulni.

119

120Az OpenFeature tiszta alapot ad: egy közös API, cserélhető szolgáltatókat és egy rendezettebb módszert a rendszer bővítésére. De a fegyelem a tiéd marad: biztonságos alapértelmezések, egyértelmű nevek, mutatók, tulajdonosok és tisztaság.

121

122A legjobb zászló az, amely segít nyugodtan elengedni, majd eltűnik, amikor már nincs rá szükség.

123

124## Források

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