Feature Flags

Release Toggle

Ukrywa niegotową funkcję w kodzie. Developerzy commitują do main za flagą zamiast long-lived branchy.

Experiment Toggle

A/B testing — różne warianty dla różnych grup. Mierz metryki, wybierz zwycięzcę.

Ops Toggle

Wyłącz kosztowne lub ryzykowne funkcje pod obciążeniem. Kill switch dla awarii.

Permission Toggle

Włącz funkcję per plan, rola lub segment. Premium features dla paid users.

Co to są Feature Flags i jak działają?

Feature Flags (zwane też Feature Toggles lub Feature Switches) to technika pozwalająca włączać i wyłączać funkcje w aplikacji bez wdrażania nowego kodu. Zamiast kondycji czy funkcja jest dostępna zależy od kodu — zależy od konfiguracji zewnętrznej systemu. Podstawowy mechanizm: if (featureFlags.isEnabled('new-checkout', user)) { showNewCheckout(); } else { showOldCheckout(); }. Wartość flag pobierana z centralnego systemu (nie z kodu). Kluczowe use cases: Trunk-based development — deweloperzy commitują do main za flagą (bez long-lived branches). Canary releases — włącz funkcję dla 5% użytkowników, monitoruj, stopniowo zwiększaj. A/B testing — 50% widzi wariant A, 50% wariant B — mierz konwersję. Kill switch — natychmiastowe wyłączenie funkcji bez deploymentu jeśli coś pójdzie nie tak. Rollout per user segment — najpierw internal users, potem beta, potem wszyscy. Ops toggles — wyłącz kosztowne funkcje przy dużym obciążeniu (circuit breaker). Typy flag wg Fowler: Release toggle — ukryj niegotową funkcję. Experiment toggle — A/B test. Ops toggle — wydajność / operacyjne. Permission toggle — per user/segment feature. Korzyści: oddzielenie deployment od release. Szybsze iteracje. Zmniejszone ryzyko dużych release'ów. Możliwość personalizacji.

LaunchDarkly, Unleash i OpenFeature — jak wybrać system feature flags?

LaunchDarkly: lider rynku komercyjnych feature flags. Targeting rules — włącz dla user.email contains '@company.com', lub user.country = 'PL'. Percentage rollouts — 10% → 25% → 50% → 100%. Multivariate flags — nie tylko true/false, ale string/number/JSON (np. różne UI warianty). A/B experiments wbudowane. Code References — skanuje kod żeby znaleźć gdzie flagi są używane. SDK dla 20+ języków. Cennik: $10+/user/miesiąc — drogie przy skali. Flagsmith: open-source + cloud (tańsza alternatywa dla LaunchDarkly). Segment-based targeting. Remote config (flaga z wartością JSON zamiast bool). Self-hosted lub SaaS. Unleash: open-source, self-hosted. Enterprise version dostępna. Gitlab feature flags używa Unleash. Strategie: gradual rollout, user ID, IP, custom. SDK dla wielu języków. PostHog: product analytics + feature flags w jednym. Dobry dla startupów chcących łączyć analytics z flags. GrowthBook: open-source, feature flags + A/B testing. Bayesian stats engine. Self-hosted lub cloud. OpenFeature (CNCF): vendor-neutral standard API dla feature flags. Jak OpenTelemetry ale dla feature flags. Zmieniasz providera (LaunchDarkly → Unleash) bez zmiany kodu aplikacji. SDK + provider pattern. Flipt: open-source, gRPC/REST API, Kubernetes native. Configcat: prosty, dobry pricing, multi-platform. AWS AppConfig: managed feature flags jako część AWS.

Targeting i segmentacja — jak kontrolować komu pokazujesz funkcję?

Targeting rules: reguły które decydują czy flag jest włączona dla konkretnego użytkownika/żądania. Kontekst (evaluation context): user ID, email, plan, country, device, request IP, custom attributes. Typy targetowania: Individual targeting — konkretny user ID zawsze widzi funkcję (wewnętrzni testerzy). Segment targeting — 'beta users' segment (lista user IDs lub reguła email domain). Percentage rollout — losowy % populacji (seeded na user ID — ten sam user zawsze w tej samej grupie). Attribute-based rules — kraj = 'PL' AND plan = 'pro'. Sticky sessions: ważne żeby user przy każdej wizycie widział ten sam wariant (nie losowe flip). Implementacja: seed hash na user ID lub session ID. LaunchDarkly, Unleash — gwarantują stickiness. Multivariate flags: zamiast bool — string, number lub JSON. Przykład: 'checkout-ui' flag = 'old' | 'redesign-v1' | 'redesign-v2'. 33% widzi każdy wariant. Pozwala testować wiele wariantów jednocześnie. Flag dependencies: flag B włączona tylko gdy flag A włączona. Prerequisite flags. Targeting w kontekście B2B: per tenant (company) — każda firma może mieć własny zestaw flag. Tenant isolation — company.id jako targeting key. Self-serve flag management: daj PM lub biznesowi możliwość włączania/wyłączania flag bez angażowania devów. Audit log: kto zmienił flagę, kiedy, jaką wartość.

Feature Flags w architekturze — najlepsze praktyki i anty-patterny?

Najlepsze praktyki: Krótkie życie flag (short-lived): Release toggles powinny być usuwane gdy feature jest stabilna. Flag debt — zbyt wiele starych flag = kod trudny do rozumienia. Usuwaj flagi po launch (ticket w backlogu). Naming convention: service-name.feature-name lub feature.experiment. Jasne, opisowe nazwy. Dokumentacja flagi: cel, właściciel, data stworzenia, planowana data usunięcia. Testowanie z flags: testuj obydwa stany (on i off). Contract tests dla flag. Test że aplikacja działa przy flag service niedostępnym (fallback). Default values: zawsze definiuj sensowną wartość domyślną. Na wypadek gdy flag service jest niedostępny. SDK cache: lokalne cache flagi (nie każdy request to sieciowe wywołanie). Streaming updates: real-time aktualizacja flag bez restartu aplikacji. SSE lub WebSocket do flag service. Anty-patterny: Flag jako long-lived configuration: jeśli flaga nigdy nie jest usuwana — to jest feature toggle zamiast konfiguracja. Użyj proper config management (env vars, config maps). Too many flags: 100+ flag = trudne do zarządzania. Priorytetyzuj i czyść regularnie. Flag w SQL/bazie: nie trzymaj flag decyzji logiki biznesowej w bazie — trudne do zmiany per-request. Hardcoded user IDs w flags: zamiast user IDs hardcode → użyj segmentów. Brak monitoring: monitoruj które wariant widzi ile % ruchu. Alerty gdy flaga nie ma efektu.

Feature Flags a A/B testing i eksperymenty — jak mierzyć efekty?

Feature Flags to infrastruktura — A/B testing to metoda naukowa przeprowadzana na tej infrastrukturze. A/B testing: podziel ruch na warianty. Mierz metryki (conversion rate, revenue, engagement). Określ statystyczną istotność przed decyzją. Metryki do A/B testów: Primary metric (guardrail): konwersja, revenue per user, activation rate. Secondary metrics: engagement, session length, error rate. Guardrail metrics: nie pogarszaj krytycznych metryk (np. checkout errors). Statystyczna istotność: p-value (standardowo 0.05 — 95% confidence). Power analysis — oblicz jaka próba jest potrzebna dla wykrycia efektu X%. Beware underpowered tests — zbyt mała próba = fałszywe wnioski. Typy testów: A/B (two variants), A/B/n (multiple variants), Multivariate (kombinacje). Peeking problem: sprawdzanie wyników zanim zebrana wystarczająca próba = false positives. Rozwiązanie: sequential testing lub always-valid inference. Narzędzia: GrowthBook — bayesian stats, open-source. Optimizely — enterprise A/B testing. LaunchDarkly Experiments — wbudowany A/B. PostHog — product analytics + flags + experiments. Statsig — feature flags + experiments + metrics. Integracja z analytics: event tracking (user widzi wariant A → konwertuje lub nie). Segment, Mixpanel, Amplitude — enrichuj eventy z wariantem flagi. Attribution: który wariant był aktywny gdy event nastąpił.

Wyślij zapytanie