AZ-400: Designing and Implementing Microsoft DevOps Solutions

Design and Implement Deployments

Exploring Deployment Strategies

When delivering new software versions, a solid deployment strategy is essential to minimize risk, maintain uptime, and support continuous delivery. In this guide, we’ll walk through six proven approaches to streamline your release process and ensure a smooth user experience.

Key Benefits of Deployment Strategies

  • Risk Management: Contain failures and reduce blast radius.
  • Improved Uptime: Roll out updates in stages to avoid downtime.
  • Continuous Delivery: Deploy features more frequently with confidence.

The image is a slide titled "Deployment Strategies – Introduction," listing six strategies: Blue/Green, Canary, Ring, Progressive Exposure, Feature Flags, and A/B Testing.

Table of Contents

  1. Blue/Green Deployments
  2. Canary Releases
  3. Ring Deployments
  4. Progressive Exposure
  5. Feature Flags
  6. A/B Testing

Blue/Green Deployments

Blue/Green deployments use two identical production environments to achieve near-zero downtime and instant rollback capabilities.

  1. Build and validate version B in the blue environment.
  2. Switch the router or load balancer so all traffic flows to blue.
  3. Monitor metrics; if issues occur, revert traffic to green immediately.

The image illustrates a Blue/Green deployment process, showing a user connecting through a router to either a new version deployment or the current production application.

Note

Blue/Green is ideal when you need a fast rollback plan and zero interruption for end users.

The image is about Blue/Green Deployments, highlighting the ability to quickly roll back if issues arise and enhancing overall system reliability.


Canary Releases

Canary deployments roll out new features to a small subset of users, enabling early detection of performance regressions before a full release.

  • Deploy the new version to a limited group of servers or users.
  • Collect metrics, logs, and user feedback.
  • Gradually increase traffic to the canary cohort if all health checks pass.

The image is a diagram titled "Canary Deployments," showing a process where developers monitor performance and catch potential issues early.

If anomalies arise, you can halt the rollout or roll back with minimal impact.


Ring Deployments

Ring deployments build on canary by defining multiple user “rings” that receive updates in succession. Rings are often organized by geography, device type, or user role.

  1. Insiders: Internal team or trusted testers.
  2. Pilot: Small subset of external users.
  3. Targeted: Larger user segment.
  4. Broad: All remaining users.

The image illustrates a "Ring Deployments" process with a series of overlapping circles labeled Insider, Pilot, Targeted, and Broad, along with categories for Geography, Device Type, and Usage.

Warning

Managing multiple rings introduces complexity in monitoring and coordination—plan your automation carefully.


Progressive Exposure

Progressive exposure combines canary and ring patterns by advancing through well-defined stages based on real-time metrics. This method works well for large-scale features that require validation under varying loads.

The image illustrates a "Progressive Exposure" process with a flowchart showing stages: Canary, Pilot Customers, Light-Load Regions, and Medium-Load Regions. Each stage is represented by a box connected with arrows, indicating a sequential progression.

Stages

  • Canary: Initial validation with minimal users.
  • Pilot Customers: Trusted external testers.
  • Light-Load Regions: Early geographic rollout.
  • Medium-Load Regions: Expanded coverage upon successful metrics.

Feature Flags

Feature flags (also known as feature toggles) decouple code deployment from feature release, granting granular control over who sees new functionality.

  • Turn features on/off at runtime without redeploying.
  • Perform dark launches by toggling visibility.
  • Enable canary or phased rollouts by flagging select user segments.
  • Instantly disable problematic features to avoid full rollback.

The image illustrates the concept of feature flags, showing how new features can be toggled on for development and quality assurance teams, while remaining off for production users.

Note

Use a centralized flag management service to avoid flag sprawl and technical debt.


A/B Testing

A/B testing (split testing) helps you compare two or more variants of a feature to identify which one best meets your key performance indicators (KPIs).

  • Serve version A to one cohort and version B to another.
  • Collect behavioral data (e.g., click-through rates, conversions).
  • Analyze results statistically and roll out the winning variant.

A/B testing fosters data-driven decisions and continuous optimization of user experience.


Strategy Comparison

StrategyKey BenefitIdeal Use Case
Blue/GreenInstant rollback, zero downtimeMajor version upgrades
CanaryEarly anomaly detectionHigh-risk features, backend services
RingControlled phased releaseLarge user bases with varied geographies
Progressive ExposureMulti-stage validationComplex features requiring load-specific testing
Feature FlagsRuntime control, dark launchesIncremental feature releases, quick disablement
A/B TestingData-driven UX improvementsUI/UX experiments, marketing campaigns

By combining these deployment strategies according to your application’s risk profile and traffic patterns, you can achieve reliable, efficient, and resilient software releases.

Watch Video

Watch video content

Previous
Introduction Designing and Implementing Deployments