Progressive Delivery Vocabulary: Feature Flags, Canary, and Blue-Green Explained

Progressive delivery is how modern teams ship software safely — not all at once, but gradually, with the ability to observe, pause, and roll back. The vocabulary of progressive delivery appears in architecture discussions, runbooks, and release planning. Understanding these terms precisely helps you communicate release strategy clearly and write better documentation.

Feature Flags

Feature flag (also feature toggle or feature switch) — A configuration mechanism that enables or disables a feature at runtime without deploying new code. Flags decouple deployment (shipping code) from release (making it available to users). Phrase: “We deployed the new checkout flow behind a feature flag — it’s dark by default until QA signs off.”

Flag lifecycle — The stages a feature flag goes through: creation (when the flag is added), targeting (rollout begins), full release (100% of users), cleanup (flag removed from code). Phrase: “Our flag lifecycle policy requires removing flags within two sprints of a full release — stale flags are a maintenance burden.”

Flag debt — Accumulation of feature flags that were never cleaned up after full release, leading to complex conditional logic and unpredictable interactions. Phrase: “We have 40 old flags in the codebase — the flag debt is making testing very difficult.”

Targeting rules — Conditions that determine which users see a flag as enabled: by user ID, percentage, country, plan tier, internal employees, or custom attributes. Phrase: “The targeting rule enables the feature for users on the beta plan in the UK only.”

Kill switch — A feature flag specifically designed to quickly disable a problematic feature in production, without a code deploy. Phrase: “We added a kill switch to the AI recommendation engine — if the model misbehaves, we can turn it off instantly.”

Canary Deployments

Canary deployment — A strategy where a new version receives a small percentage of traffic first (the canary), and the percentage increases if metrics remain healthy. Named after the canary-in-a-coal-mine analogy. Phrase: “We started the canary at 1% — if error rates stay below 0.1% for 30 minutes, the pipeline promotes to 10%.”

Canary weight — The percentage of traffic routed to the canary version. Phrase: “Canary weight is at 5% — we’ll raise it to 25% after the next metric evaluation window.”

Canary analysis — Automated or manual comparison of metrics between the canary version and the baseline (stable version): error rate, latency, CPU usage, business metrics. Phrase: “Canary analysis flagged elevated P99 latency on the new version — the promotion was paused automatically.”

Promotion — Moving the canary version to the next traffic percentage tier, or making it the new stable version. Phrase: “The canary passed all analysis gates — promoting to 100% now.”

Automated rollback trigger — A predefined condition (e.g. error rate exceeds 1%) that automatically reverts traffic from the canary to the stable version without human intervention. Phrase: “The automated rollback trigger fired at 2am — the canary was emitting 5xx errors above the threshold.”

Error rate threshold — The maximum acceptable error rate before an automated rollback is triggered. Phrase: “Our error rate threshold for canary analysis is 0.5% — anything above that triggers an automatic rollback.”

Blue-Green and Ring Deployments

Blue-green deployment — Two production environments (blue = current, green = new). Traffic is switched from blue to green when the new version is validated. Rollback is instant: switch back to blue. Phrase: “We do blue-green for the payment service — instant rollback is a requirement given the risk profile.”

Slot swap — In cloud platforms like Azure App Service, the mechanism for switching traffic between deployment slots (equivalent to blue-green swap). Phrase: “Run the smoke tests against the staging slot before triggering the slot swap.”

Traffic cutover — The moment when traffic switches from the old version to the new version — either instantly (blue-green) or gradually (canary). Phrase: “Traffic cutover happened at 14:00 UTC — all metrics nominal after five minutes.”

Ring-based deployment — A strategy that releases changes to successive rings of users: internal employees → beta users → 10% → 50% → 100%. Each ring is a validation gate. Phrase: “Ring 0 is our own engineering team — we always dogfood on Ring 0 before expanding.”

Traffic splitting — Dividing traffic between two or more versions using a load balancer, API gateway, or service mesh. The mechanism behind both canary and blue-green deployments.

Tools Vocabulary

LaunchDarkly — A popular feature management platform. Key terms in its interface: targeting, variations, segments, environments, flag evaluation.

Unleash — An open-source feature flag system. Key terms: toggle, strategy (gradual rollout, userWithId), environment, impression data.

Practice: Write a release plan for a fictional feature using progressive delivery. Include which feature flag tool you would use, how you would configure targeting rules, what your canary weight progression would be, and what your automated rollback threshold would be. Use as many terms from this post as possible.

Understanding Nuance: “Rollback” and “Kill Switch” – A Specific Concern

Let’s be honest; some of these terms—canary, ring, blue-green—sound impressive. They’re built around the idea of sophisticated control, which is fantastic, but it’s easy to get caught up in the jargon and lose sight of the core principle: we want to minimize risk when releasing new code. One area where this nuance is particularly important for developers learning English technical vocabulary is understanding the difference between a “rollback” and a “kill switch.” They’re often used interchangeably, but they represent distinct actions with very different implications.

A rollback typically refers to reverting a deployment – essentially, going back to the previous stable version of your application. This is usually triggered by a problem detected after release, like a critical bug or unexpected performance degradation. The goal isn’t necessarily to prevent the issue from happening in the first place; it’s about mitigating its immediate impact. Think of it as an emergency measure – “We rolled back to version 2.1.3 because users reported intermittent database connection errors.” You might see a comment like this on a pull request: “Rollback triggered due to high error rates observed after deployment. Investigation ongoing.” It’s a reactive step, focused on restoring functionality quickly.

A kill switch, however, is far more drastic. It’s an immediate and absolute shutdown of a feature or, in some cases, the entire application. While a rollback targets a specific version, a kill switch immediately stops all traffic to that particular component. Imagine a new payment gateway integration failing catastrophically – instead of just reverting users to the old system (rollback), you might use a kill switch to prevent any transactions from going through the faulty gateway until the problem is resolved. A Slack message in this scenario could read: “Kill switch activated for Feature X due to severe performance issues impacting 50% of users. Engineering team investigating.” This isn’t about restoring functionality; it’s about preventing further damage and buying time for a proper fix. The key difference lies in the degree of intervention – rollback is targeted, kill switch is total cessation.

It’s crucial to communicate these distinctions clearly, especially when discussing deployment strategies with stakeholders who might not be as technically fluent. Using precise language avoids confusion and ensures everyone understands the scope of the action being taken. Furthermore, understanding when a rollback versus a kill switch is appropriate depends heavily on your system architecture and monitoring setup—knowing how you’ll detect the issue in the first place informs the correct response.

# Example:  A simplified kill switch implementation (Conceptual - not production ready)
# This demonstrates a hypothetical command to disable a feature flag
# via a configuration file. In reality, this would be much more complex.
# Assume 'feature_flags.json' contains configurations like {"FeatureX": true}
import json

def disable_feature(feature_name):
  try:
    with open('feature_flags.json', 'r') as f:
      data = json.load(f)
    if feature_name in data:
      data[feature_name] = False
      with open('feature_flags.json', 'w') as f:
        json.dump(data, f, indent=4)
      print(f"Feature '{feature_name}' disabled.")
    else:
      print(f"Feature '{feature_name}' not found in configuration.")
  except FileNotFoundError:
    print("Configuration file not found.")

# Example usage (hypothetical):
disable_feature("FeatureX")