Feature Flags and Progressive Delivery
A feature flag (also called a feature toggle) is a conditional switch in code that determines whether a piece of functionality is active, evaluated at runtime rather than at build or deploy time. Instead of shipping a feature to every user the moment its code merges, teams wrap the new code path in a flag and control exposure through a configuration service or flag-management platform. This separates two historically conflated activities — deploying (getting code onto production infrastructure) and releasing (making a feature visible to users) — which is the foundational idea behind progressive delivery: rolling a feature out gradually and reversibly instead of as a single irreversible event tied to a deployment.
Cricket analogy: A feature flag is like a coach holding a promising young player in the squad but not selecting them for the XI until conditions are right -- the player is already 'deployed' to the team bus, but 'released' onto the field only when the flag (team sheet decision) is flipped on matchday.
Types of Feature Flags
Release flags gate unfinished or risky features behind a toggle so code can merge to the main branch continuously without exposing incomplete work — this is what enables trunk-based development at scale. Experiment flags (used for A/B testing) route different user segments to different code paths to measure impact on a metric. Ops flags act as kill switches for expensive or fragile subsystems, letting on-call engineers disable a feature instantly during an incident without a redeploy. Permission flags gate functionality by plan tier or user entitlement, which is a longer-lived business concern rather than a temporary rollout mechanism.
Cricket analogy: Release flags are like fielding a net bowler in training who isn't yet ready for a real match; experiment flags are like trialing two different batting orders in separate warm-up games to see which scores more; ops flags are like a captain instantly substituting an injured bowler mid-over; and permission flags are like reserving the players' pavilion for members-only, based on club tier.
Progressive Rollout Mechanics
A flag-management platform typically lets you target a flag by percentage of traffic, by user attribute (region, account plan, beta cohort), or by explicit allow-list, and to change that targeting instantly without a new deployment. A typical progressive delivery sequence starts at 1% of traffic, watches error rates and business metrics, and steps up to 5%, 25%, 50%, and 100% over hours or days, halting or rolling back the percentage the moment a regression appears. Because the rollback is just a configuration change rather than a redeploy, mean time to recovery for a bad feature drops from minutes (a rollback deploy) to seconds (flipping the flag).
Cricket analogy: A progressive rollout is like a young bowler being tested first in one over of a low-stakes warm-up, then a full spell in a T20, then a Test match if performance holds -- selectors watch economy rate at each stage and pull them from the attack instantly (seconds) rather than waiting for the next match to make a change (minutes).
name: Post-Deploy Progressive Rollout
on:
workflow_dispatch:
inputs:
flag_key:
required: true
target_percentage:
required: true
jobs:
ramp-flag:
runs-on: ubuntu-latest
steps:
- name: Update rollout percentage via flag service API
run: |
curl -sf -X PATCH "https://flags.example.com/api/v1/flags/${{ inputs.flag_key }}" \
-H "Authorization: Bearer ${{ secrets.FLAG_SERVICE_TOKEN }}" \
-d '{"rollout": { "percentage": ${{ inputs.target_percentage }} } }'
- name: Wait and check error budget
run: ./scripts/check-error-budget.sh --flag ${{ inputs.flag_key }} --window 15mFeature flags let a team decouple 'is this code on production servers' from 'can users see this feature' — the same distinction between a chef finishing a dish in the kitchen (deploy) and the waiter actually serving it to a table (release). A dish can sit ready in the kitchen for any number of tables to be served whenever the timing is right.
Flags left in code long after a feature fully ships accumulate as 'flag debt': every unremoved flag adds a branch to test and a source of subtle bugs when stale flags interact. Mature teams treat flag cleanup as a mandatory follow-up task, not an optional one, and many tooling platforms flag stale toggles that haven't changed state in months.
Relationship to CI/CD Pipelines
Flags reduce pressure on the deployment pipeline itself: because a bad feature can be disabled instantly through configuration, pipelines can ship smaller, more frequent changes with lower perceived risk, and rollback of a *feature* no longer requires rolling back a *deployment*. Some pipelines integrate flag ramp-up as an explicit post-deploy stage, automatically increasing exposure over time and gating each step on observed error rates and business KPIs pulled from monitoring.
Cricket analogy: Because a struggling bowler can be pulled from the attack instantly by the captain's call rather than the whole team being substituted, teams feel free to try smaller, more frequent tactical experiments in a match -- some franchises now even script an automatic 'over-by-over' review, upping a bowler's overs only if the economy rate stays low.
- Feature flags decouple code deployment from user-facing release, enabling safer, reversible rollouts.
- Common flag types include release, experiment (A/B), ops (kill switch), and permission flags.
- Progressive delivery ramps exposure gradually (e.g., 1% → 5% → 25% → 100%) while watching metrics.
- Flag-based rollback is a configuration change, dramatically faster than redeploying old code.
- Stale, unremoved flags accumulate as technical debt and should be cleaned up after full rollout.
- Flags let pipelines ship smaller, more frequent changes since release risk moves out of the deploy step.
Practice what you learned
1. What core distinction do feature flags enable in software delivery?
2. Which flag type is specifically used as an emergency kill switch during an incident?
3. Why is flag-based rollback typically faster than a deployment rollback?
4. What is 'flag debt'?
5. In a progressive rollout, what typically determines whether exposure increases from one percentage step to the next?
Was this page helpful?
You May Also Like
Canary Releases
Learn how canary releases gradually expose a small percentage of real traffic to a new version, using metrics to decide whether to expand or abort the rollout.
Rolling Deployments
Rolling deployments replace instances of an application gradually, batch by batch, so the service stays available throughout the release without needing a full duplicate environment.
Blue-Green Deployments
Understand the blue-green deployment pattern for near-instant, low-risk releases and rollbacks by running two full environments and switching traffic between them.
Monitoring and Alerting for Pipelines
Understand how to instrument CI/CD pipelines with metrics, logs, and alerts so teams detect broken builds, slow pipelines, and failed deployments before they become incidents.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics