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.