Feature flag: uvolněte, aniž byste zadrželi dech

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

1~
2Nasazení je, když kód dorazí do výroby. Vydání je, když to někdo může skutečně použít. Záměna těchto dvou je jedním z nejrychlejších způsobů, jak z každého nasazení udělat trochu napjatý moment.
3~
4feature flag slouží k vložení mezery mezi tyto dva momenty. Můžete nasadit dnes, zítra spustit pro interní tým, pak pro pilotního zákazníka a poté pro 10 % uživatelů. Pokud se něco pokazí, vypněte vlajku. Nemusíte nutně vrátit zpět celé vydání.
5~
6## Vlajka není jen kdyby
7~
8Technicky je to často `if`. Kulturně je to mnohem víc.
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18Tato malá `if` může představovat postupné zavádění, experiment, migraci, podnikové povolení nebo provozní kill switch. Problém je v tom, že pokud to špatně spravujete, může se z toho stát i technický dluh, který zůstane v kódu dva roky.
19~
20## Kde se bere OpenFeature
21~
22OpenFeature je otevřená specifikace pro hodnocení feature flag se společným API. Myšlenka je jednoduchá: kód vaší aplikace by neměl přímo záviset na dodavateli nebo interním systému, který používáte pro příznaky.
23~
24Aplikace se ptá:
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~
34Poskytovatel rozhodne, odkud pravidla pocházejí: SaaS, soubor, interní služba, příznak, konfigurace GitOps. Pokud jednoho dne změníte backend označující funkce, aplikace se nemusí všude přepisovat.
35~
36Toto oddělení vypadá jako architektonický detail, ale je cítit, jak projekt roste.
37~
38## Kontext je polovina úspěchu
39~
40Příznak zapnutí nebo vypnutí pro každého je užitečný, ale omezený. Progresivní doručování žije v kontextu:
41~
42- interní nebo externí uživatel;
43- bezplatný nebo podnikový plán;
44- vesnice;
45- organizace;
46- verze aplikace;
47- stabilní procento provozu.
48~
49Důležitý klíč je `targetingKey`: musí být stabilní. Pokud se mění s každým požadavkem, může uživatel skončit jednou ve variantě A a jednou ve variantě B. Pro experiment je to hrozné, pro pokladnu to může být katastrofální.
50~
51## Rozumné zavedení
52~
53Tok, který se mi líbí, je tento:
54~
551. nasadit s vypnutým praporkem;
562. zapalování pro vývojáře a QA;
573. zapnutí pro pilotního zákazníka nebo nájemce;
584. 5% zavedení;
595. zavedení na 25 %;
606. 100% zavedení;
617. odstranění starého kódu a vlajky.
62~
63Často zapomínaný bod je ten poslední. Dočasná vlajka musí mít datum smrti. Pokud to zůstane navždy, každý budoucí refaktor se bude muset zeptat: "ale je tato větev stále užitečná?".
64~
65## Kill switch: nejprve je připravte
66~
67kill switch je příznak, který vás zachrání, když si s vámi začne hrát externí závislost, úloha spotřebovává příliš mnoho zdrojů nebo nová logika vytváří podivné chyby.
68~
69Dobrý kill switch musí být:
70~
71- snadné najít;
72- dokumentováno v runbooku;
73- občas testováno;
74- pozorovatelné při aktivaci;
75- nezávislé, pokud možno, na části, která by se mohla zlomit.
76~
77Nejhorší je při nehodě zjistit, že vlajka existuje, ale nikdo neví, jestli ještě funguje.
78~
79## Pozorovatelnost nebo neprogresivní doručení
80~
81Zapnutí funkce na 10 % bez pohledu na metriky je jen optimismus s více kroky.
82~
83Každé vydání by mělo odpovědět na jednoduché otázky:
84~
85- přibylo chyb?
86- změnila se latence?
87- dokončí uživatelé tok?
88- je více lístků nebo opakování?
89- ovlivňuje varianta pouze jeden segment?
90~
91OpenFeature podporuje háčky kolem vyhodnocování příznaků. Jsou užitečné pro protokolování chyb, přidávání metrik nebo propojení hodnocení s trace.
92~
93## Pojmenování a vlastnictví
94~
95Na jménech záleží. `new_ui` neříká nic. `checkout.v2.enabled` říká mnohem víc.
96~
97Pro každou vlajku bych označil alespoň:
98~
99- jméno;
100- popis;
101- vlastník;
102- bezpečné výchozí nastavení;
103- důvod, proč existuje;
104- datum nebo podmínka odstranění.
105~
106Vlajka bez vlastníka je téměř vždy vlajkou, kterou nikdo nevymaže.
107~
108## Kde je hodnotit
109~
110Frontend, backend nebo edge? Závisí.
111~
112Pokud je příznak pro rozvržení, kopírování nebo začlenění, frontend je v pořádku. Pokud jde o oprávnění, fakturaci, limity nebo citlivá data, musí být na backendu. Pokud to zahrnuje směrování nebo experimenty s vysokým provozem, může mít okraj smysl.
113~
114Jednoduché pravidlo: frontend může zlepšit zážitek, ale neměl by být jedinou bezpečnostní bariérou.
115~
116## Závěr
117~
118Dobře provedené feature flag mění vztah k produkci. Neeliminují riziko, ale dělají ho menší a lépe zvládnutelný. Můžete se uvolnit v řezech, pozorovat, zastavit se, vrátit se, učit se.
119~
120OpenFeature přidává čistý základ: společný API, zaměnitelné poskytovatele a přehlednější způsob, jak systém rozvíjet. Ale disciplína zůstává na vás: bezpečné výchozí hodnoty, jasná jména, metriky, vlastníci a čistota.
121~
122Nejlepší vlajka je ta, která vám pomůže se klidně uvolnit a pak zmizí, když už není potřeba.
123~
124## Zdroje
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

2Nasazení je, když kód dorazí do výroby. Vydání je, když to někdo může skutečně použít. Záměna těchto dvou je jedním z nejrychlejších způsobů, jak z každého nasazení udělat trochu napjatý moment.

4feature flag slouží k vložení mezery mezi tyto dva momenty. Můžete nasadit dnes, zítra spustit pro interní tým, pak pro pilotního zákazníka a poté pro 10 % uživatelů. Pokud se něco pokazí, vypněte vlajku. Nemusíte nutně vrátit zpět celé vydání.

6## Vlajka není jen kdyby

8Technicky je to často `if`. Kulturně je to mnohem víc.

10```typescript

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

12 return newCheckout(input);

13}

14~

15return oldCheckout(input);

16```

17~

18Tato malá `if` může představovat postupné zavádění, experiment, migraci, podnikové povolení nebo provozní kill switch. Problém je v tom, že pokud to špatně spravujete, může se z toho stát i technický dluh, který zůstane v kódu dva roky.

19~

20## Kde se bere OpenFeature

21~

22OpenFeature je otevřená specifikace pro hodnocení feature flag se společným API. Myšlenka je jednoduchá: kód vaší aplikace by neměl přímo záviset na dodavateli nebo interním systému, který používáte pro příznaky.

23~

24Aplikace se ptá:

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~

34Poskytovatel rozhodne, odkud pravidla pocházejí: SaaS, soubor, interní služba, příznak, konfigurace GitOps. Pokud jednoho dne změníte backend označující funkce, aplikace se nemusí všude přepisovat.

35~

36Toto oddělení vypadá jako architektonický detail, ale je cítit, jak projekt roste.

37~

38## Kontext je polovina úspěchu

39~

40Příznak zapnutí nebo vypnutí pro každého je užitečný, ale omezený. Progresivní doručování žije v kontextu:

41~

42- interní nebo externí uživatel;

43- bezplatný nebo podnikový plán;

44- vesnice;

45- organizace;

46- verze aplikace;

47- stabilní procento provozu.

48~

49Důležitý klíč je `targetingKey`: musí být stabilní. Pokud se mění s každým požadavkem, může uživatel skončit jednou ve variantě A a jednou ve variantě B. Pro experiment je to hrozné, pro pokladnu to může být katastrofální.

50~

51## Rozumné zavedení

52~

53Tok, který se mi líbí, je tento:

54~

551. nasadit s vypnutým praporkem;

562. zapalování pro vývojáře a QA;

573. zapnutí pro pilotního zákazníka nebo nájemce;

584. 5% zavedení;

595. zavedení na 25 %;

606. 100% zavedení;

617. odstranění starého kódu a vlajky.

62~

63Často zapomínaný bod je ten poslední. Dočasná vlajka musí mít datum smrti. Pokud to zůstane navždy, každý budoucí refaktor se bude muset zeptat: "ale je tato větev stále užitečná?".

64~

65## Kill switch: nejprve je připravte

66~

67kill switch je příznak, který vás zachrání, když si s vámi začne hrát externí závislost, úloha spotřebovává příliš mnoho zdrojů nebo nová logika vytváří podivné chyby.

68~

69Dobrý kill switch musí být:

70~

71- snadné najít;

72- dokumentováno v runbooku;

73- občas testováno;

74- pozorovatelné při aktivaci;

75- nezávislé, pokud možno, na části, která by se mohla zlomit.

76~

77Nejhorší je při nehodě zjistit, že vlajka existuje, ale nikdo neví, jestli ještě funguje.

78~

79## Pozorovatelnost nebo neprogresivní doručení

80~

81Zapnutí funkce na 10 % bez pohledu na metriky je jen optimismus s více kroky.

82~

83Každé vydání by mělo odpovědět na jednoduché otázky:

84~

85- přibylo chyb?

86- změnila se latence?

87- dokončí uživatelé tok?

88- je více lístků nebo opakování?

89- ovlivňuje varianta pouze jeden segment?

90~

91OpenFeature podporuje háčky kolem vyhodnocování příznaků. Jsou užitečné pro protokolování chyb, přidávání metrik nebo propojení hodnocení s trace.

92~

93## Pojmenování a vlastnictví

94~

95Na jménech záleží. `new_ui` neříká nic. `checkout.v2.enabled` říká mnohem víc.

96~

97Pro každou vlajku bych označil alespoň:

98~

99- jméno;

100- popis;

101- vlastník;

102- bezpečné výchozí nastavení;

103- důvod, proč existuje;

104- datum nebo podmínka odstranění.

105~

106Vlajka bez vlastníka je téměř vždy vlajkou, kterou nikdo nevymaže.

107~

108## Kde je hodnotit

109~

110Frontend, backend nebo edge? Závisí.

111~

112Pokud je příznak pro rozvržení, kopírování nebo začlenění, frontend je v pořádku. Pokud jde o oprávnění, fakturaci, limity nebo citlivá data, musí být na backendu. Pokud to zahrnuje směrování nebo experimenty s vysokým provozem, může mít okraj smysl.

113~

114Jednoduché pravidlo: frontend může zlepšit zážitek, ale neměl by být jedinou bezpečnostní bariérou.

115~

116## Závěr

117~

118Dobře provedené feature flag mění vztah k produkci. Neeliminují riziko, ale dělají ho menší a lépe zvládnutelný. Můžete se uvolnit v řezech, pozorovat, zastavit se, vrátit se, učit se.

119~

120OpenFeature přidává čistý základ: společný API, zaměnitelné poskytovatele a přehlednější způsob, jak systém rozvíjet. Ale disciplína zůstává na vás: bezpečné výchozí hodnoty, jasná jména, metriky, vlastníci a čistota.

121~

122Nejlepší vlajka je ta, která vám pomůže se klidně uvolnit a pak zmizí, když už není potřeba.

123~

124## Zdroje

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~