Blue-Green Deployment Template for PMs

Blue-green switches 100% of traffic at once between two full environments. Canary routes a small percentage (1-10%) of traffic to the new version while the rest continues hitting the old version. Blue-green gives you a faster, simpler rollback (one switch) but no gradual risk reduction. Canary gives you gradual exposure but requires traffic splitting infrastructure and more complex monitoring. Many teams use both: blue-green for low-risk releases and canary for high-risk changes. See the [canary release template](/templates/canary-release-template) for the canary approach.

Use the expand-and-contract pattern. First, deploy a release that adds new columns or tables without removing old ones (expand). Both environments can read and write using the old schema. After the cutover is stable, deploy a follow-up release that removes the old columns (contract). This requires two deployments but preserves the rollback path for the risky cutover step.

Exactly double your infrastructure cost during the deployment window. Most teams keep the idle environment scaled down to zero or minimum capacity between deployments and scale it up only when preparing for a release. With cloud auto-scaling, you can provision the green environment 30 minutes before deployment and decommission it a few days after. The incremental cost is small relative to the risk reduction.

Yes. Kubernetes makes blue-green simpler through label selectors. Deploy the new version with a different label (e.g., `version: green`), run health checks, then update the Service selector to point at the new pods. Tools like Argo Rollouts and Flagger automate this process. The green Deployment runs alongside the blue Deployment, and the Service acts as the traffic router.

WebSocket connections are long-lived and will break when you switch traffic. Options: (1) Set a grace period where both environments accept connections and let existing WebSockets drain naturally. (2) Implement client-side reconnection logic that transparently reconnects to the new environment. (3) Use a sticky session layer that routes existing WebSocket connections to their original environment until they close. Option 2 is the most reliable because it handles all cutover scenarios, not just planned deployments. ---