Feature flags and progressive delivery strategies
Feature flags have evolved from a simple toggle mechanism to a core practice enabling progressive delivery. According to LaunchDarkly's State of Feature Management, teams using feature flags deploy 2x more frequently and experience 50% fewer production incidents from releases.
The case for progressive delivery
According to Split.io's Feature Delivery Report, progressive delivery reduces mean time to recovery (MTTR) by 90% compared to traditional rollback procedures.
Feature flag fundamentals
Release Toggle
Enable/disable features without deployment
Experiment Toggle
A/B testing and experimentation
Ops Toggle
Kill switches for performance issues
Permission Toggle
Feature access by user or tier
Percentage Rollout
Gradual exposure to user populations
Targeting
Segment-based feature delivery
Separate Deploy from Release: The core principle of progressive delivery is decoupling deployment (code goes to production) from release (users see the feature). This enables safer, more controlled rollouts.
Progressive delivery patterns
Canary Release
Release to small percentage of users first. Monitor for issues before expanding.
Ring Deployment
Deploy through rings: internal → beta → early adopters → general availability.
Blue-Green
Two identical environments, switch traffic between them.
Dark Launch
Deploy and run code without exposing to users. Test in production.
Feature Branch by Abstraction
Build features behind flags over time, release when complete.
Canary release workflow
Deploy Code
Deploy to production with flag off
Enable 1%
Turn on for small percentage
Monitor
Watch metrics, logs, errors
Increase %
Gradually expand rollout
100% or Rollback
Full release or instant disable
Clean Up
Remove flag after stabilization
Typical Canary Rollout Schedule
Feature flag platforms
Feature Flag Platform Comparison
| Feature | LaunchDarkly | Split | Unleash | Flagsmith |
|---|---|---|---|---|
| Percentage Rollouts | ✓ | ✓ | ✓ | ✓ |
| User Targeting | ✓ | ✓ | ✓ | ✓ |
| A/B Testing | ✓ | ✓ | ✗ | ✗ |
| Self-Hosted Option | ✗ | ✗ | ✓ | ✓ |
| SDK Coverage | ✓ | ✓ | ✓ | ✓ |
| Analytics | ✓ | ✓ | ✗ | ✓ |
Feature Flag Platform Adoption (%)
Targeting strategies
Common Targeting Criteria
Internal Users First
Dogfooding—employees see features before customers.
Beta Customers
Customers who opt in to early access programs.
Tier-Based
Premium customers get features first.
Regional
Roll out by geography to limit blast radius.
Testing with feature flags
Unit Tests
Test both flag states explicitly
Integration Tests
Test feature interactions with flags
E2E Tests
Test critical paths with flag combinations
Flag State Tests
Verify targeting rules work correctly
Production Testing
Test in production with restricted access
Flag lifecycle management
Creation
Define flag, targeting rules, and success metrics.
Development
Implement feature behind flag, test both states.
Rollout
Progressive release with monitoring.
Stabilization
100% rollout, monitor for issues.
Removal
Remove flag from code, clean up.
Technical Debt: Stale flags are technical debt. Plan for flag cleanup from the start. Set expiration dates, automate alerts for old flags, and include flag removal in your definition of done.
Metrics and monitoring
Key Metrics to Monitor During Rollout (%)
Implementation best practices
Naming Convention
Clear, consistent flag names across org
Documentation
Purpose, owner, expected lifetime
Default State
Fail safe—default to off for new features
Monitoring
Alert on flag evaluation errors
Cleanup Process
Regular reviews and automated removal
Kill Switch
Emergency off switches for critical features
FAQ
Q: How many flags should we have active? A: It depends on organization size, but aim to minimize. 50-100 active flags for a medium organization is reasonable. More important is having a process to remove flags after rollout.
Q: Should we use feature flags for all features? A: No—use flags for risky or gradual releases. Simple, low-risk changes don't need flags. Overusing flags adds complexity.
Q: How do we handle flags in testing? A: Test both flag states. Use test fixtures to control flag values. Consider the combinatorial explosion of multiple flags.
Q: What's the performance impact of feature flags? A: Minimal with proper implementation. Use local flag evaluation (SDKs cache rules). Avoid database calls per evaluation. Most platforms evaluate in under 1ms.
Sources and further reading
- LaunchDarkly State of Feature Management
- Martin Fowler: Feature Toggles
- Progressive Delivery
- DORA: Continuous Delivery Capabilities
- Release It! by Michael Nygard
Implement Progressive Delivery: Feature flags and progressive delivery require thoughtful implementation and process design. Our team helps organizations build release strategies that minimize risk while maximizing velocity. Contact us to discuss your delivery strategy.
Ready to implement feature flags? Connect with our DevOps experts to develop a tailored progressive delivery strategy.
