Feature Flags and Progressive Delivery

Analogy categoryAnalogies

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).

yaml

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 15m

Feature 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?

Rolling Deployments

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

Docker & Kubernetes Study Notes

YAML · 40 topics

Topics covered

#YAML#CICDToolsPipelinesStudyNotes#DevOps#FeatureFlagsAndProgressiveDelivery#Feature#Flags#Progressive#Delivery#StudyNotes#SkillVeris

Feature Flags and Progressive Delivery