platform-engineering · intermediate
Progressive Delivery and Feature Flags
Quick answer
Progressive delivery releases software incrementally (canary, percentage, cohort) with health checks. Feature flags decouple deploy from release so you can dark-launch, target users, and kill switches without redeploying.
Why this matters
- Big-bang deploys maximize blast radius.
- Flags enable experiments and safe rollback.
- Error budgets pair naturally with gradual rollouts.
Learning objectives
- Separate deploy vs release. 2. Design flag lifecycle. 3. Canary with automated abort. 4. Avoid flag debt. 5. Combine with SLOs.
Explain like I am 5
Try a new playground rule with one class first—not the whole school at once.
Mental model
flowchart LR
Deploy --> FlagOff[Flag off]
FlagOff --> Canary
Canary -->|healthy| Expand
Canary -->|sick| Abort
Expand --> GA[All users]
GA --> RemoveFlag
Core concepts
Deploy ≠ release
Code can sit dark until flag on.Flag types
Release, experiment, ops kill switch—different ownership and TTL.Canary analysis
Compare error rate/latency vs baseline; auto-abort on burn.Targeting
Internal, % random, segment—document bias.Flag debt
Remove flags after GA; stale flags become landmines.Worked example
Checkout redesign: deploy behind flag; 5% canary; p99 regression → auto disable; fix; re-canary; GA; delete flag in two sprints.
Trade-offs
| All-or-nothing | Infinite flags |
|---|---|
| Simple | Complexity / debt |
Failure modes
| Mode | Mitigation |
|---|---|
| No kill switch | Ops flags for risky paths |
| Flag soup | TTL + cleanup tickets |
| Canary without metrics | Tie to SLIs |
Interview mode
Skeleton: "I progressive-deliver with flags and canaries—small blast radius, automated abort, flag cleanup."
Knowledge check
Decoupling deploy from release and limiting blast radius
Eliminating all testing
Removing the need for version control
Guaranteeing zero bugs forever
By Shubham Jain