Keep the old release useful
The reference uses one Application Load Balancer, two target groups, and two EC2 instances. A candidate is installed in the inactive slot while the prior successful version continues serving normal traffic. The documentation distinguishes the previous deployed release from simply taking a Git parent: a deployment can contain multiple commits.
Management stays pinned to a stable controller even when application traffic changes color. That separation keeps the mechanism that performs a handover independent from the application revision being handed over.
Observe before switching
The documented flow checks an immutable source revision, runs tests and coverage, verifies health, and routes an administrator cohort to the candidate. HTTPS and WebSocket evidence from distinct sources precede the default traffic switch. Failed checks restore the retained route.
Existing WebSockets remain attached to their original target until reconnecting, which is an important boundary for interpreting a traffic change. The routing visualizer is intended to show actual rules and receipts rather than a purely decorative deployment animation.
Keep the operational history clear
This repository records the earlier integrated implementation. The current V39 platform separates provisioning, controller, and applications, and uses a direct deployment broker. Keeping the reference alongside its successor shows how the release model evolved while preserving the central constraint: a candidate must earn traffic through evidence before it replaces the retained release.