Gate promotion at controlled traffic ingress

Learning objective

Implement staged promotion and canary/blue-green traffic controls only at a routing boundary you control (for example, Container Apps revisions), with measured quality and approval gates.

Core idea

Promotion is a decision to expose an approved release set to more work. Implement that decision where you can select the receiving revision, verify the resulting allocation, and stop progression. A weighted rollout requires a router that actually supports weighted targets; a versioned agent definition alone does not provide one.

Container Apps ingress can split traffic between active revisions. Foundry hosted-agent endpoints serve one version at a time and do not support traffic splitting between versions. When a Container Apps application invokes Foundry agents, each revision must resolve the intended downstream release set. Splitting two frontend revisions that both invoke the same changing backend does not create a meaningful agent canary.

How it works

Establish the controlled routing target

Use Container Apps multiple revision mode for explicit coexistence and traffic allocation. The setting is configuration.activeRevisionsMode: multiple; the CLI mechanism is az containerapp revision set-mode with the mode multiple. Ingress allocation is expressed in configuration.ingress.traffic, with revisionName and weight identifying the target and percentage.

az containerapp ingress traffic set applies allocations by revision through --revision-weight, or by label through --label-weight. All configured weights must total 100%.

Microsoft’s documented blue/green pattern assigns blue and green labels using az containerapp revision label add --label, then switches traffic with --label-weight blue=0 green=100; rollback reverses those weights to blue=100 green=0. Set template.revisionSuffix to a release-specific value, such as a build number or Git commit short hash, for deterministic revision names. Record those revision names as release evidence because a label can move between revisions while keeping the same URL.

A label URL routes directly to its associated revision independently of the main application traffic allocation. That makes it useful for candidate testing before production exposure. The revisions documentation separately identifies Deployment labels mode as preview. The design here uses multiple revision mode with revision or label weights; it does not require the preview Deployment labels mode.

Promote the same approved candidate

Separate candidate deployment from increased exposure. Create the candidate revision, validate its resolved dependencies, and run acceptance work before giving it production traffic. Preserve the compatible set described in 4.3.2. A pipeline that rebuilds different artifacts after acceptance must establish that the deployed output still matches the approved evidence.

Define separate promotion decisions: admission to acceptance, limited production exposure, broader exposure, and full adoption. Each decision records the candidate, baseline, evidence, approver, and target allocation. Your percentage schedule and observation period are application policy, not automatic guarantees supplied by Container Apps.

For blue/green, validate the candidate while the established revision owns production, then change allocation to 100% candidate. For canary, use a limited share and increase it only after the observation gate passes. For example, 95/5 followed by 80/20 and then 0/100 is a possible team policy, not a documented universal recommendation. If evidence is insufficient, hold the weight rather than interpreting the absence of an alert as success.

A blue/green release moves to 100% candidate after acceptance, while a canary widens its share only when the observation gate passes.

Convert quality results into a release decision

Foundry cloud evaluation exposes completed-run evidence through openai_client.evals.runs.retrieve() and openai_client.evals.runs.output_items.list(). Run status distinguishes completed, failed, and canceled. A failed or canceled evaluation is missing acceptance evidence, not a quality pass. The results page documents individual score, threshold, and passed fields and aggregate per_testing_criteria_results containing pass_rate.

Use those identifiers to build a machine-readable gate tied to the candidate and dataset. See 3.1.2 for evaluation configuration and 3.2.7 for judge calibration. The evaluator’s threshold converts an individual result into a pass decision; your release policy separately decides what aggregate result, critical-case coverage, and baseline comparison justify promotion. An acceptable average can conceal an unacceptable failure in a high-impact tool case.

Record both operational and behavioral evidence. Startup and readiness prove service availability at that point; they do not prove correct specialist selection or safe tool outcomes. During production exposure, associate observations with the receiving release set and examine the same quality dimensions used in acceptance. See 3.3.1 and 3.3.3 for workflow health and continuous evaluation.

Enforce authority outside the rollout script

In Azure DevOps Services, resource administrators configure Approvals and checks on environments and other protected resources outside pipeline YAML. The consuming stage waits for its resource checks. This separates the person editing deployment logic from the owner deciding whether the production resource may be used.

Use Invoke REST API to consult your evidence service for the candidate’s gate decision. That service should validate the release identifier, evaluation completion, required cases, and policy version before returning approval. This mapping is application logic; the Azure Pipelines check supplies the stage-entry enforcement mechanism.

Use Query Azure Monitor Alerts for operational observation. It succeeds when no alert rules are activated at evaluation, so it cannot substitute for a quality dataset or prove that monitoring covered the candidate. Add a human Approvals check where business acceptance or risky tool authority requires review. Configure whether approvers can approve their own runs and choose a timeout.

Represent exposure increases as protected stages when each increase needs a check. A check before one long deployment stage does not automatically reapprove every traffic change inside that stage. Apply an Exclusive lock where competing pipeline runs could overwrite allocation. Its lockBehavior options are runLatest and sequential; select the behavior according to whether superseded promotions should be discarded or processed in order.

Key distinctions and trade-offs

Traffic gate versus quality gate: Ingress determines which revision receives work. Evaluation determines whether increased exposure is justified. Connecting them requires release-aware pipeline logic.

Direct candidate testing versus production weighting: A label URL selects one revision. The application URL follows traffic weights. Results from a direct test do not measure the production traffic mix.

Operational alerts versus behavioral acceptance: An inactive alert is evidence about configured alert rules. It is not proof that an agent fulfilled its task or respected tool constraints.

Stage approval versus every change: Azure Pipelines checks protect stage entry. Choose stage boundaries that match your promotion decisions and prevent an approved stage from silently expanding exposure beyond its reviewed scope.

Architecture / decision scenario

A support workflow routes through two Container Apps revisions. Each revision selects a distinct saved Foundry agent set and compatible read-only tools. The team validates the candidate through direct revision access and records its completed evaluation run, individual critical-case results, and aggregate pass rates against the baseline.

The limited-exposure stage requires an Invoke REST API evidence check and a production-environment approval. It allocates 95% to the established revision and 5% to the candidate. These are scenario policy values. A subsequent observation stage examines candidate-attributed workflow outcomes and configured Azure Monitor alerts.

The candidate answers well but chooses the wrong specialist for one critical category. The evidence service rejects broader exposure, even though no infrastructure alert is active. The team holds or removes candidate traffic and investigates. After correction and fresh evidence, a protected stage can approve a complete blue/green cutover. Container Apps owns every weight change; the Foundry backend does not acquire weighted routing merely because the gateway supports it.

Common exam traps

• Treating Foundry hosted-agent versioning as weighted routing.
• Splitting frontend traffic while both revisions resolve the same backend set.
• Setting revision weights whose total differs from 100%.
• Treating an evaluation job’s submission as a completed quality result.
• Replacing behavioral acceptance with absence of Azure Monitor alerts.
• Assuming one stage approval governs all later traffic changes automatically.

What to remember

Name the router, immutable receiving revision, measured evidence, and approving authority. Promote through explicit decisions whose stages enforce checks. Quality gates must resolve to the same release set selected by traffic allocation, and a failed or incomplete gate must prevent further exposure.

Knowledge check

References

• Microsoft, Update and deploy changes in Azure Container Apps
• Microsoft, Manage revisions in Azure Container Apps
• Microsoft, Traffic splitting in Azure Container Apps
• Microsoft, Hosted agents in Foundry Agent Service
• Microsoft, Get cloud evaluation results with the Microsoft Foundry SDK
• Microsoft, Pipeline deployment approvals
• Microsoft, Blue-Green Deployment in Azure Container Apps