Deployment Strategies: Release in Small, Measurable Steps
Compare blue-green, canary, rings, feature flags, and A/B testing, then design a rollout with real stop and rollback conditions.
Open one checkout lane before changing the whole shop
A shop can trial a new checkout with a small customer group, watch queue time and failed payments, then expand. Releasing software follows the same principle: limit exposure and observe meaningful signals before increasing it.
Deployment puts a version into an environment. Release exposes a capability to users. Feature flags can separate those events, but only if both code paths and dependencies support it.
| Strategy | Main mechanism | Important trade-off |
|---|---|---|
| Blue-green | Maintain two environments and switch traffic | Extra capacity; data compatibility still matters |
| Canary | Send limited traffic to the new version | Requires trustworthy routing and comparable telemetry |
| Rings | Expand through defined audiences or environments | Ring membership must represent intended risk |
| Progressive exposure | Increase exposure after measured checks | Needs explicit thresholds and observation windows |
| Rolling | Replace instances incrementally | Old and new versions coexist |
| Feature flag | Switch behavior independently of deployment | Flags need lifecycle, testing, and fallback |
| A/B test | Compare alternatives against a defined hypothesis | Requires experiment design, not just traffic splitting |
A canary tests operational safety of a rollout; an A/B experiment tests a product hypothesis. They can overlap, but neither label automatically supplies the other’s evidence.
Design a canary decision
For the fictional booking service, a plan might say:
Artifact: exact tested image digest.
First exposure: a small permitted cohort.
Observe: booking completion, errors, latency, duplicate confirmations.
Compare: same time window and comparable traffic on stable version.
Stop: agreed customer-impact threshold or broken dependency.
Expand: only after enough representative traffic and a reviewed result.
Recover: route back and verify stable service.Percentages and time windows must reflect real traffic. Five quiet minutes with two requests is not strong evidence. Check both aggregate metrics and the exposed cohort; an error affecting 1% of users can disappear in a whole-service average.
An agent can summarize telemetry and explain threshold breaches, but an autonomous expansion must still be constrained by the approved release policy. Do not let a natural-language “looks healthy” replace the actual measurements.
Understand App Service slots
App Service deployment slots are live applications with separate hostnames on supported plan tiers. Deploying to a staging slot can support validation before a swap. A slot is not automatically isolated from production databases or queues; review its settings and outbound dependencies.
During a swap, content and swappable configuration move according to App Service’s documented behavior. Settings marked as deployment-slot settings stay with their slot. Review connection strings, authentication, certificates, and other settings rather than assuming everything swaps identically.
Swap with preview separates applying target configuration from completing the swap. A reverse swap can restore prior application content, but it does not undo external database writes or queued work.
Warm up and health-check the target application before switching traffic. Keep session handling and startup dependencies in mind. “Zero downtime” is an outcome to verify, not a feature checkbox.
Rolling and load-balanced deployments
With rolling replacement, keep enough healthy capacity while updating instances. Configure readiness checks and traffic draining so new instances do not receive traffic before they can serve it, and old instances can finish requests when appropriate.
In Azure Pipelines deployment jobs, supported rolling strategy behavior is target-specific; the documented rolling strategy applies to virtual machine resources. Do not assume one YAML strategy works unchanged for every App Service or Kubernetes deployment.
For containers, deploy reviewed manifests and an exact image identity, observe rollout health, and inspect customer-facing behavior. A scheduler reporting “available” cannot prove a business transaction succeeded.
Manage feature flags as production configuration
Flags can target users, groups, or percentages through supported feature-management libraries and services. Define a safe default, who may change targeting, telemetry dimensions, and a removal date.
Test both on/off behavior and partial failures. A flag that hides a button does not remove a server-side authorization requirement. An old code path may still fail if a new database schema removed a field it needs.
A slot swap is reversed after a release problem. Which change is not automatically undone?
Try it: tabletop a partial rollout
Prerequisites: no cloud account is required for the tabletop exercise. Creating duplicate environments or slots can incur charges and requires supported tiers.
Choose a harmless application change. Draw stable/new traffic paths, identify shared data, and define one rollout signal and one stop condition. Walk through a failure after some users have already written data with the new version. Explain what routing back repairs and what it cannot repair.
Expected observation: the recovery plan handles shared state and partial exposure, not just the deployment command.
Cleanup: a tabletop has no resources. If you separately created sandbox slots or containers, remove only those exercise resources after preserving any needed data.
Decision check: can we claim no downtime?
Measure customer-facing availability during the change. A successful swap task and a green infrastructure health probe are necessary evidence, not proof of every user journey.