Feature flag: zwolnij bez wstrzymywania oddechu

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

1~
2Wdrożenie ma miejsce, gdy kod trafia do środowiska produkcyjnego. Zwolnienie ma miejsce wtedy, gdy ktoś może z niego faktycznie skorzystać. Pomieszanie tych dwóch elementów to jeden z najszybszych sposobów, aby każde wdrożenie było trochę napięte.
3~
4feature flag służy do umieszczenia odstępu pomiędzy tymi dwoma momentami. Możesz wdrożyć dzisiaj, uruchomić jutro dla zespołu wewnętrznego, następnie dla klienta pilotażowego, a następnie dla 10% użytkowników. Jeśli coś pójdzie nie tak, wyłącz flagę. Niekoniecznie musisz wycofywać całą wersję.
5~
6## Flaga to nie tylko pytanie „jeśli”.
7~
8Technicznie rzecz biorąc, często jest to `if`. Kulturalnie to dużo więcej.
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18Te małe `if` może oznaczać stopniowe wdrażanie, eksperyment, migrację, zezwolenie na prowadzenie działalności lub kill switch operacyjne. Problem w tym, że jeśli nie zarządzasz nim dobrze, może to również stać się długiem technicznym, który pozostaje w kodzie przez dwa lata.
19~
20## Gdzie pojawia się OpenFeature
21~
22OpenFeature to otwarta specyfikacja do obliczania feature flag ze wspólnym API. Pomysł jest prosty: kod aplikacji nie powinien zależeć bezpośrednio od dostawcy lub wewnętrznego systemu, którego używasz do tworzenia flag.
23~
24Aplikacja pyta:
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~
34Dostawca decyduje, skąd pochodzą reguły: SaaS, plik, usługa wewnętrzna, flaga, konfiguracja GitOps. Jeśli pewnego dnia zmienisz backend flagowania funkcji, aplikacja nie będzie musiała być wszędzie przepisana.
35~
36To oddzielenie wydaje się detalem architektonicznym, ale jest odczuwalne w miarę rozwoju projektu.
37~
38## Kontekst to połowa sukcesu
39~
40Flaga włączenia lub wyłączenia dla wszystkich jest przydatna, ale ograniczona. Stopniowe dostarczanie żyje w kontekście:
41~
42- użytkownik wewnętrzny lub zewnętrzny;
43- plan bezpłatny lub korporacyjny;
44- wieś;
45- organizacja;
46- wersja aplikacji;
47- stabilny procent ruchu.
48~
49Ważnym kluczem jest `targetingKey`: musi być stabilny. Jeśli będzie się to zmieniać przy każdym żądaniu, użytkownik może raz znaleźć się w wariancie A, a raz w wariancie B. Dla eksperymentu jest to okropne, dla kasy może to być katastrofalne.
50~
51## Rozsądne wdrożenie
52~
53Przepływ, który mi się podoba, to:
54~
551. rozmieścić z wypuszczoną flagą;
562. zapłon dla programistów i QA;
573. uruchomienie dla klienta pilotażowego lub najemcy;
584. 5% wdrożenia;
595. wdrożenie na poziomie 25%;
606. 100% wdrożenia;
617. usunięcie starego kodu i flagi.
62~
63Często zapominanym punktem jest ten ostatni. Flaga tymczasowa musi mieć datę śmierci. Jeśli pozostanie na zawsze, każdy przyszły refaktor będzie musiał zadać sobie pytanie: „ale czy ta gałąź jest nadal przydatna?”.
64~
65## Kill switch: najpierw je przygotuj
66~
67kill switch to flaga, która Cię ratuje, gdy zewnętrzna zależność zaczyna Ci przeszkadzać, zadanie zużywa zbyt wiele zasobów lub nowa logika generuje dziwne błędy.
68~
69Dobre kill switch musi być:
70~
71- łatwe do znalezienia;
72- udokumentowane w elemencie Runbook;
73- testowany sporadycznie;
74- obserwowalne po aktywacji;
75- niezależny, w miarę możliwości, od części, która może się zepsuć.
76~
77Najgorsze jest to, że w trakcie wypadku okazuje się, że flaga istnieje, ale nikt nie wie, czy nadal działa.
78~
79## Obserwowalność lub brak progresywnego dostarczania
80~
81Włączenie funkcji na poziomie 10% bez sprawdzania wskaźników to po prostu optymizm złożony z wielu kroków.
82~
83Każdy rollout powinien odpowiadać na proste pytania:
84~
85- czy wzrosła liczba błędów?
86- czy opóźnienie uległo zmianie?
87- czy użytkownicy kończą przepływ?
88- czy jest więcej biletów lub ponownych prób?
89- czy wariant wpływa tylko na jeden segment?
90~
91OpenFeature obsługuje zaczepy dotyczące oceny flagi. Są przydatne do rejestrowania błędów, dodawania wskaźników lub łączenia oceny z trace.
92~
93## Nazewnictwo i własność
94~
95Imiona mają znaczenie. `new_ui` nic nie mówi. `checkout.v2.enabled` mówi znacznie więcej.
96~
97Dla każdej flagi zaznaczyłbym co najmniej:
98~
99- imię;
100- opis;
101- właściciel;
102- bezpieczne ustawienie domyślne;
103- powód, dla którego istnieje;
104- data lub stan usunięcia.
105~
106Flaga bez właściciela jest prawie zawsze flagą, której nikt nie usunie.
107~
108## Gdzie je ocenić
109~
110Frontend, backend czy Edge? Zależy.
111~
112Jeśli flaga dotyczy układu, kopiowania lub dołączania, frontend jest w porządku. Jeśli dotyczy to uprawnień, rozliczeń, limitów lub wrażliwych danych, musi znajdować się na backendzie. Jeśli wiąże się to z routingiem lub eksperymentami o dużym natężeniu ruchu, rozwiązanie brzegowe może mieć sens.
113~
114Prosta zasada: frontend może poprawić doświadczenie, ale nie powinien być jedyną barierą bezpieczeństwa.
115~
116## Wniosek
117~
118Dobrze zrobione feature flag zmienia relację z produkcją. Nie eliminują ryzyka, ale sprawiają, że jest ono mniejsze i łatwiejsze do zarządzania. Możesz uwalniać w plasterkach, obserwować, zatrzymywać się, wracać, uczyć się.
119~
120OpenFeature dodaje czysty fundament: wspólnego API, wymiennych dostawców i bardziej przejrzysty sposób rozwijania systemu. Ale dyscyplina pozostaje Twoja: bezpieczne ustawienia domyślne, jasne nazwy, metryki, właściciele i czystość.
121~
122Najlepsza flaga to taka, która pomaga spokojnie wypuścić, a potem znika, gdy nie jest już potrzebna.
123~
124## Źródła
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

2Wdrożenie ma miejsce, gdy kod trafia do środowiska produkcyjnego. Zwolnienie ma miejsce wtedy, gdy ktoś może z niego faktycznie skorzystać. Pomieszanie tych dwóch elementów to jeden z najszybszych sposobów, aby każde wdrożenie było trochę napięte.

4feature flag służy do umieszczenia odstępu pomiędzy tymi dwoma momentami. Możesz wdrożyć dzisiaj, uruchomić jutro dla zespołu wewnętrznego, następnie dla klienta pilotażowego, a następnie dla 10% użytkowników. Jeśli coś pójdzie nie tak, wyłącz flagę. Niekoniecznie musisz wycofywać całą wersję.

6## Flaga to nie tylko pytanie „jeśli”.

8Technicznie rzecz biorąc, często jest to `if`. Kulturalnie to dużo więcej.

10```typescript

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

12 return newCheckout(input);

13}

14~

15return oldCheckout(input);

16```

17~

18Te małe `if` może oznaczać stopniowe wdrażanie, eksperyment, migrację, zezwolenie na prowadzenie działalności lub kill switch operacyjne. Problem w tym, że jeśli nie zarządzasz nim dobrze, może to również stać się długiem technicznym, który pozostaje w kodzie przez dwa lata.

19~

20## Gdzie pojawia się OpenFeature

21~

22OpenFeature to otwarta specyfikacja do obliczania feature flag ze wspólnym API. Pomysł jest prosty: kod aplikacji nie powinien zależeć bezpośrednio od dostawcy lub wewnętrznego systemu, którego używasz do tworzenia flag.

23~

24Aplikacja pyta:

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~

34Dostawca decyduje, skąd pochodzą reguły: SaaS, plik, usługa wewnętrzna, flaga, konfiguracja GitOps. Jeśli pewnego dnia zmienisz backend flagowania funkcji, aplikacja nie będzie musiała być wszędzie przepisana.

35~

36To oddzielenie wydaje się detalem architektonicznym, ale jest odczuwalne w miarę rozwoju projektu.

37~

38## Kontekst to połowa sukcesu

39~

40Flaga włączenia lub wyłączenia dla wszystkich jest przydatna, ale ograniczona. Stopniowe dostarczanie żyje w kontekście:

41~

42- użytkownik wewnętrzny lub zewnętrzny;

43- plan bezpłatny lub korporacyjny;

44- wieś;

45- organizacja;

46- wersja aplikacji;

47- stabilny procent ruchu.

48~

49Ważnym kluczem jest `targetingKey`: musi być stabilny. Jeśli będzie się to zmieniać przy każdym żądaniu, użytkownik może raz znaleźć się w wariancie A, a raz w wariancie B. Dla eksperymentu jest to okropne, dla kasy może to być katastrofalne.

50~

51## Rozsądne wdrożenie

52~

53Przepływ, który mi się podoba, to:

54~

551. rozmieścić z wypuszczoną flagą;

562. zapłon dla programistów i QA;

573. uruchomienie dla klienta pilotażowego lub najemcy;

584. 5% wdrożenia;

595. wdrożenie na poziomie 25%;

606. 100% wdrożenia;

617. usunięcie starego kodu i flagi.

62~

63Często zapominanym punktem jest ten ostatni. Flaga tymczasowa musi mieć datę śmierci. Jeśli pozostanie na zawsze, każdy przyszły refaktor będzie musiał zadać sobie pytanie: „ale czy ta gałąź jest nadal przydatna?”.

64~

65## Kill switch: najpierw je przygotuj

66~

67kill switch to flaga, która Cię ratuje, gdy zewnętrzna zależność zaczyna Ci przeszkadzać, zadanie zużywa zbyt wiele zasobów lub nowa logika generuje dziwne błędy.

68~

69Dobre kill switch musi być:

70~

71- łatwe do znalezienia;

72- udokumentowane w elemencie Runbook;

73- testowany sporadycznie;

74- obserwowalne po aktywacji;

75- niezależny, w miarę możliwości, od części, która może się zepsuć.

76~

77Najgorsze jest to, że w trakcie wypadku okazuje się, że flaga istnieje, ale nikt nie wie, czy nadal działa.

78~

79## Obserwowalność lub brak progresywnego dostarczania

80~

81Włączenie funkcji na poziomie 10% bez sprawdzania wskaźników to po prostu optymizm złożony z wielu kroków.

82~

83Każdy rollout powinien odpowiadać na proste pytania:

84~

85- czy wzrosła liczba błędów?

86- czy opóźnienie uległo zmianie?

87- czy użytkownicy kończą przepływ?

88- czy jest więcej biletów lub ponownych prób?

89- czy wariant wpływa tylko na jeden segment?

90~

91OpenFeature obsługuje zaczepy dotyczące oceny flagi. Są przydatne do rejestrowania błędów, dodawania wskaźników lub łączenia oceny z trace.

92~

93## Nazewnictwo i własność

94~

95Imiona mają znaczenie. `new_ui` nic nie mówi. `checkout.v2.enabled` mówi znacznie więcej.

96~

97Dla każdej flagi zaznaczyłbym co najmniej:

98~

99- imię;

100- opis;

101- właściciel;

102- bezpieczne ustawienie domyślne;

103- powód, dla którego istnieje;

104- data lub stan usunięcia.

105~

106Flaga bez właściciela jest prawie zawsze flagą, której nikt nie usunie.

107~

108## Gdzie je ocenić

109~

110Frontend, backend czy Edge? Zależy.

111~

112Jeśli flaga dotyczy układu, kopiowania lub dołączania, frontend jest w porządku. Jeśli dotyczy to uprawnień, rozliczeń, limitów lub wrażliwych danych, musi znajdować się na backendzie. Jeśli wiąże się to z routingiem lub eksperymentami o dużym natężeniu ruchu, rozwiązanie brzegowe może mieć sens.

113~

114Prosta zasada: frontend może poprawić doświadczenie, ale nie powinien być jedyną barierą bezpieczeństwa.

115~

116## Wniosek

117~

118Dobrze zrobione feature flag zmienia relację z produkcją. Nie eliminują ryzyka, ale sprawiają, że jest ono mniejsze i łatwiejsze do zarządzania. Możesz uwalniać w plasterkach, obserwować, zatrzymywać się, wracać, uczyć się.

119~

120OpenFeature dodaje czysty fundament: wspólnego API, wymiennych dostawców i bardziej przejrzysty sposób rozwijania systemu. Ale dyscyplina pozostaje Twoja: bezpieczne ustawienia domyślne, jasne nazwy, metryki, właściciele i czystość.

121~

122Najlepsza flaga to taka, która pomaga spokojnie wypuścić, a potem znika, gdy nie jest już potrzebna.

123~

124## Źródła

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~