Platform engineering must release a new orchestrator version that changes tool-routing logic. They want limited blast radius, fast rollback, and production traffic validation—not a big-bang cutover. Which release methodology best fits?
Select an answer to reveal the explanation.
Short Explanation
Correct answer: A. Canary releases limit blast radius: small traffic share, health and quality gates, gradual expand, automated rollback on error or eval degradation. Big-bang Friday dual-region cutovers (B) maximize risk. Laptop-as-prod (C) is not a release strategy. Hot-editing production files (D) destroys auditability. For multi-agent systems, include quality evals—not only HTTP errors—in the canary gates.
Full Explanation
Release methodologies for multi-agent solutions include DTAP, blue/green, and canary. The goals of limited blast radius, production validation, and fast rollback align with canary. Option A implements percentage rollout with automated rollback on operational or evaluation failure. Option B is high-risk simultaneous cutover. Options C and D are uncontrolled and non-compliant with release management. Pair canary with infrastructure-as-code, versioned agent packages, and clear rollback to the prior orchestrator image and prompt set.