Design and implement build and release pipelines
Deployment Strategies and Release Safety
CoreSeparate deployment from release, order dependent changes safely, minimize downtime, and design observable rollback or roll-forward paths for code and databases.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
A release is a distributed state transition. Expert designs keep old and new components compatible while controlling audience exposure, health evaluation, and recovery.
Must Know
- Blue-green switches between complete environments; canary and rings expand exposure progressively; rolling replaces instances within availability limits.
- Feature flags separate code deployment from user exposure; A/B testing assigns cohorts to compare product outcomes rather than infrastructure health alone.
- Model dependency order in pipeline graphs and use backward-compatible expand-and-contract changes for databases and APIs.
- App Service slots allow warm-up and validation before swap; slot settings and stateful dependencies still require deliberate handling.
- A hotfix starts from the production release line, passes a defined protected path, and is merged back into every maintained line that needs it.
- Resilient deployment steps are idempotent, bounded by timeouts, observable, and safe to retry or resume.
- Build containers and binaries once, identify them immutably, and inject environment-specific configuration at deployment.
- Database migrations should run once, record completion, and preserve compatibility throughout rolling application deployment.
Compare and Distinguish
- Canary evaluates release health in a small cohort; A/B testing evaluates product outcomes between stable cohorts.
- A slot swap changes routing between app versions; a feature flag changes runtime exposure inside a version.
- Rollback restores a prior compatible state; roll-forward repairs with a new state when reversal is unsafe.
Scenario examples
- Scenario: A schema change must coexist with old instances. Think: expand, deploy compatible code, migrate use, then contract.
- Scenario: A risky release needs progressive health evaluation. Think: canary or rings with pause and rollback criteria.
Exam traps
- Rebuilding per environment destroys evidence that staging and production received the same bits.
- A feature flag without owner or expiry becomes permanent operational debt.
- A database rollback is not always safe after irreversible data transformation.
Key takeaways
- Design compatibility windows before ordering deployment steps.
- Choose strategy by exposure and recovery need, not by fashionable name.
- Make every release observable and every recovery path rehearsable.
How it works
- Progressive strategies shift a bounded audience, evaluate defined health evidence, and expand only when pause criteria remain satisfied.
- Explicit pipeline dependencies place schema, infrastructure, application, and activation changes in their safe order.
Objects and administrative surfaces
- Azure Pipelines deployment jobs, environments, strategies, checks, artifacts, and database tasks.
- GitHub Actions environments, deployment protection, concurrency, container registries, release assets, and cloud deployment actions.
- Azure App Service slots and Azure App Configuration Feature Management.
When to use it
- Use blue-green or slots when a complete warmed environment and rapid traffic reversal matter more than incremental replacement.
Security and governance implications
- Predefine emergency authority, retain artifact provenance, and keep production configuration and credentials outside the built binary.
Troubleshooting signals
- When a rollout degrades, compare cohort, version, configuration, dependency, readiness, and migration state before expanding or reversing.
More detail
- Use canary or rings for progressive operational exposure and A/B testing for stable cohorts measuring a product hypothesis.
- Apply expand-and-contract database changes before rolling code requires them, and postpone incompatible contraction until old code is gone.
- Make deployment actions idempotent, observable, bounded by timeouts, and recoverable through a tested rollback or roll-forward path.
Ready for the quiz?
- When is A/B testing not a canary deployment?
- Why should a migration be idempotent?
- What must be checked before reversing an App Service slot swap?
Related objectives
- D3.4.S1 — Design a deployment strategy, including blue-green, canary, ring, progressive exposure, feature flags, and A/B testing
- D3.4.S2 — Design a pipeline to ensure that dependency deployments are reliably ordered
- D3.4.S3 — Plan for minimizing downtime during deployments by using load balancing, rolling deployments, and deployment slot usage and swap
- D3.4.S4 — Design a hotfix path plan for responding to high-priority code fixes
- D3.4.S5 — Design and implement a resiliency strategy for deployment
- D3.4.S6 — Implement feature flags by using Azure App Configuration Feature Manager
- D3.4.S7 — Implement application deployment by using containers, binaries, and scripts
- D3.4.S8 — Implement a deployment that includes database tasks