feature-flags

# Feature Flags Flags decouple **deploy** from **release**—and become **debt** if never removed. **Taxonomy**, **ownership**, and **retirement** matter as much as targeting. ## When to Offer This Workflow **Trigger conditions:** - Gradual rollouts, kill switches, or experiments behind flags - Flag sprawl and unknown defaults - Client vs server evaluation and hydration flicker **Initial offer:** Use **six stages**: (1) taxonomy, (2) targeting rules, (3) evaluation & consistency, (4) safety & ops, (5) lifecycle & cleanup, (6) governance). Confirm provider (LaunchDarkly, Unleash, ConfigCat, homegrown). --- ## Stage 1: Taxonomy **Goal:** Separate short-lived **release** flags, long-lived **config** flags, and **experiment** flags tied to analytics. **Exit condition:** Naming convention and expected TTL per type. --- ## Stage 2: Targeting Rules **Goal:** Percentage rollouts, segments (tenant, plan, region), deterministic bucketing (stable user key). --- ## Stage 3: Evaluation & Consistency **Goal:** Server-side authoritative for security and billing; client flags for UX only; avoid UI flicker on hydration (SSR/CSR agreement). --- ## Stage 4: Safety & Ops **Goal:** Kill-switch runbook; audit trail for changes; safe defaults when provider unavailable (often “off”). --- ## Stage 5: Lifecycle & Cleanup **Goal:** Tickets to remove flags after full rollout; periodic audits; metric for stale flags. --- ## Stage 6: Governance **Goal:** Approvals for broadening exposure; promotion across environments; break-glass access for incidents. --- ## Final Review Checklist - [ ] Flag types and naming documented - [ ] Targeting and bucketing deterministic - [ ] Server vs client boundaries clear - [ ] Kill switches and defaults documented - [ ] Cleanup process and ownership ## Tips for Effective Guidance - Never put security-only gates solely in client-side flags. - Pair with **ab-testing** when experiment analysis is primary. ## Handling Deviations - Align with **release-management** for communication cadence.