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

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

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

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~