Blue-Green and Canary Deployments

Prerequisites: completed Build a Multi-Stage Deployment Pipeline, a Kubernetes cluster to deploy against (a local kind/minikube cluster is sufficient), kubectl configured.

Sourcing & version notes: Kubernetes core primitives used for blue-green are stable, unchanged APIs. Canary traffic-splitting uses Argo Rollouts, which is not part of core Kubernetes — it requires the Argo Rollouts controller plus an ingress/mesh integration (NGINX Ingress, Istio, or a cloud load balancer) for weighted splitting to actually work. Verify the current Argo Rollouts traffic-management docs for your specific ingress before relying on this in a real cluster.

A naive deploy replaces old instances with new ones in place — if the new version has a bug, every user hits it simultaneously, and rolling back means another full deploy cycle. Blue-green and canary are two different answers to the same problem: reduce blast radius and give yourself a fast, cheap way to back out. Blue-green keeps two full environments and switches traffic between them atomically; canary shifts a small percentage of traffic to the new version first and watches it before going further. This project implements both against a Kubernetes target so you can see the mechanics, not just the diagrams.