Blue-green deployment separates old and new application environments; canary deployment limits exposure while comparing a new release with a control. They can be combined. Choose the routing, observation and recovery design from your workload’s failure tolerance, traffic and data compatibility rather than treating either label as a guarantee of zero downtime.

Key takeaways

• Environment topology and exposure strategy are separate decisions.
• A canary needs representative traffic and trustworthy release-level telemetry.
• Switching traffic back does not undo database writes or external side effects.
• Agree halt criteria, decision ownership and recovery before starting a rollout.

Blue green vs canary deployment: separate topology from exposure

A blue-green design maintains distinct current and candidate application pools. A router, load balancer or platform deployment mechanism directs requests to the appropriate version. The previous pool can remain available for a controlled reversal, subject to data and dependency compatibility.

A canary design sends a bounded portion of eligible production work to the candidate. The team compares its behavior against a control and decides whether to expand, hold or stop. A blue-green pair can itself receive traffic progressively, so the patterns are not mutually exclusive.

Microsoft’s safe-deployment guidance emphasizes progressive exposure, health checks and stopping releases when health deteriorates. Google’s SRE workbook describes canary evaluation against a control. These principles require an observable workload; a deployment tool cannot supply missing business signals automatically.

Versioned artifact → candidate environment → synthetic and compatibility checks
Production router → control pool + bounded candidate cohort
Release-level signals → hold / expand / recover
Shared dependencies → compatible schema, messages and side effects

Determine the unit of routing: request, session, account, tenant, region or deployment stamp. Request-level percentages can expose one customer to both versions. Tenant-level assignment preserves a stable experience but may produce uneven workload volumes. Background consumers also need a partition or assignment strategy; an HTTP traffic rule does not constrain every worker.

A practical decision table

Estimate temporary overlap costs, operational complexity and capacity headroom. A smaller canary can reduce initial exposure, but a broken shared dependency can still affect the control. Isolation must match the failure mode being tested.

Use the failure budget to bound exposure

Start from an agreed service-level objective and incident policy. Record remaining error budget, critical transactions and the largest acceptable release impact. Do not consume the entire remaining budget merely because a rollout is technically permitted.

Illustrative planning example, not a measured result: assume 100,000 eligible requests during one observation window, a 5% candidate share and a candidate error-rate increase of two percentage points. The simple expected additional failures are 100,000 × 0.05 × 0.02 = 100 requests.

This estimate assumes stable traffic allocation and comparable request mix. It is not a worst-case bound: a schema defect, shared cache corruption or external write can propagate beyond the candidate. Plan for the credible failure scenario as well as the arithmetic expectation.

If the agreed release allowance is smaller than the modeled impact, reduce exposure, improve detection or change the release method. If the control also deteriorates, investigate shared dependencies instead of automatically declaring the candidate healthy because the difference is small.

Define an emergency route for necessary fixes. A policy should identify who can approve an exception, what checks remain mandatory and how the decision is recorded. “Emergency” should not silently disable every deployment safeguard.

Database compatibility determines whether rollback works

Use an expand-and-contract migration when old and new application versions must coexist. Introduce compatible structures first, deploy code that tolerates both forms, migrate data with reconciliation, then remove obsolete structures only after older consumers are retired.

1. Add the new field or table without immediately removing the old contract.
2. Verify both application versions against the expanded schema.
3. Backfill using an owned, observable and restartable migration.
4. Change reads or writes in controlled stages and reconcile divergence.
5. Retire the old contract after the recovery window and dependent consumers are reviewed.

This is a design sequence, not a database-specific migration script. Concurrent writes, transaction boundaries and dual-write consistency need workload-specific engineering. Never assume that copying records makes two stores equivalent.

Include queues, event schemas, scheduled jobs and third-party APIs in the compatibility review. A candidate can emit a message that the old worker cannot read. Returning web traffic to the previous pool then leaves the incident unresolved.

Classify recovery actions: route reversal for compatible application defects, feature disablement for isolated behavior, forward fix for incompatible data changes, and reconciliation for external side effects. Test the selected actions before production.

Monitoring gates for progressive delivery

Tag telemetry with release version and environment, keeping sensitive information out of labels. Inspect request count, failures, latency distribution, resource saturation and critical business completion. Add queue age, message failures or reconciliation status where those better describe the workload.

• Coverage gate: the candidate has exercised the important operations and user groups.
• Health gate: service objectives and agreed candidate-versus-control limits remain acceptable.
• Data gate: reconciliation and compatibility checks show no unexplained divergence.
• Capacity gate: the next wave and recovery path have sufficient headroom.
• Observation gate: delayed effects and relevant business cycles have had time to appear.

Set thresholds from a baseline and risk assessment. A generic five-minute wait or a universal traffic percentage is not enough. Missing telemetry should hold promotion until the team understands the gap. Avoid letting the absence of samples count as a passing result.

Account for slow jobs, regional usage and day-boundary behavior. Correlate symptoms with deployment events, but do not assume every incident during rollout was caused by the release. Keep the previous version, artifact identity and configuration available for investigation.

Two worked release examples

Customer portal with compatible API changes

In a hypothetical portal release, a separate candidate pool runs the new API against an additive schema. Internal checks exercise login, account access and transaction creation. A stable customer cohort receives the candidate while similar control traffic continues on the existing pool.

The team holds expansion until critical journey results, latency and data reconciliation pass. A release-specific rise in failed transactions triggers route reversal. Before using that recovery path, the team has confirmed the old version can read data produced by the candidate. This combines blue-green infrastructure with canary exposure.

Background billing processor with external effects

A fictional billing worker upgrade cannot safely be tested through random HTTP routing. The team assigns an explicit account cohort to the candidate, uses idempotency controls and reconciles expected versus recorded actions. It prevents two workers from independently owning the same work.

If the candidate creates an incorrect external action, stopping it prevents further exposure but does not reverse completed actions. Recovery follows a reviewed correction procedure with finance ownership. The release design therefore includes reconciliation and human approval rather than claiming instant rollback.

A release checklist your team can execute

1. Identify artifact, configuration and dependency versions.
2. Document cohort assignment and shared failure domains.
3. Validate schema and message compatibility with both versions.
4. Confirm monitoring, thresholds and minimum evidence coverage.
5. Rehearse routing reversal or the chosen forward-recovery path.
6. Name the person accountable for hold, promotion and recovery.
7. Expand only after each gate passes; record the evidence.
8. Retire the old pool and contracts deliberately after the recovery window.

Connect this plan to the enterprise CI/CD workflow and Azure gateway architecture. This guide focuses on release exposure and recovery, rather than selecting a pipeline product.

Common questions

Design a release path with credible recovery

Bring service objectives, traffic patterns and data contracts to a review. Discuss a cloud architecture and cost review to map rollout cohorts, monitoring gates and recovery responsibilities for your workload.