AZ-400 Release Strategy
Design & implement a release strategy
Design & Implement a Release Strategy — MOC
MS Learn path: Design and implement a release strategy · The CD half — delivering every change safely to production.
Planned concepts
Continuous delivery · release-strategy · deployment-ring · blue-green-deployment · canary-deployment · feature-flags · release-definition · deployment-gate · rollback-strategy · Sneak/verified environments
Canvas
Modules in this path
- Introduction to Continuous Delivery
- Design a release strategy
- Deployment patterns
- Deployment gates and rollback
Skills
Release pipeline, deployment patterns, rollback.
Practice questions
- az400-q-release-001 — blue-green deployment
- az400-q-release-002 — canary rollout + deployment gates
Introduction to Continuous Delivery
MS Learn path: Design and implement a release strategy — module 1.
Overview
Introduces the shift from manual release management to continuous delivery (CD): what CD is, why it matters, and how a release pipeline carries validated artifacts safely to production.
Units
- What is continuous delivery?
- Continuous delivery vs continuous deployment
- The release pipeline & stages
- Release strategies overview
Concepts introduced
Key terms & commands
- CI → produces a validated build artifact; CD → releases it.
- Continuous deployment = every passing change auto-released (stricter than CD).
- Azure Pipelines:
releasepipelines / multi-stage YAML.
Hands-on
⚠ verify — add a hands-on exercise (create a release pipeline, add a stage).
Exam focus
- Know the CD vs continuous-deployment distinction.
- Understand that CD keeps changes always releasable and relies on automation + rollback.
Related
Design a Release Strategy
MS Learn path: Design and implement a release strategy — module 2.
Overview
Covers how to choose and design a release strategy: selecting rollout patterns based on risk, defining progressive exposure, and planning release cadence and approvals.
Units
- Choosing a release strategy
- Progressive delivery concepts
- Release cadence & approvals
- Considerations for rollout (blast radius, monitoring)
Concepts introduced
Key terms & commands
- Progressive exposure — release to a small group, observe, expand.
- Blast radius — how many users a bad release affects; minimize it.
- Choose pattern by risk tolerance & zero-downtime needs.
Hands-on
⚠ verify — add an exercise designing a rollout for a sample app.
Exam focus
- Match rollout patterns to scenarios (rings, canary, feature flags).
- Understand how telemetry/validation drives rollout decisions.
Related
release-strategy · deployment-ring · feature-flags · cd · Path MOC
Deployment Patterns
MS Learn path: Design and implement a release strategy — module 3.
Overview
Explores the concrete deployment patterns teams use to ship safely: blue/green, canary, ring-based rollouts, and slot-based swaps — and when to pick each.
Units
- Blue/green deployment
- Canary deployment
- Rolling / ring-based deployment
- Slot-based swap (App Service)
- Comparing patterns by trade-offs
Concepts introduced
Key terms & commands
- Blue/green → two environments + atomic switch; instant rollback.
- Canary → small % + metric-gated expansion.
- Rings → ordered cohorts with gates.
- Slot swap on App Service = zero-downtime blue/green.
Hands-on
⚠ verify — add an exercise using App Service slot swaps and a canary-style rollout.
Exam focus
- Compare patterns: blue/green = atomic switch + instant rollback; canary = gradual + telemetry; rings = cohort-based.
- Know slot-based swapping for PaaS zero-downtime release.
Related
blue-green-deployment · canary-deployment · deployment-ring · deployment-slots · Path MOC
Deployment Gates and Rollback
MS Learn path: Design and implement a release strategy — module 4.
Overview
Covers the control mechanisms that make releases safe: deployment gates and approvals that pause releases until conditions are met, and rollback strategies that bring a bad release back to a known-good state.
Units
- Deployment gates & approvals
- Pre-deployment vs post-deployment gates
- Monitor/query-based gates
- Rollback strategies & forward fix
Concepts introduced
Key terms & commands
- Approval gate — human sign-off.
- Azure Monitor gate — metric/log query must pass.
- Pre/post-deployment gates per stage.
- Rollback — flip traffic (blue/green), stop canary, or kill-switch the flag.
Hands-on
⚠ verify — add an exercise adding an approval + monitor gate and a rollback.
Exam focus
- Gates: pre- vs post-deployment, approval/Monitor/work-item types, retries & timeouts.
- Rollback: match mechanism to pattern; feature-flag kill switch = fastest, blue/green = instant.
- Stateful/schema changes may need forward-fix over rollback.
Related
deployment-gate · rollback-strategy · release-definition · feature-flags · Path MOC
Core CD
Continuous Delivery (CD)
What it is
Continuous Delivery (CD) is the practice of automatically building, packaging, and preparing every validated change so it can be released to any environment (dev → test → staging → production) with the push of a button — or fully automatically. It’s the “delivery” half of CI/CD, running after Continuous Integration produces a tested artifact.
Why it exists
CI proves every change builds and passes tests. CD extends that to prove every change is always in a releasable state and can get to production quickly and safely. It shrinks the time between “code merged” and “value delivered to users” and removes the risky, manual, error-prone “release day” ritual.
Key ideas
- Automation: a pipeline (e.g. release pipeline in Azure Pipelines/GitHub Actions) carries a build artifact through stages: deploy → test → smoke → sign off → production.
- Releasable state, not necessarily released: CD makes a release possible and easy; it doesn’t force auto-releasing to users.
- Continuous deployment is the stricter cousin: every change that passes the pipeline is automatically released to production with no human approval. CD is a prerequisite; continuous deployment is a choice layered on top.
- Relies on deployment gates (quality/approval checkpoints), rollback, and automated environment parity.
How it fits
Code → CI (build+test) → CD pipeline → stage → gates → production
Exam notes
- Distinguish continuous delivery (change is ready to release; deployment to production may be manual) from continuous deployment (every change is released automatically).
- CD requires high test automation and rollback capability; without those, you can’t safely auto-release.
- In Azure Pipelines, releases are modeled with stages + approval/gates (see deployment-gate).
Related
release-strategy · release-definition · deployment-gate · rollback-strategy · feature-flags · deployment-ring
📘 Source: Microsoft Learn — Cd
Release strategy
What it is
A release strategy is the set of decisions about how, when, and to whom a new version of software is delivered to production. It covers the deployment model, the rollout pattern, the cadence, who approves it, how it’s monitored, and how to undo it. It’s the answer to: “How do we ship this change safely?”
Why it exists
Releasing directly to all users at once is high-risk: a single bad change becomes a global outage with no gradual containment. A deliberate release strategy reduces the blast radius of bad releases, gets feedback earlier, and lets teams release more often with confidence.
Key ideas
- Release = deploy + verify + rollback path. Deployment is putting the bits somewhere; release is making them available to users — the two don’t have to happen together (e.g. feature flags decouple them).
- Choose a pattern by risk tolerance:
- Big-bang / all-at-once: simplest, highest risk.
- Blue/green: two full environments, atomic switch over.
- Canary: release to a small subset, watch metrics, expand.
- Rings: staged rollout across progressively larger audiences.
- Feature flags: ship code dark, release functionality separately.
- Define the rollout cadence (e.g. weekly), approvals/gates, and a rollback strategy up front.
- Progressive exposure lets you limit risk while still shipping fast.
How it fits
Release strategy is the umbrella; deployment patterns are the mechanisms. CD pipeline → choose pattern → monitor → expand or rollback.
Exam notes
- Match the pattern to the scenario: zero-downtime + instant switch → blue/green (often deployment slots); gradual risk-controlled rollout with live traffic → canary or rings.
- Canary and ring rollouts rely on monitoring/telemetry to decide whether to continue; feature flags let you turn functionality on/off without redeploying.
- Release strategy choices directly shape the release pipeline design.
Related
cd · deployment-ring · blue-green-deployment · canary-deployment · feature-flags · rollback-strategy
📘 Source: Microsoft Learn — Release Strategy
Release definition (release pipeline)
What it is
A release definition (the classic “release pipeline” in Azure Pipelines) is the automated pipeline that carries a validated build artifact through stages — e.g. Dev → Test → Staging → Production — deploying it and running validation at each step. It’s the executable expression of a release strategy and of continuous delivery.
Why it exists
Manual deployments are slow, inconsistent, and risky. A release definition encodes how a release happens so every release follows the same, repeatable, audited path: deploy to each environment, run smoke/QA, pass gates or approvals, and finally reach production — with a rollback path when things go wrong.
Key ideas
- Stages = environments/gates the artifact flows through (Dev → Test → Prod).
- Deployment jobs/tasks per stage (e.g. deploy to App Service, run tests, publish).
- Deployment gates & approvals: pre-deployment and post-deployment checks (manual approval, health metrics, work items) that pause or block the release until criteria are met.
- Artifact source: consumes the build output from CI (build pipeline) — CI produces, CD consumes.
- Triggers: auto on new artifact (continuous deployment) or manual.
- Modern equivalent: YAML multi-stage pipelines with environments; classic releases are the GUI-driven model.
How it fits
CI produces a tested artifact; the release definition carries it to production safely. It is the tooling layer that implements CD and the chosen release strategy.
Exam notes
- Release definition = stage-based deployment pipeline for artifacts, distinct from the build (CI) pipeline.
- Gates and approvals are configured on stages and can be pre- or post-deployment.
- Continuous deployment = a release triggered automatically on new artifact; with approvals required, it becomes semi-automated.
Related
cd · deployment-gate · rollback-strategy · release-strategy · build-artifact
📘 Source: Microsoft Learn — Release Definition
Deployment patterns
Blue/green deployment
What it is
Blue/green deployment is a release pattern that maintains two identical production environments — blue (current) and green (new) — and switches user traffic between them in a single, near-instantaneous cutover. You deploy the new version to green, validate it, then redirect the router/load balancer from blue to green atomically. Blue stays ready as the instant fallback.
Why it exists
By keeping the previous environment warm, you get zero-downtime releases and a trivial, atomic rollback: if green fails, point traffic back at blue. This eliminates the in-place-upgrade window where old and new code coexist on the same instances.
Key ideas
- Two full environments (compute, config, DB migrations considered) — green is fully prepared before any traffic moves.
- Atomic switch: a load balancer / router / deployment slot swap redirects traffic — instant, no per-instance draining.
- Rollback = switch back — flip the router to the previous environment rather than redeploying.
- On Azure, App Service deployment slots are a common blue/green implementation (swap slots).
- Cost/consistency note: you run two environments (doubled capacity), and stateful components (databases) must be handled carefully so both colors share compatible state.
How it fits
Blue/green is a deployment pattern selected by the release strategy. It prioritizes instant switch + instant rollback over gradual exposure.
Exam notes
- Blue/green = two environments + atomic traffic switch; gives zero downtime and instant rollback.
- Choose blue/green when you need a clean cutover with immediate fallback (e.g. slot swap on App Service).
- Contrast with canary (gradual %) and rings (cohort-based) which give progressive exposure rather than an all-at-once switch.
Related
release-strategy · deployment-slots · rollback-strategy · canary-deployment · release-definition
📘 Source: Microsoft Learn — Blue Green Deployment
Canary deployment
What it is
Canary deployment is a progressive rollout technique that sends the new version to a small subset of real users or servers first (“canaries”), monitors their behavior and telemetry, and only if they look healthy expands the rollout to a wider audience until all traffic is on the new version. The name comes from coal-mine canaries — a warning system for the rest of the flock.
Why it exists
You get real-world validation on live traffic with a small blast radius. A bad change only affects the canary cohort initially; you detect it from metrics (errors, latency) before exposing everyone, then either continue the rollout or roll back the canary.
Key ideas
- Small %, real traffic: route e.g. 5–10% of traffic to the new version (via load balancer weight, traffic manager, service mesh, or slot swap that takes a fraction).
- Driven by telemetry: decide to expand only when health/error/latency metrics for the canary stay within thresholds. Automated via deployment gates (e.g. monitoring gates).
- Controlled expansion: 5% → 25% → 50% → 100% as each step validates.
- Rollback is easy: remove the canary / route traffic back to the stable version.
- Often combined with feature flags to gate functionality exposure independently of the code rollout.
How it fits
Canary is a progressive-delivery pattern under the release strategy. It gives gradual, metric-gated exposure — unlike blue/green, which switches everything at once.
Exam notes
- Canary = release to a small percentage, monitor, then expand; driven by health/error telemetry, not time alone.
- Distinguish from rings (canary = random/small traffic %; rings = defined user cohorts) and blue/green (full swap).
- Use a monitoring/health gate (deployment-gate) to automate the canary → full rollout decision.
Related
release-strategy · deployment-ring · feature-flags · rollback-strategy · deployment-gate
📘 Source: Microsoft Learn — Canary Deployment
Deployment rings
What it is
Deployment rings (also called release rings or zones) are a progressive rollout model where a new version is deployed to an ordered sequence of environments/audiences, each representing a larger and less-risky group of users, with validation gates between them. A classic Microsoft pattern is Ring 0 (developer/early adopter) → Ring 1 (pilot/insider) → Ring 2 (production subset) → Ring 3 (worldwide).
Why it exists
Instead of releasing to everyone at once, rings let you expose a change to a small, tolerant, or internal audience first, observe real-world behavior, and only widen the rollout once each ring proves healthy. It contains the blast radius of bad releases while still shipping to production quickly.
Key ideas
- Each ring is a ring of users/environments that gets the release after the inner ring is validated. Rings grow in size and decrease in safety.
- Progressive exposure: the same build flows ring-by-ring; a gate (health metrics, error rates, manual approval) decides whether to proceed to the next ring.
- Use a feature flag as the control to turn the functionality on per ring while the code is already deployed.
- Rollback per ring: if a ring degrades, stop and roll back that ring instead of the whole world.
- Common in large-scale SaaS; Azure/Microsoft 365 themselves use ring rollouts.
How it fits
Rings are a specific implementation of progressive delivery. Unlike canary (a small, often random traffic %), rings are cohort-based (defined groups) with explicit gates between them.
Exam notes
- Rings = ordered cohorts + gates between them; inner rings are more technical/tolerant (devs, insiders), outer rings are all users.
- Combine rings with feature flags to gate functionality exposure and with deployment gates to automate ring transitions.
- Ring failures are handled by stopping the rollout and rolling back the affected ring, not necessarily the whole deployment.
Related
release-strategy · canary-deployment · feature-flags · deployment-gate · rollback-strategy · cd
📘 Source: Microsoft Learn — Deployment Ring
Feature flags (feature toggles)
What it is
Feature flags (feature toggles / switches) are configuration switches in code that let you turn a feature on or off at runtime — without redeploying. The code is shipped to production with the feature present but dark; a flag controls whether users see it. In Azure, Azure App Configuration provides managed feature-flag management.
Why it exists
They decouple deployment from release: you can deploy code (which is technically live) but only release the functionality when you choose. This enables dark launches, trunk-based development on short-lived branches, instant kill-switch rollback (turn the flag off instead of redeploying), and per-audience rollouts.
Key ideas
- Deploy ≠ release: code ships always-on ready; the flag determines when and to whom the feature is visible.
- Kill switch: disabling a flag is the fastest possible rollback — no redeploy, no downtime.
- Audience targeting: flags can vary by user, ring, percentage, or environment — powering ring and canary rollouts and gradual rollout percentages.
- Safe defaults: a flag should default to off for a new feature (or to a safe value) so a misconfig doesn’t expose it.
- Flag hygiene: remove flags once the feature is fully rolled out — dead toggles are tech debt and a risk.
- Azure App Configuration centralizes flags with .NET/Java/other SDKs and
Microsoft.FeatureManagement.
How it fits
Feature flags are a release-mechanism used inside a release strategy to expose functionality gradually and to provide a fast rollback path independent of the deployment pipeline.
Exam notes
- Feature flags let you release functionality without a deployment — the strongest differentiator vs other patterns.
- Best known for kill-switch rollback and progressive/percent rollouts and per-ring targeting.
- Remember flag cleanup and safe defaults; know that Azure App Configuration is the managed home for flags.
Related
release-strategy · deployment-ring · canary-deployment · rollback-strategy · release-definition
📘 Source: Microsoft Learn — Feature Flags
Controls & safety
Deployment gates
What it is
Deployment gates are automated or approval-based checkpoints in a release pipeline that pause a release before (pre-deployment) or after (post-deployment) a stage until specified conditions are met. If a gate fails, the release is held or fails rather than continuing to the next environment.
Why it exists
A pipeline that blindly deploys to production is dangerous. Gates let you enforce “is it healthy enough to proceed?” — checking live telemetry, approvals, and work-item status — before expanding a rollout or cutting over. They make release decisions data-driven and governed instead of blind or manual-only.
Key ideas
- Approval gate: a human (often a different team/role) explicitly approves before/after a stage.
- Azure Monitor / query-based gates: evaluate a metric/log query (e.g. error rate, latency) and pass only when it’s within threshold.
- Work item gate: require relevant work items/change-requests to be associated.
- Pre-deployment vs post-deployment: pre = “can we go to this stage?”, post = “did this stage come out healthy?” — post-deployment gates are key for progressive rollout decisions (canary/ring expansion).
- Retries & timeout: gates run repeatedly over a window (e.g. every N minutes) and fail if never satisfied.
How it fits
Gates are the control mechanism that turns a release strategy into practice — especially for canary and ring rollouts, where metrics decide whether to widen or stop the rollout.
Exam notes
- Gates can be pre-deployment or post-deployment and are configured per stage in a release.
- Types include approvals, Azure Monitor (metrics/logs), and work item gates.
- Post-deployment monitoring gates are what automate canary/ring expansion and enable safer continuous deployment.
Related
release-definition · canary-deployment · deployment-ring · cd · rollback-strategy
📘 Source: Microsoft Learn — Deployment Gate
Rollback strategy
What it is
A rollback strategy is the pre-planned, repeatable way to return a service to a known-good state after a bad release. It defines how you undo or compensate for a failed deployment — redeploy the previous version, switch traffic back, or toggle a flag — and who triggers it and how fast.
Why it exists
Bad releases happen. The cost isn’t the failure itself but how long it takes to recover. A deliberate rollback plan minimizes mean time to recover (MTTR) and limits user impact, so teams can ship faster without fear — because they know they can always get back to a good state.
Key ideas
- Deployment pattern drives rollback:
- Blue/green → flip traffic back to the previous environment (instant).
- Canary / rings → stop expanding and route the affected subset back to the stable version.
- Feature flags → disable the flag (kill switch) — often fastest, no redeploy.
- Forward fix / redeploy → ship a corrective build; fallback when rollback isn’t viable (e.g. incompatible DB schema).
- Statefulness is the hard part: databases/schema migrations may not be simply reversible — plan for forward-fix or data-compatible migration alongside code rollback.
- Automate & rehearse: gate-triggered or on-call-triggered rollback should be tested, not improvised at 2am.
- Pair with deployment gates (post-deployment health checks) to detect the need to roll back early.
How it fits
Rollback is the safety net that makes aggressive continuous delivery viable. Every release strategy must answer: “If this goes wrong, how do we get back to good?” — before shipping.
Exam notes
- Rollback should be pre-planned and (ideally) automated/tested; match the mechanism to the deployment pattern.
- Feature flags = fastest rollback (kill switch, no redeploy).
- Blue/green = instant rollback by switching environments.
- Watch for stateful/data issues: a code rollback may not undo a schema migration — consider forward-fix.
Related
blue-green-deployment · canary-deployment · feature-flags · deployment-ring · release-strategy
📘 Source: Microsoft Learn — Rollback Strategy