SRE Feature Flags and Progressive Delivery
Releasing code and releasing a feature do not need to happen together. Feature flags separate the two steps. Teams ship code safely to production and switch features on for a small group and widen the group as confidence grows.
What Is a Feature Flag?
A feature flag is a switch in the code that turns a feature on or off without a new deployment. Think of a light switch in a new room. Electricians install the wiring ahead of time, and the owner flips the switch when the room is ready. A flag works the same way for software.
if (flag("new_checkout") is ON for this user) {
show new checkout page
} else {
show current checkout page
}
Types of Flags
| Type | Purpose | Lifetime |
|---|---|---|
| Release flag | Hide unfinished or new features | Days to weeks |
| Ops flag or kill switch | Disable a risky feature during trouble | Long |
| Experiment flag | Compare two versions with real users | Weeks |
| Permission flag | Give features to chosen plans or groups | Long |
Progressive Delivery
Progressive delivery releases a change in widening circles and checks health at each stage.
[Team Only] → [1% Users] → [5%] → [25%] → [50%] → [100%]
↑ │ │ │ │
└── rollback by flipping the flag at any stage
At each stage the team compares error rate and latency against the old version. Healthy numbers allow the next step. Bad numbers trigger an instant switch back.
Other Safe Release Patterns
Canary Release
A canary sends a small share of traffic to servers that run the new version. The name comes from the canary birds that miners once carried to warn of danger.
Blue-Green Deployment
Two identical environments run side by side. Blue serves users. Green holds the new version. A traffic switch moves users from blue to green, and a switch back reverses the change.
Dark Launch
The new code runs in the background on real traffic, but users never see its results. The team measures performance before any exposure.
The Kill Switch
A kill switch protects the whole service. Wrap risky or optional features, such as recommendations or heavy reports, in an operations flag. During an incident, an engineer flips the flag and sheds load in seconds. The core service stays alive while the optional parts rest.
Example: New Payment Screen
- The team deploys the new screen with the flag off.
- Employees turn it on for themselves and test.
- The flag opens for 1 percent of users in one country.
- Error rate holds steady, so the share grows to 10 percent and 50 percent.
- At 50 percent, payment success drops by two points. The team flips the flag off in under a minute.
- Developers fix a bug and restart the rollout.
Without a flag, the same problem would require a full rollback deployment.
Flag Hygiene
Old flags create confusing code and hidden risk. Treat every flag as a loan that must be repaid.
- Record an owner, a purpose, and an expiry date for each flag.
- Remove release flags soon after reaching 100 percent.
- Test both the on and off paths.
- Keep flag names clear and consistent.
- Log every flag change with time and author.
Risks to Manage
- Too many flags make behavior hard to predict.
- A flag service outage must fall back to a safe default value.
- Unreviewed flag changes can cause incidents as easily as code changes.
Common Mistakes
- Leaving finished flags in the code for years.
- Skipping monitoring during rollout.
- Letting anyone change production flags with no record.
- Nesting flags inside flags until nobody understands the logic.
Key Takeaways
Feature flags separate deployment from release, enable gradual rollout, and provide instant rollback. Pair them with strong monitoring and strict cleanup habits.