Delivery EngineeringAdvanced9 submodules

Deployment Strategies and Release Safety

Choose rolling, recreate, blue-green, canary, A/B, shadow, feature-flag, and rollback patterns based on availability, capacity, data compatibility, observability, and risk.

From concept to production evidence

Separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Learning outcomes

  • Compare major deployment strategies
  • Design zero-downtime prerequisites
  • Use feature flags and shadow traffic safely
  • Set promotion and abort criteria
  • Select and test rollback strategies

Deployment Strategies and Release Safety end-to-end flow

Use this sequence as the operating backbone for every submodule note and hands-on exercise.

  1. 01
    Deploy candidateDeployment Strategies and Release Safety stage 1: deploy candidate with an auditable result before the next stage begins.
  2. 02
    Prove readinessDeployment Strategies and Release Safety stage 2: prove readiness with an auditable result before the next stage begins.
  3. 03
    Shift controlled trafficDeployment Strategies and Release Safety stage 3: shift controlled traffic with an auditable result before the next stage begins.
  4. 04
    Compare health and business signalsDeployment Strategies and Release Safety stage 4: compare health and business signals with an auditable result before the next stage begins.
  5. 05
    Promote or abortDeployment Strategies and Release Safety stage 5: promote or abort with an auditable result before the next stage begins.
  6. 06
    Clean up or roll backDeployment Strategies and Release Safety stage 6: clean up or roll back with an auditable result before the next stage begins.

Architecture diagrams from Microsoft documentation

Use these diagrams beside the original Edukron notes and flows to compare the learning model with the official product and architecture view.

Official Microsoft CI/CD baseline architecture showing Azure Repos, pull request checks, CI, CD, staging, production, and monitoring.

CI/CD baseline architecture with Azure Pipelines

A pull-request pipeline validates changes, CI produces a versioned artifact, CD promotes it through staging and production, and Azure observability closes the feedback loop.

Run a progressive release

  1. Choose strategy from workload constraints
  2. Define health and business metrics
  3. Deploy backward-compatible candidate
  4. Shift traffic in stages
  5. Trigger promotion and rollback tests

9 full submodule notes

Read in order
01

Rolling deployment

Rolling deployment moves a versioned change toward users through repeatable validation, immutable artifacts, controlled promotion, and recoverable release decisions within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes
02

Recreate deployment

Recreate deployment moves a versioned change toward users through repeatable validation, immutable artifacts, controlled promotion, and recoverable release decisions within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes
03

Blue-Green

Blue-Green moves a versioned change toward users through repeatable validation, immutable artifacts, controlled promotion, and recoverable release decisions within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes
04

Canary

Canary moves a versioned change toward users through repeatable validation, immutable artifacts, controlled promotion, and recoverable release decisions within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes
05

A/B deployment

A/B deployment moves a versioned change toward users through repeatable validation, immutable artifacts, controlled promotion, and recoverable release decisions within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes
06

Feature flags

Feature flags provides a concrete platform capability that must be configured, secured, validated, observed, and owned throughout its lifecycle within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes
07

Shadow deployment

Shadow deployment moves a versioned change toward users through repeatable validation, immutable artifacts, controlled promotion, and recoverable release decisions within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes
08

Zero-downtime deployment

Zero-downtime deployment moves a versioned change toward users through repeatable validation, immutable artifacts, controlled promotion, and recoverable release decisions within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes
09

Rollback strategies

Rollback strategies restores a safe service state while preserving evidence and reducing the chance that mitigation introduces a second failure within Deployment Strategies and Release Safety. It is not an isolated definition: its value appears when it supports separate deployment from release, keep old and new versions compatible during transition, define objective promotion and abort signals, drain traffic safely, and rehearse recovery before a production event.

Open full notes