Progressive Delivery

A configuration switch that enables or disables a feature at runtime without a code deployment. Allows teams to decouple code deployment from feature release, enabling dark launches, A/B tests, and instant rollbacks. Also called feature toggle or feature switch.

"We shipped the new checkout flow behind a feature flag — it's deployed to all environments but only enabled for 1% of users. Once we confirm conversion metrics are healthy, we'll ramp to 100% by updating the flag value in LaunchDarkly."

A type of feature flag specifically used to control whether a finished feature is visible to users — distinct from experiment flags (A/B) or ops flags (circuit breakers). Release toggles are expected to be short-lived and removed once the feature is fully launched.

"The payments team keeps a release toggle on every new payment method. When the business approves the regional launch, ops flips the toggle for that country — no deployment needed. Toggles older than 90 days trigger a cleanup ticket automatically."

A deployment strategy that routes a small percentage of live traffic to a new version of the service while the rest continues on the old version. The "canary" detects problems early before they affect all users. Traffic is gradually shifted to the new version if metrics remain healthy.

"We deploy canary releases at 1% traffic for 30 minutes before promoting. The canary monitors three signals: error rate, p99 latency, and business conversion. If any threshold breaches, the deployment system automatically rolls back to the previous version."

A release strategy using two identical production environments (blue and green). Traffic runs on blue while green has the new version deployed and tested. Traffic is switched to green instantly. Blue remains available for an immediate rollback by switching back.

"Our blue-green setup means zero-downtime deployments — we deploy the new version to the green environment, run smoke tests, then switch the load balancer in under a second. If something fails in the first 30 minutes, we switch back to blue immediately."

Routing a defined percentage of incoming requests to different versions of a service. The foundation of canary releases and A/B experiments at infrastructure level — typically implemented via load balancer weights, service mesh rules, or CDN configuration.

"We use traffic splitting in Istio: 90% of requests route to v1, 10% to v2. Once v2's error rate is below 0.1% for 24 hours, we shift to 50/50, then 100% v2 over the next 48 hours. The shift is fully automated based on the monitoring thresholds."

Deploying a new feature or service to production but keeping it invisible to users — allowing the system to process real traffic or data without exposing the user interface or results. Used to validate performance and behaviour under real load before users see the feature.

"We dark launched the new recommendation engine for two weeks — it computed recommendations for all users using shadow traffic but never showed them. We validated latency, memory usage, and result quality against the existing engine before the public launch."

A technique where real production requests are duplicated and sent to a new service version in parallel — the new service processes the request but its response is discarded, not returned to users. Allows testing the new version under real load without any user impact.

"Before migrating to the new search service, we ran shadow traffic for one week — every search query was sent to both the old and new service simultaneously. We compared results, measured latency differences, and confirmed the new service handled peak load correctly."

An automated or manual condition that initiates reverting a deployment to the previous version — typically a threshold breach in error rate, latency, or business metrics. Defining rollback triggers before a deployment removes the need for manual decision-making during an incident.

"Our deployment pipeline defines rollback triggers: if error rate exceeds 1% or p99 latency exceeds 2 seconds within 10 minutes of a canary deployment, the system automatically rolls back and pages on-call. We've had zero manual rollback decisions in the last quarter."

The period a new deployment runs in production (or at a partial traffic percentage) before being promoted to full rollout — allowing time to observe metrics, catch edge cases, and build confidence. The term comes from hardware testing where chips were "baked" to surface early failures.

"Our standard baking time is 24 hours at 10% canary before we promote to 100%. For high-risk changes — database schema migrations, payment flows — we extend baking time to 72 hours and require explicit sign-off from the owning team lead."

A feature flag or configuration that can instantly disable a feature in production without a deployment — used as an emergency safety mechanism for features that could cause harm if they malfunction. Kill switches must be tested in drills to confirm they work before they are needed.

"Every payment feature ships with a kill switch. During the Black Friday traffic spike, one payment method started timing out at 3x normal rate — we activated the kill switch in 45 seconds, routing users to alternative methods while the team investigated. No deployment required."

A release strategy that gradually increases the percentage of users receiving a new feature — starting with a small cohort (1%, 5%, 10%) and expanding based on observed metrics. Combines canary deployment at infrastructure level with user-level feature flags for fine-grained control.

"We rolled out the new editor progressively: 1% of users for 48 hours, then 10% for a week, then 50% after positive NPS signals, then 100%. Each phase gated on error rate <0.5%, satisfaction score above baseline, and no increase in support tickets."

The percentage of deployments that cause a degradation requiring remediation — a hotfix, rollback, or patch. One of the four DORA metrics. Elite performers have a change failure rate of 0–15%; high performers 16–30%. High rates indicate insufficient testing or review processes.

"Our change failure rate was 22% last quarter — above our 15% target. Root cause analysis showed that database migrations were responsible for 60% of failures. We introduced mandatory migration testing in staging with production-representative data, bringing the rate to 11%."