Vocabulary for Progressive Delivery: Canary, Feature Flags, and Dark Launch

Progressive delivery is the practice of releasing software changes to increasingly larger audiences in a controlled, observable way — reducing risk by limiting the blast radius of any release. It is the evolution beyond simple continuous deployment.

If you work in platform engineering, product engineering, or DevOps, you encounter progressive delivery vocabulary constantly: in architecture discussions, incident post-mortems, feature planning sessions, and tool evaluations. This guide explains the core terms precisely, with the context you need to use them accurately.

Why Progressive Delivery Matters

Traditional deployment is binary: the new version is either deployed or it is not. Progressive delivery adds a third dimension: to whom and how much. This changes the risk profile of every release.

“Progressive delivery is continuous delivery where new versions are deployed to a subset of users and evaluated before rolling out fully.”

— James Governor, coined the term in 2018

Core Vocabulary

1. Canary Release / Canary Deployment

Pronunciation: /ˈkænəri rɪˈliːs/

Routing a small percentage of production traffic — typically 1-5% — to the new version, while the majority of users continue using the stable version. Named after the historical practice of sending canary birds into coal mines to detect dangerous gases before sending humans.

Usage: “We’re doing a canary release — 2% of traffic goes to v2.4. We’ll monitor error rates for 30 minutes before expanding.”

Key phrases:

• “Run a canary” — execute a canary deployment
• “Canary traffic” — the traffic subset routed to the new version
• “Canary analysis” — comparing metrics between the canary and baseline
• “Promote the canary” — expand the canary to more traffic
• “Bake time” — the observation period for a canary before promotion

2. Ring Deployment

A multi-stage rollout strategy where you release to progressively larger rings of users — from internal, to beta users, to a small production percentage, to full production. Common in large-scale platforms (Azure, Windows, Microsoft 365).

Typical rings:

• Ring 0 (Canary): Internal employees only
• Ring 1 (Early adopters): Opted-in beta users
• Ring 2 (Small production): 1-5% of production
• Ring 3 (Wider production): 20-50%
• Ring 4 (Full production): 100%

Usage: “This change goes through all four rings. Ring 0 validation takes 24 hours, then we gate on error budget before promoting to Ring 1.”

3. Feature Flag / Feature Toggle

Pronunciation: /ˈfiːtʃə flæɡ/

A mechanism that allows a feature to be enabled or disabled at runtime without deploying new code. Feature flags decouple deployment from release — you can ship code to production without activating it for users.

Types of feature flags:

• Release flag — temporary flag to control rollout of a new feature; removed when fully released
• Experiment flag — used for A/B testing
• Ops flag — used to control system behaviour in production (e.g., disable a feature under high load)
• Permission flag — controls feature access for specific user groups

Usage: “The new checkout flow is behind a feature flag. We’ll enable it for 10% of users and monitor conversion rates before expanding.”

4. Dark Launch

Deploying new code to production and routing real production traffic through it, but not showing the results to users. The system processes the request twice — once with the old code (shown to the user) and once with the new code (results discarded or logged). Used to test real-world performance and correctness before the feature is visible.

Usage: “We dark-launched the new search ranking algorithm for two weeks. The new code processed 40 million queries without any failures before we surfaced results to users.”

Related terms:

• “Shadow mode” — synonym for dark launch
• “Shadow traffic” — traffic sent to the new system in dark launch
• “Shadow testing” — the practice of dark launching for validation

5. Kill Switch

A mechanism to instantly and completely disable a feature, integration, or service component — usually a feature flag set to a global “off” state. A kill switch is a safety mechanism, not a planned deployment step.

Usage: “We have a kill switch on the new payment provider integration. If error rates spike after launch, the on-call engineer can disable it in 30 seconds without a deployment.”

Related phrases:

• “Pull the kill switch” / “Flip the kill switch” — activate it
• “Arm the kill switch” — prepare it so it can be activated quickly
• “Kill switch is armed” — the switch is ready to use

6. Gradual Rollout / Progressive Rollout

A release strategy where the new version is enabled for an incrementally growing percentage of users over time — for example, 1% → 5% → 25% → 100%, with automatic or manual promotion at each stage.

Usage: “We’re doing a gradual rollout with automatic promotion every 24 hours, gated on error rate staying below 0.1%.“

7. Rollout Gate / Quality Gate

A checkpoint in a progressive deployment where specific metrics must be within acceptable bounds before the rollout can proceed to the next stage. Gates can be manual (a human approves) or automated (metrics trigger promotion).

Usage: “The rollout gate checks P99 latency, error rate, and user-reported crashes. All three must be green for 30 minutes before automatic promotion to the next ring.”

8. Traffic Splitting

The technical mechanism of dividing incoming requests between two or more versions of a service. Implemented at the load balancer, service mesh, or API gateway level.

Methods:

• Percentage-based splitting: 95% to v1, 5% to v2
• Header-based routing: Requests with a specific header go to v2
• User attribute-based: Users in a specific region or with a specific plan
• Sticky sessions: Same user always goes to the same version

9. Blue/Green Deployment

Running two identical production environments (Blue = current, Green = new). Traffic is switched from Blue to Green in a single atomic operation. Unlike a canary, blue/green is not gradual — it is a full cutover. The benefit is instant rollback: point traffic back to Blue.

Usage: “We use blue/green for our database migrations — we can switch traffic back to the previous version in under 10 seconds if anything goes wrong.”

Compare with canary: Blue/green is instant and complete; canary is gradual and incremental.

10. A/B Test / Split Test

A controlled experiment where two variants (A and B) are shown to randomly divided user groups to measure which performs better on a defined metric (conversion rate, click-through, engagement). Unlike a canary (focused on system health), A/B tests measure user behaviour.

Usage: “We’re running an A/B test on the onboarding flow. Variant B shows the pricing page earlier. We need 10,000 users per variant for statistical significance.”

11. Statistical Significance

In A/B testing, the confidence level that an observed difference between variants is real and not due to random chance. Typically expressed as a p-value below 0.05 (95% confidence).

Usage: “The conversion improvement is only 1.2% and we haven’t reached statistical significance — we need another week of data before making a decision.”

12. Cohort

A group of users who share a characteristic and are analysed together — typically defined by the date they were first exposed to a feature, their geography, their plan level, or another attribute.

Usage: “The week-1 cohort showed 40% retention. The week-2 cohort, which experienced the new onboarding, shows 52% — a significant improvement.”

13. Feature Branch Deployment / Preview Environment

Deploying a feature branch to a temporary, isolated environment for testing and review before merging. Also called PR environments or review apps.

Usage: “Every PR automatically gets a feature branch deployment — reviewers can test the actual behaviour without checking out the branch locally.”

14. Stale Flag / Flag Debt

A feature flag that was never removed after its feature was fully released. Stale flags accumulate over time and create technical debt — they make the codebase harder to understand and can cause unexpected behaviour.

Usage: “We have 47 feature flags in the codebase. At least 15 are stale — the features are fully rolled out but the flags and their code branches are still there.”

15. Rollback vs Roll-forward

• Rollback: Reverting to the previous version when a release has problems
• Roll-forward: Fixing the problem in a new deployment rather than reverting, because reverting would also undo other changes already in production

Usage: “We can’t roll back — three other features shipped in the same version and are already being used. We’ll roll forward with a targeted fix.”

Putting It Together: A Progressive Delivery Conversation

Engineer: “We’re planning to ship the new recommendation engine next week. What’s the rollout strategy?”

Release Engineer: “We’ll start with a dark launch — route 5% of traffic in shadow mode for 48 hours to compare latency and accuracy with the current model. If the metrics look good, we’ll flip the feature flag to 1% canary. The rollout gate requires P99 latency below 200ms and error rate below 0.5% for 4 consecutive hours. If all checks pass, we auto-promote through 5%, 25%, 100% over three days. The kill switch is armed throughout — if anything spikes, we can disable the flag globally in seconds.”

Key Takeaways

• Canary release sends a small traffic percentage to the new version; promote it based on metrics.
• Ring deployment uses structured rings (internal → beta → production tiers).
• Feature flags decouple deployment from release — ship the code, then control when users see it.
• Dark launch runs new code against real traffic invisibly — perfect for validating correctness and performance before go-live.
• Kill switch is the emergency off-switch; arm it before every release.
• Blue/green gives instant rollback; canary gives gradual risk reduction — they serve different purposes.
• Stale flags are technical debt — build a habit of removing flags once fully rolled out.

Progressive delivery vocabulary is the language of confident, controlled software releases. Knowing these terms means you can participate in deployment strategy discussions and contribute to safer releases.