Decoupling Deployment from Release
Feature flags separate code deployment from feature release. Code ships to production hidden behind a flag. When ready, the flag is enabled for a subset of users, then gradually rolled out. If problems emerge, the flag is disabled — no redeployment needed.
The decoupling is transformative. Without feature flags, every code change is a release. With feature flags, code changes are deployments, and feature releases are business decisions. Deployments happen continuously; releases happen when the business is ready.
Trunk-Based Development: All developers commit to the main branch, hiding incomplete features behind flags. This eliminates long-lived branches, merge conflicts, and integration hell. It also enables experimentation: A/B testing, canary releases, and dark launches all depend on feature flags.
Progressive Rollout Patterns
- Percentage-based: Enable for 1%, 5%, 25%, 100% of users. Monitor metrics at each step. Each step has automatic rollback criteria based on error rate, latency, and business metrics.
- User segments: Beta users, internal employees, specific customer tiers. Provides controlled exposure to friendly users who will report issues constructively.
- Geographic: Roll out by region to contain blast radius. Start with a low-traffic region, then progress to higher-traffic regions.
- Time-based: Enable during business hours when engineering is available. Night-time rollouts are risky because the engineering team is asleep when issues occur.
Combined Pattern: A feature might roll out to internal users first, then beta users, then 1% of Australian users, then 5% of European users, then 25% of North American users, and finally 100% globally. Each stage has monitoring, rollback criteria, and a decision gate.
Safety Mechanisms
Automatic rollback triggers: error rate spike, latency threshold, custom business metrics. Circuit breakers disable features if downstream dependencies fail. Kill switches immediately disable all features in an emergency.
Rollback Triggers: If error rate increases by more than 0.5%, disable the flag. If p95 latency increases by more than 100ms, disable the flag. If conversion rate drops by more than 2%, disable the flag. These triggers are evaluated continuously, and the flag is disabled automatically if any trigger fires.
Kill Switches: The emergency brake. A kill switch immediately disables a feature for all users, regardless of targeting rules. Used for emergencies: security vulnerabilities, data corruption, or catastrophic failures. Every critical feature should have a kill switch accessible to on-call engineers without requiring code changes or deployments.
Our Recommendation
Use LaunchDarkly or Unleash for feature management. Implement progressive rollouts for all user-facing changes. Maintain kill switches for critical paths. Feature flags are not optional for production systems — they are essential safety equipment.
Platform Choice: LaunchDarkly is the enterprise standard with targeting rules, progressive rollouts, A/B testing, and analytics. Pricing is per monthly active users. For smaller teams, Unleash is an open-source alternative that provides core feature flagging without the enterprise price tag.
Flag Cleanup: Remove flags after the feature is stable (typically 30 days after full rollout). Accumulated flags create technical debt and confusion. The implementation pattern: wrap every new feature in a flag, define the rollout strategy before deployment, implement automatic rollback triggers, and maintain kill switches for critical paths.
