• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Practice : Blue-Green Deployments

Purpose and Strategic Importance

Blue-Green Deployments are a technique to reduce downtime and risk when releasing software. By maintaining two environments (blue and green), teams can switch user traffic from the old version to the new one only after validating the new environment is healthy.

This practice allows for instant rollback, seamless releases, and zero-downtime deployments. It supports safer, faster production changes, and aligns closely with modern DevOps practices for resilient service management and operational control.


Description of the Practice

  • Two identical production environments exist: "blue" (current live) and "green" (new release).
  • The new version is deployed to the green environment and tested before switching traffic.
  • Once validated, traffic is routed from blue to green with a single change (DNS, load balancer, etc.).
  • The blue environment is retained temporarily to allow rollback if needed.
  • This switch is ideally automated as part of the delivery pipeline.

How to Practise It (Playbook)

1. Getting Started

  • Provision two production-equivalent environments in your infrastructure.
  • Configure your router, load balancer, or DNS to support traffic switching.
  • Build deployment automation that can target either environment.
  • Deploy the new version to the green environment without impacting users.

2. Scaling and Maturing

  • Integrate smoke tests and health checks into the green environment post-deploy.
  • Automate validation steps before switching traffic to green.
  • Create rollback automation that instantly routes traffic back to blue if needed.
  • Use metrics and alerts to detect regressions during or after the switch.
  • Log and audit every traffic switch for traceability and learning.

3. Team Behaviours to Encourage

  • Plan deployments as collaborative, observable events - not isolated tech changes.
  • Use playbooks or checklists to align operations, developers, and stakeholders.
  • Prioritise rollback readiness - practice switching back in rehearsals.
  • Encourage shared ownership of environment health and release safety.

4. Watch Out For…

  • Configuration drift between blue and green environments - keep them truly identical.
  • Overhead in maintaining two full environments - balance cost with risk profile.
  • Manual steps that delay or complicate the switch.
  • Blind confidence - always monitor for real user impact after switching.

5. Signals of Success

  • Deployments can be switched with zero downtime and no user disruption.
  • Rollbacks are instant, with minimal manual intervention.
  • All production changes are tested in real infrastructure before being exposed to users.
  • Confidence and control over releases increase across teams.
  • Delivery becomes safer and faster without operational surprises.
Associated Standards
  • Changes are introduced with minimal failures and maximum resilience (CFR)
  • Services are restored quickly and safely following failure (MTTR)
  • Systems recover quickly and fail safely
Associated Measures
  • Change Failure Rate (CFR)
  • Deployment Frequency

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering