Lab: ordered, resilient release paths

Outcome

Model a safe release of a disposable web workload through an additive database change, a binary/container artifact, a deployment slot or training target, and a measured rollback decision.

Before you begin

Start with the database-safe release lab and the feature-flag rollout lab. Use only a training App Service/Container App or an echo deployment; Azure resources can cost money. Keep the workload owner, runtime, data store, network boundary, deployment identity, and rollback owner in a short runbook.

Do

1. Build once: package a harmless API as either a versioned container image or a zipped binary. Attach its commit SHA and version to the artifact. Do not rebuild the same version for each environment.
2. Define the deployment graph: additive database migration → compatible application version → smoke test → feature exposure. Make the application reject deployment when the migration marker is absent. Use explicit dependsOn/stage dependencies.
3. Deploy to a training target. For App Service, deploy to a staging slot and send a smoke request before swap; for a container, use a separate revision and send the same request before directing traffic. Record status, response time, and version.
4. Add a bounded retry only around a deliberately simulated transient operation such as a temporary HTTP 503. Make retries log attempt number and stop after a fixed limit. Let deterministic validation failures fail immediately.
5. Create a hotfix branch from the released tag. Require the same test and environment approval, deploy the already-built hotfix artifact, then merge the hotfix back to the normal branch and write the release note.

Verify

Capture the dependency graph, migration marker, immutable artifact identity, smoke-test result before and after traffic change, retry log, environment approval, and hotfix merge-back. State the rollback criterion: for example, failed smoke test or an error-rate threshold during the training observation window.

Break and fix

1. Reverse the migration/application order. The application must fail its compatibility check; restore the additive-first order.
2. Make the smoke endpoint return 500. Keep traffic on the existing slot/revision or disable the feature flag; diagnose from the release log and restore the healthy artifact.
3. Turn a deterministic schema-validation error into a retry. Show the wasted attempts, then restrict retry to classified transient failures.

Clean up

Delete the training slot or revision, database, resource group, images/binaries, environments, and temporary hotfix branch after merge-back. Retain only scrubbed run evidence.

Scenario practice

• Configure: When should a slot swap, a new container revision, a feature flag, or a database rollback be the release control?
• Diagnose: A deployment retries three times and still fails before traffic changes. Which evidence classifies it as a deterministic validation failure instead of a transient platform error?
• Distinguish: Why is a hotfix branch a source-control path, while a rollback is a runtime recovery decision?

Sources and re-audit

• Azure Pipelines jobs and conditions, checked 2026-08-22.
• Deploy to App Service slots, Azure Container Apps revisions, and retry guidance, checked 2026-08-22.

Re-audit when deployment-slot/revision behavior, pipeline condition semantics, or retry guidance changes.

Related

deployment-environment · rollback-strategy · feature-flags · workload · All labs