Feature flag: zwolnij bez wstrzymywania oddechu

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

:Feature flag: zwolnij bez wstrzymywania oddechulines 1-131 (END) — press 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}

15return oldCheckout(input);

16```

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.

20## Gdzie pojawia się OpenFeature

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.

24Aplikacja pyta:

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

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.

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

38## Kontekst to połowa sukcesu

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

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.

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.

51## Rozsądne wdrożenie

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

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.

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?”.

65## Kill switch: najpierw je przygotuj

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.

69Dobre kill switch musi być:

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ć.

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

79## Obserwowalność lub brak progresywnego dostarczania

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

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

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?

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

93## Nazewnictwo i własność

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

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

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