Context
A Container Apps revision is an immutable snapshot of revision-scoped application settings. Deploying a revision does not automatically prove that ordinary users reach it. Multiple-revision mode allows weighted routing, while labels provide direct access to selected revisions for controlled testing.
Prerequisites are the app's revision mode, ingress configuration, current traffic rules and a safe version-identification response or log field. Obtain read access to revision state and application logs. Define promotion and rollback criteria before changing user traffic.
1. Read the deployed revision state
List the active and inactive revisions and record their image references. A deployment pipeline can finish while the candidate remains unable to start or pass readiness. Check provisioning, running and health information as separate signals.
Compare the effective traffic configuration with the release plan. Identify whether a rule references a named revision or the latest revision. A later deployment can change what a latest pointer means. Preserve the previous weights and revision identifiers so rollback refers to a known configuration.
2. Test the candidate directly
Use a label URL or other documented direct revision access path to exercise the candidate before allocating ordinary traffic. Confirm the served version through an approved build identifier, not an assumption based on the URL alone. Exercise authentication, dependencies and a representative business request.
Remember that some settings are application-scoped and affect all revisions, while image and template changes create revisions. Secrets and shared ingress configuration need their own change review. A candidate that works in isolation can still be incompatible with an older active revision sharing a database or configuration contract.
3. Observe weighted traffic correctly
After an approved weight change, correlate application request logs with revision identity. A handful of browser refreshes is not a reliable statistical check of the configured split. Client caching, repeated connections and the small sample can distort what an operator sees.
Do not assume sticky sessions solve cross-revision state. Microsoft's cookie-based session affinity feature applies to HTTP ingress in single-revision mode. Applications using weighted revisions should deliberately handle shared session state and release compatibility. Keep rollback straightforward by preserving the stable revision's health and required capacity during the evaluation window.
Diagnostic checkpoints
| Observation | Likely boundary | Next evidence |
|---|---|---|
| Candidate exists, receives no traffic | Weight or activation | Effective ingress rules |
| Label works, app URL shows old build | Different routing path | Per-revision request logs |
| Candidate fails readiness | Startup or dependency | Revision logs and probes |
| Sessions break during split | Shared state contract | Session storage and compatibility |
Illustrative scenario
A hypothetical team deploys a new catalog revision and validates its label URL. The ordinary hostname still routes entirely to the stable revision because weights were never changed. Version-tagged logs explain the result without another deployment. This example illustrates a release configuration boundary and does not report a real promotion outcome.
Verification and release SOP
Accept promotion only when the candidate meets the defined error, latency and business checks under its allocated traffic. Verify that rollback returns ordinary routing to the intended stable revision. Include background effects and schema compatibility in the decision.
Maintain the revision naming scheme, label ownership, routing snapshot and promotion thresholds in the SOP. Monitor errors and resource demand by revision. Review inactive revision cleanup separately from deployment so a recent rollback target is not removed before the evaluation period ends. Retest routing after changes to ingress mode or revision strategy.
Explore Clouvenix containers kubernetes for implementation and operational handover.