Blue-Green Deployments — CI/CD with GitHub Actions

Blue-green deployment is a release strategy that eliminates downtime and provides instant rollback by maintaining two identical production environments — 'blue' (current live) and 'green' (new version) — and switching traffic between them atomically. The new version is deployed and validated in the green environment while the blue environment continues serving 100% of production traffic. Once green is validated, the load balancer or traffic router switches all traffic from blue to green in a single operation — the cutover takes milliseconds. If the new version has issues, traffic is switched back to blue instantly, also in milliseconds, without any pod restarts or redeployments. This contrasts with rolling deployments (previous lesson) where rollback requires deploying the old version again. Blue-green is the gold standard for zero-downtime deployments where instant rollback is a hard requirement.

Analogy🏏Cricket

🏏 Think of it like cricket: A cricket series is structured in three tiers: the series schedule (which matches are played and when), individual match plans (batting order, bowling rotations, fielding strategy), and specific delivery plans (which balls to bowl to which batsman in which over). The series schedule is the workflow — it defines the overall event. Each match is a job — it runs independently but contributes to the series outcome. Each delivery plan is a step — a specific action with a discrete result. Just as a Test captain doesn't redesign the series schedule for every match but does adjust the bowling plan for each innings, GitHub Actions separates what triggers the automation (workflow) from how independent tasks are parallelised (jobs) from the individual commands executed (steps). The insight is that this separation of concerns is what allows large, complex pipelines to remain manageable — just as a well-structured series plan keeps a touring team organised across multiple venues and formats.