Match release methods to operational risk

Learning objective

Choose DTAP, blue/green, and canary release methods based on operational risk.

Core idea

Choose a release method by the failure you need to contain. Development, test, acceptance, and production (DTAP) separates validation environments. Blue/green keeps two compatible production candidates available for a controlled switch. Canary exposes a limited share of production traffic to a candidate before broader adoption. These methods answer different questions and can be combined.

For a multi-agent system, operational risk includes incorrect decisions, repeated tool effects, broken specialist contracts, and changes in the model behind a deployment name. A healthy container can still deliver unacceptable answers. Choose the method together with a behavioral gate and a recoverable release set, rather than using successful startup as the definition of safety.

How it works

Use DTAP to reduce uncertainty before exposure

Treat DTAP as a release process you design, rather than a Foundry setting. Development supports experimentation; test checks repeatable contracts and regressions; acceptance confirms the business workflow and permissions; production handles approved live work. Define what evidence each stage adds. Four environment names without separate configuration, credentials, and decision criteria provide little protection.

Foundry agent versions are immutable after saving. Changes require a separate saved version, and code can identify an agent as <agent_name>:<version>. Use that identifier to connect acceptance results to the candidate you intend to release. A test of an unsaved playground draft is weaker evidence than a test of the saved production candidate.

Azure Pipelines implements stage-entry control through environment Approvals and checks. Resource administrators configure these checks outside pipeline YAML. A manual approval on the production environment gives its owner a decision point before the consuming stage starts. The environment is a pipeline protection mechanism; it does not itself create separate Azure resources. See 4.3.2 for environment and dependency isolation.

DTAP is valuable when an incorrect tool action has consequences that cannot be undone by switching traffic. It lets you test with nonproduction accounts and controlled fixtures before live admission. Its limitation is realism: an acceptance dataset cannot prove every production behavior, traffic shape, or interaction among specialists. Treat passing acceptance as authorization for a bounded rollout, rather than proof that every live outcome is safe.

Use blue/green for a controlled cutover

Azure Container Apps revisions provide immutable snapshots of a container app. In multiple revision mode, you control active revisions and their traffic weights. The blue/green pattern keeps the approved revision serving production while you validate a candidate revision through a direct endpoint. After validation, you switch the application traffic to the candidate and retain the preceding revision for recovery.

Container Apps multiple revision mode allocates weighted traffic between revisions; see 4.3.3 for the settings, commands, and approval gates.

Choose blue/green when you need a clear switch point and rapid routing recovery, and can support parallel candidates. Both candidates must work with shared dependencies during the overlap. A tool schema migration that breaks blue invalidates the apparent rollback path even if its container remains healthy. Parallel deployment also creates an operational cost: you maintain and validate two usable sets until the recovery window closes. Prefer a complete cutover when splitting requests would introduce mixed-contract behavior that you cannot safely reconcile. Prefer canary when both sets can coexist and the live observation changes your confidence in the candidate.

Use canary to measure bounded live exposure

Canary allocates part of production traffic to the candidate while the established revision continues serving the remainder. Container Apps implements this through revision traffic weights; see 4.3.3 for the controls. An illustrative 95/5 split exposes the candidate to 5% of incoming traffic; those percentages are your policy, not Microsoft’s recommended universal rollout schedule.

Choose canary when live workload diversity matters and you can observe meaningful outcomes before increasing exposure. Compare candidate and baseline on the same dimensions: end-to-end task completion, tool failures, safety violations, latency, and cost. See 3.3.3 for continuous quality measurement. A percentage of requests is not a guarantee about the proportion of tenants, conversations, or high-impact actions exposed.

For stateful conversations, define which release owns an admitted session. Treat that as an application requirement: request-level traffic weighting alone does not prove conversation-level consistency. If a specialist or tool performs irreversible actions, a small percentage still permits harm. Require approval or restrict candidate capabilities before admitting those actions; canary is an exposure control, not a side-effect safety mechanism.

Key distinctions and trade-offs

The three methods control different risks:

Foundry hosted-agent endpoints serve one version at a time and route 100% of traffic to it. They do not support traffic splitting between versions. Hosting an agent in Foundry therefore does not itself implement a weighted canary. Put the split at a routing layer you control, such as Container Apps revisions whose application configuration selects distinct downstream release sets.

Container Apps single revision mode automatically moves traffic after the candidate satisfies its readiness requirements, and keeps traffic on the preceding revision if the update fails. That is useful platform deployment behavior, but readiness is not a measured agent-quality gate. Multiple revision mode provides the explicit control needed for the patterns taught here.

Architecture / decision scenario

An insurance workflow uses a coordinator, a policy specialist, and a payment tool. A release changes routing instructions and the payment tool’s response schema. The team chooses DTAP first: test uses synthetic accounts, acceptance verifies the saved agent versions and the tool contract, and production requires an environment approval in Azure Pipelines.

For the schema change, the team chooses blue/green because it needs a clear cutover between complete compatible sets. Each Container Apps revision selects its own coordinator, specialists, and tool adapter. The preceding set remains usable during the recovery window. Switching only the coordinator while changing the shared tool incompatibly would defeat that choice.

For a later change to read-only policy explanations, the team adds a canary after acceptance. A small configured traffic weight supplies live quality evidence without permitting candidate payment actions. If quality regresses, it returns the candidate’s weight to zero. The Foundry endpoint behind each revision still serves one version; Container Apps owns the split.

Common exam traps

• Treating DTAP, blue/green, and canary as mutually exclusive options.
• Assuming four named stages imply isolated Azure resources and credentials.
• Equating readiness checks with agent-quality acceptance.
• Calling a weighted rollout a Foundry hosted-agent feature.
• Assuming a small traffic share prevents irreversible tool effects.
• Retaining a container while breaking the dependencies it needs for recovery.

What to remember

Use DTAP for progressive validation, blue/green for a controlled switch between compatible sets, and canary for limited production evidence. Identify the owner of traffic allocation before choosing a rollout method. The release method reduces a particular operational risk; measured outcomes and dependency compatibility determine whether promotion is justified.

Knowledge check

References

• Microsoft, Agent development lifecycle in Microsoft Foundry
• Microsoft, Pipeline deployment approvals
• Microsoft, Update and deploy changes in Azure Container Apps
• Microsoft, Traffic splitting in Azure Container Apps
• Microsoft, Hosted agents in Foundry Agent Service
• Microsoft, Blue-Green Deployment in Azure Container Apps