Azure Container Apps revisions: validate a release before moving traffic

Understand which changes create a revision

A Container Apps revision captures a version of the application's revision-scoped configuration. Once created, that revision is immutable. Changes to revision-scoped properties create a new revision, while application-scoped settings can affect the application more broadly. Review the documented scope of a configuration change before assuming it applies only to the candidate release.

An image digest makes release identity clearer than a mutable image tag. Record the image, revision name and application configuration used for the deployment. These three pieces explain what is running and help separate an image change from a secret, networking or scaling change when request behavior differs after deployment.

Choose a revision mode for the release strategy

In single revision mode, the platform manages the transition from the old revision to the new ready revision. Multiple revision mode lets more than one revision remain active and enables an explicit traffic distribution. Use multiple revisions when the operational plan actually needs a canary or parallel release, and account for the capacity consumed by those active revisions.

Traffic splitting operates on the configured revision targets and weights. A small percentage of traffic can limit exposure during a trial, but it does not make an incompatible data change safe. Both versions may access the same databases, queues and external systems. Design the candidate and current release to coexist before routing requests between them.

Build a measured rollout

1. Deploy the candidate image and record its immutable artifact identity.
2. Check provisioning, startup and readiness results for the new revision.
3. Test representative requests against the candidate using the supported revision access path.
4. Apply a deliberate traffic distribution and observe errors and latency by revision.
5. Move traffic further only when the measured result meets the release requirement.

Readiness is a prerequisite for useful traffic tests. A revision can exist in the deployment history while its containers fail to start because of an invalid image, missing configuration or unavailable dependency. Inspect provisioning status and container diagnostics before changing weights in response to a request failure.

Include background work in the revision plan

HTTP traffic weights do not decide which active revision processes every type of background task. If two active versions run scheduled work or consume the same queue, the workload can differ from the visible request split. Document the scale rules and worker behavior, and use idempotent processing where jobs may be redelivered or processed across versions.

Application-scoped changes need special care during a canary. A shared secret update can affect more than the newly deployed image, and a rollback of traffic does not automatically restore previous dependency state. Keep release metadata and configuration history so the recovery plan can distinguish traffic movement from reversing a shared change.

Verify the final active state

After the rollout, inspect the active revisions and weights and confirm that real requests reach the intended version. Review unused revisions and the chosen retention policy. A complete deployment record includes the candidate checks, observed error rate, final traffic state and a tested recovery path. That evidence is more useful than a deployment command that merely returned success.

References

• Update and deploy changes in Azure Container Apps — Microsoft Learn
• Traffic splitting in Azure Container Apps — Microsoft Learn