Feature flag: eliberați fără să vă țineți respirația

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

1~
2Implementarea este atunci când codul ajunge în producție. Eliberarea este atunci când cineva o poate folosi efectiv. Confuzia celor două este una dintre cele mai rapide modalități de a face din fiecare implementare un moment puțin tensionat.
3~
4feature flag servesc pentru a pune spațiu între aceste două momente. Puteți implementa astăzi, puteți activa mâine pentru echipa internă, apoi pentru un client pilot, apoi pentru 10% dintre utilizatori. Dacă ceva nu merge bine, opriți steagul. Nu trebuie neapărat să anulați întreaga versiune.
5~
6## Steagul nu este doar un dacă
7~
8Din punct de vedere tehnic, este adesea un `if`. Cultural este mult mai mult.
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18Acel mic `if` poate reprezenta o lansare treptată, un experiment, o migrare, un permis de întreprindere sau un kill switch operațional. Problema este că dacă nu o gestionezi bine, poate deveni și datorie tehnică care rămâne în cod doi ani.
19~
20## Unde intervine OpenFeature
21~
22OpenFeature este o specificație deschisă pentru evaluarea feature flag cu un API comun. Ideea este simplă: codul aplicației dvs. nu ar trebui să depindă direct de furnizor sau de sistemul intern pe care îl utilizați pentru steaguri.
23~
24Aplicația întreabă:
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~
34Furnizorul decide de unde provin regulile: SaaS, fișier, serviciu intern, flagd, configurație GitOps. Dacă într-o zi schimbați backend-ul de semnalizare a caracteristicilor, aplicația nu trebuie să fie rescrisă peste tot.
35~
36Această separare pare un detaliu arhitectural, dar se simte pe măsură ce proiectul crește.
37~
38## Contextul este jumătate din bătălie
39~
40Un steag pornit sau oprit pentru toată lumea este util, dar limitat. Livrarea progresivă trăiește în context:
41~
42- utilizator intern sau extern;
43- plan gratuit sau de întreprindere;
44- sat;
45- organizare;
46- versiunea aplicației;
47- procent stabil de trafic.
48~
49Cheia importantă este `targetingKey`: trebuie să fie stabilă. Dacă se schimbă la fiecare solicitare, un utilizator poate ajunge o dată în varianta A și o dată în varianta B. Pentru un experiment este groaznic, pentru un checkout poate fi dezastruos.
50~
51## O lansare sensibilă
52~
53Un flux care îmi place este acesta:
54~
551. desfășurare cu flag off;
562. aprindere pentru dezvoltatori și QA;
573. pornire pentru un client pilot sau chiriaș;
584. 5% lansare;
595. lansare la 25%;
606. lansare 100%;
617. eliminarea vechiului cod și steag.
62~
63Punctul adesea uitat este ultimul. Un steag temporar trebuie să aibă o dată de deces. Dacă rămâne pentru totdeauna, fiecare viitor refactor va trebui să se întrebe: „dar mai este utilă această ramură?”.
64~
65## Kill switch: pregătiți-le mai întâi
66~
67kill switch este indicatorul care te salvează atunci când o dependență externă începe să te încurce, un job consumă prea multe resurse sau o nouă logică produce erori ciudate.
68~
69Un kill switch bun trebuie să fie:
70~
71- usor de gasit;
72- documentat în runbook;
73- testat ocazional;
74- observabil când este activat;
75- independent, pe cât posibil, de partea care s-ar putea rupe.
76~
77Cel mai rău este să descoperi în timpul accidentului că steagul există, dar nimeni nu știe dacă mai funcționează.
78~
79## Observabilitate sau nu livrare progresivă
80~
81Activarea unei funcții la 10% fără să se uite la valori este doar optimism cu mai mulți pași.
82~
83Fiecare lansare ar trebui să răspundă la întrebări simple:
84~
85- au crescut erorile?
86- s-a schimbat latența?
87- utilizatorii completează fluxul?
88- există mai multe bilete sau reîncercări?
89- o variantă afectează doar un segment?
90~
91OpenFeature acceptă cârlige în jurul evaluării steagului. Sunt utile pentru înregistrarea erorilor, adăugarea de valori sau legarea evaluării la un trace.
92~
93## Denumirea și proprietatea
94~
95Numele contează. `new_ui` nu spune nimic. `checkout.v2.enabled` spune mult mai multe.
96~
97Pentru fiecare steag aș marca cel puțin:
98~
99- nume;
100- descriere;
101- proprietar;
102- implicit sigur;
103- motivul pentru care există;
104- data sau starea înlăturării.
105~
106Un steag fără proprietar este aproape întotdeauna un steag pe care nimeni nu îl va șterge.
107~
108## Unde să le evaluăm
109~
110Frontend, backend sau edge? Depinde.
111~
112Dacă marcajul este pentru aspect, copiere sau onboarding, interfața este în regulă. Dacă se referă la permisiuni, facturare, limite sau date sensibile, trebuie să fie pe backend. Dacă implică rutare sau experimente cu trafic ridicat, marginea poate avea sens.
113~
114Regula simplă: frontend-ul poate îmbunătăți experiența, dar nu ar trebui să fie singura barieră de securitate.
115~
116## Concluzie
117~
118feature flag bine făcut schimbă relația cu producția. Ele nu elimină riscul, dar îl fac mai mic și mai ușor de gestionat. Poți să eliberezi în felii, să observi, să te oprești, să te întorci, să înveți.
119~
120OpenFeature adaugă o bază curată: un API obișnuit, furnizori interschimbabili și o modalitate mai ordonată de a dezvolta sistemul. Dar disciplina rămâne a ta: valori implicite sigure, nume clare, valori, proprietari și curățenie.
121~
122Cel mai bun steag este cel care te ajută să te eliberezi calm și apoi dispare când nu mai este nevoie.
123~
124## Surse
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

2Implementarea este atunci când codul ajunge în producție. Eliberarea este atunci când cineva o poate folosi efectiv. Confuzia celor două este una dintre cele mai rapide modalități de a face din fiecare implementare un moment puțin tensionat.

4feature flag servesc pentru a pune spațiu între aceste două momente. Puteți implementa astăzi, puteți activa mâine pentru echipa internă, apoi pentru un client pilot, apoi pentru 10% dintre utilizatori. Dacă ceva nu merge bine, opriți steagul. Nu trebuie neapărat să anulați întreaga versiune.

6## Steagul nu este doar un dacă

8Din punct de vedere tehnic, este adesea un `if`. Cultural este mult mai mult.

10```typescript

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

12 return newCheckout(input);

13}

14~

15return oldCheckout(input);

16```

17~

18Acel mic `if` poate reprezenta o lansare treptată, un experiment, o migrare, un permis de întreprindere sau un kill switch operațional. Problema este că dacă nu o gestionezi bine, poate deveni și datorie tehnică care rămâne în cod doi ani.

19~

20## Unde intervine OpenFeature

21~

22OpenFeature este o specificație deschisă pentru evaluarea feature flag cu un API comun. Ideea este simplă: codul aplicației dvs. nu ar trebui să depindă direct de furnizor sau de sistemul intern pe care îl utilizați pentru steaguri.

23~

24Aplicația întreabă:

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~

34Furnizorul decide de unde provin regulile: SaaS, fișier, serviciu intern, flagd, configurație GitOps. Dacă într-o zi schimbați backend-ul de semnalizare a caracteristicilor, aplicația nu trebuie să fie rescrisă peste tot.

35~

36Această separare pare un detaliu arhitectural, dar se simte pe măsură ce proiectul crește.

37~

38## Contextul este jumătate din bătălie

39~

40Un steag pornit sau oprit pentru toată lumea este util, dar limitat. Livrarea progresivă trăiește în context:

41~

42- utilizator intern sau extern;

43- plan gratuit sau de întreprindere;

44- sat;

45- organizare;

46- versiunea aplicației;

47- procent stabil de trafic.

48~

49Cheia importantă este `targetingKey`: trebuie să fie stabilă. Dacă se schimbă la fiecare solicitare, un utilizator poate ajunge o dată în varianta A și o dată în varianta B. Pentru un experiment este groaznic, pentru un checkout poate fi dezastruos.

50~

51## O lansare sensibilă

52~

53Un flux care îmi place este acesta:

54~

551. desfășurare cu flag off;

562. aprindere pentru dezvoltatori și QA;

573. pornire pentru un client pilot sau chiriaș;

584. 5% lansare;

595. lansare la 25%;

606. lansare 100%;

617. eliminarea vechiului cod și steag.

62~

63Punctul adesea uitat este ultimul. Un steag temporar trebuie să aibă o dată de deces. Dacă rămâne pentru totdeauna, fiecare viitor refactor va trebui să se întrebe: „dar mai este utilă această ramură?”.

64~

65## Kill switch: pregătiți-le mai întâi

66~

67kill switch este indicatorul care te salvează atunci când o dependență externă începe să te încurce, un job consumă prea multe resurse sau o nouă logică produce erori ciudate.

68~

69Un kill switch bun trebuie să fie:

70~

71- usor de gasit;

72- documentat în runbook;

73- testat ocazional;

74- observabil când este activat;

75- independent, pe cât posibil, de partea care s-ar putea rupe.

76~

77Cel mai rău este să descoperi în timpul accidentului că steagul există, dar nimeni nu știe dacă mai funcționează.

78~

79## Observabilitate sau nu livrare progresivă

80~

81Activarea unei funcții la 10% fără să se uite la valori este doar optimism cu mai mulți pași.

82~

83Fiecare lansare ar trebui să răspundă la întrebări simple:

84~

85- au crescut erorile?

86- s-a schimbat latența?

87- utilizatorii completează fluxul?

88- există mai multe bilete sau reîncercări?

89- o variantă afectează doar un segment?

90~

91OpenFeature acceptă cârlige în jurul evaluării steagului. Sunt utile pentru înregistrarea erorilor, adăugarea de valori sau legarea evaluării la un trace.

92~

93## Denumirea și proprietatea

94~

95Numele contează. `new_ui` nu spune nimic. `checkout.v2.enabled` spune mult mai multe.

96~

97Pentru fiecare steag aș marca cel puțin:

98~

99- nume;

100- descriere;

101- proprietar;

102- implicit sigur;

103- motivul pentru care există;

104- data sau starea înlăturării.

105~

106Un steag fără proprietar este aproape întotdeauna un steag pe care nimeni nu îl va șterge.

107~

108## Unde să le evaluăm

109~

110Frontend, backend sau edge? Depinde.

111~

112Dacă marcajul este pentru aspect, copiere sau onboarding, interfața este în regulă. Dacă se referă la permisiuni, facturare, limite sau date sensibile, trebuie să fie pe backend. Dacă implică rutare sau experimente cu trafic ridicat, marginea poate avea sens.

113~

114Regula simplă: frontend-ul poate îmbunătăți experiența, dar nu ar trebui să fie singura barieră de securitate.

115~

116## Concluzie

117~

118feature flag bine făcut schimbă relația cu producția. Ele nu elimină riscul, dar îl fac mai mic și mai ușor de gestionat. Poți să eliberezi în felii, să observi, să te oprești, să te întorci, să înveți.

119~

120OpenFeature adaugă o bază curată: un API obișnuit, furnizori interschimbabili și o modalitate mai ordonată de a dezvolta sistemul. Dar disciplina rămâne a ta: valori implicite sigure, nume clare, valori, proprietari și curățenie.

121~

122Cel mai bun steag este cel care te ajută să te eliberezi calm și apoi dispare când nu mai este nevoie.

123~

124## Surse

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~