Wdroż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.

feature 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ę.

Flaga to nie tylko pytanie „jeśli”.

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

if (await flags.isEnabled('checkout.v2.enabled', context)) {
  return newCheckout(input);
}

return oldCheckout(input);

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

Gdzie pojawia się OpenFeature

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

Aplikacja pyta:

const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
  targetingKey: user.id,
  plan: user.plan,
  country: user.country,
});

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

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

Kontekst to połowa sukcesu

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

• użytkownik wewnętrzny lub zewnętrzny;
• plan bezpłatny lub korporacyjny;
• wieś;
• organizacja;
• wersja aplikacji;
• stabilny procent ruchu.

Waż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.

Rozsądne wdrożenie

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

1. rozmieścić z wypuszczoną flagą;
2. zapłon dla programistów i QA;
3. uruchomienie dla klienta pilotażowego lub najemcy;
4. 5% wdrożenia;
5. wdrożenie na poziomie 25%;
6. 100% wdrożenia;
7. usunięcie starego kodu i flagi.

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

Kill switch: najpierw je przygotuj

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

Dobre kill switch musi być:

• łatwe do znalezienia;
• udokumentowane w elemencie Runbook;
• testowany sporadycznie;
• obserwowalne po aktywacji;
• niezależny, w miarę możliwości, od części, która może się zepsuć.

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

Obserwowalność lub brak progresywnego dostarczania

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

Każdy rollout powinien odpowiadać na proste pytania:

• czy wzrosła liczba błędów?
• czy opóźnienie uległo zmianie?
• czy użytkownicy kończą przepływ?
• czy jest więcej biletów lub ponownych prób?
• czy wariant wpływa tylko na jeden segment?

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

Nazewnictwo i własność

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

Dla każdej flagi zaznaczyłbym co najmniej:

• imię;
• opis;
• właściciel;
• bezpieczne ustawienie domyślne;
• powód, dla którego istnieje;
• data lub stan usunięcia.

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

Gdzie je ocenić

Frontend, backend czy Edge? Zależy.

Jeś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.

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

Wniosek

Dobrze 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ę.

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

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

Źródła

• OpenFeature: Introduction
• OpenFeature: Node.js SDK
• OpenFeature Specification: Flag Evaluation API
• OpenFeature: Hooks
• CNCF: OpenFeature