Product Engineering

Feature Flags

Feature Flags oddzielają deployment kodu od releasu funkcji. Dzięki nim możesz mergować kod do głównej gałęzi codziennie — i decydować kiedy i dla kogo dana funkcja jest widoczna.

Typów flag

Popularnych platform

Kill Switch

Kluczowa korzyść

Flag Debt

Ryzyko bez czyszczenia

4 typy Feature Flags

Każdy typ flagi ma inny cel, lifecycle i ryzyko. Mieszanie typów bez świadomości prowadzi do flag graveyardów — starych flag których nikt nie usuwa.

Release Flag

Cel

Ukrycie niedokończonego kodu w produkcji podczas developmentu

Kiedy stosować

Gdy chcesz mergować do main bez releaseowania feature

Lifecycle

Usuwana gdy feature jest gotowy i stabliany (dni-tygodnie)

Ryzyko

Jeśli nie usunięta — zaśmieca kod i konfunduje innych developerów

Experiment Flag

Cel

A/B test nowej funkcji lub wariantu na % użytkowników

Kiedy stosować

Gdy chcesz zmierzyć czy zmiana poprawia metrykę (konwersja, engagement)

Lifecycle

Usuwana po zakończeniu eksperymentu i decyzji (tygodnie)

Ryzyko

Długo trwające eksperymenty komplikują codebase

Ops Flag

Cel

Sterowanie zachowaniem systemu w runtime bez deploymentu

Kiedy stosować

Kill switch dla problematycznej funkcji, circuit breaker, rate limiting

Lifecycle

Może być stała — to de facto konfiguracja systemu (tygodnie-miesiące)

Ryzyko

Jeśli używana jako długoterminowa konfiguracja — lepiej użyć config service

Permission Flag

Cel

Dostęp do funkcji per plan, klient lub rola użytkownika

Kiedy stosować

Enterprise-only features, beta programs, admin-only tools

Lifecycle

Może być długoterminowa — ale powinna być w entitlement system, nie flagach

Ryzyko

Mieszanie flagów z entitlements komplikuje billing i authorization

Platformy Feature Flags

Wybór platformy zależy od skali, budżetu i potrzeb. Dla prostych use cases wystarczy config file. Dla zaawansowanego targeting i A/B testów — dedykowana platforma.

LaunchDarkly

SaaS (commercial)

Najpopularniejsza komercyjna platforma. SDK dla wszystkich języków, real-time targeting, analityka.

Scale-upy i enterprise z budżetem na narzędzia

Flagsmith

Open-source + SaaS

Open-source alternatywa dla LaunchDarkly. Self-hosted lub cloud. Dobre SDK.

Startupy chcące open-source z opcją hosted

Unleash

Open-source

Popularna open-source platforma z bogatymi targeting options. Self-hosted.

Firmy z zasobami do self-hostingu

Split.io

SaaS (commercial)

Silna w A/B testing + feature flags. Dobra analityka eksperymentów.

Firmy gdzie eksperymenty są priorytetem

Custom (env vars / config)

DIY

Environment variables lub config file. Brak UI, brak targeting — ale zero kosztu.

Wczesne startupy lub proste use cases

Często zadawane pytania

Co to są Feature Flags?

Feature Flags (znane też jako Feature Toggles lub Feature Switches) to technika programistyczna pozwalająca włączać i wyłączać funkcje produktu bez deployowania nowego kodu. Flaga to prosta warunki w kodzie: 'jeśli flaga X jest włączona — pokaż nową funkcję; jeśli wyłączona — pokaż starą'. Feature Flags umożliwiają: deploy kodu bez releasu feature (Continuous Delivery), stopniowe udostępnianie funkcji (rollout 1% → 10% → 100% userów), A/B testowanie nowych funkcji na segmencie użytkowników, szybkie wycofanie feature gdy coś pójdzie źle (kill switch), beta dostęp dla wybranych klientów (early access programs).

Jakie są rodzaje Feature Flags?

Typy Feature Flags: Release Flags — ukrywają niedokończoną funkcję podczas developmentu. Mergowany do main bez impaktu na użytkowników. Usuwane gdy feature jest gotowy. Experiment Flags — A/B test nowej funkcji na % userów. Mierzysz metryki i decydujesz który wariant wygrał. Ops Flags — sterowanie zachowaniem systemu w produkcji bez deploymentu. Np. wyłączenie nieesencjonalnego serwisu podczas incydentu. Permission Flags — dostęp do funkcji dla konkretnych planów, klientów lub ról. Np. Enterprise-only features. Kill Switches — szybkie wyłączenie problematycznej funkcji bez hotfixu i deploymentu.

Jakie są korzyści z Feature Flags?

Korzyści Feature Flags: Continuous Delivery bez ryzyka — deploy code continuously, release kiedy chcesz. Szybsze feedback loops — testuj z prawdziwymi użytkownikami zanim releaseując do wszystkich. Bezpieczniejszy rollout — stopniowe udostępnianie na 1%, 10%, 50%, 100% userów. Szybka reakcja na problemy — kill switch zamiast rollback deploymentu. Personalizacja — różne doświadczenia dla różnych segmentów (plan, rola, region). Feature Flags są kluczowym elementem kultury Continuous Delivery w firmach jak Facebook, LinkedIn, GitHub — gdzie deploy kodu i release feature są osobnymi decyzjami. Ryzyko: tech debt gdy flagi nie są czyszczone — 'flag graveyard' to prawdziwy problem.

Jak wdrożyć Feature Flags?

Wdrożenie Feature Flags: Prosty start — hardcoded boolean w kodzie. Szybki, ale nie dynamiczny i wymaga deploymentu do zmiany. Config file — flagi w pliku konfiguracyjnym lub environment variable. Dynamiczna zmiana bez deploymentu. Feature Flag Service — dedykowana platforma (LaunchDarkly, Flagsmith, Split.io, Unleash) z UI do zarządzania flagami, targeting rules, analytics. Best practices: Nazywaj flagi opisowo (enable_new_checkout_v2 nie flag_123). Dokumentuj cel i planowaną datę usunięcia każdej flagi. Regularnie czyść stare flagi (flag lifecycle management). Testuj oba stany flagi (on i off) w testach automatycznych. Nie używaj flag jako długoterminowej konfiguracji — mają być tymczasowe.

Czym Feature Flags różnią się od A/B Testów?

Feature Flags vs. A/B Testy: A/B Test to eksperyment — randomizujesz użytkowników do wariantu A lub B, mierzysz który wygrywa statystycznie i implementujesz zwycięzcę. Feature Flags to mechanizm — infrastruktura która umożliwia m.in. A/B testowanie, ale ma znacznie szersze zastosowania (rollout, kill switches, beta access). A/B Test zawsze ma jasny cel (konwersja, engagement) i statystyczne kryterium sukcesu. Feature Flag może być używany bez żadnego A/B testu — np. jako rollout mechanism dla nowej funkcji której nie testujesz, tylko stopniowo udostępniasz. Najlepsze praktyki łączą oba: Feature Flags jako infrastruktura, A/B Testing jako metodologia decyzyjna.

Czytaj dalej