Blue-Green Deployment in OpenShift

Learn how Blue-Green Deployment works in OpenShift, implement zero-downtime Spring Boot deployments, perform instant rollback, and understand real-world enterprise deployment strategies.

Introduction

Imagine you're deploying a new version of an online banking application that processes millions of transactions every day.

A traditional deployment or even a rolling deployment introduces change gradually. But what if the new release contains a critical bug after all Pods have been updated?

This is where Blue-Green Deployment becomes valuable.

Blue-Green Deployment maintains two identical production environments:

Blue – Current production environment
Green – New application version

Traffic is switched from Blue to Green only after the new version has been fully tested, enabling near zero-downtime deployments and instant rollback.

Learning Objectives

By the end of this article, you will understand:

What is Blue-Green Deployment?
Blue-Green architecture
Traffic switching
Spring Boot implementation
Service selector updates
Rollback strategy
Enterprise use cases
Blue-Green vs Rolling Deployment
Best practices

What is Blue-Green Deployment?

Blue-Green Deployment is a release strategy where two identical production environments run simultaneously.

Blue serves live users.
Green hosts the new application version.

After validation, the Service or Route switches traffic from Blue to Green.

Blue-Green Architecture

flowchart TD

Users --> Route

Route --> Service

Service --> Blue["Blue Deployment (v1)"]

Green["Green Deployment (v2)"]

Blue --> DB[(Database)]

Green --> DB

Initially, all traffic goes to the Blue environment.

Why Blue-Green Deployment?

Traditional deployment problems:

Downtime
Risky production updates
Difficult rollback
Interrupted user sessions

Blue-Green Deployment solves these challenges.

Benefits:

Zero downtime
Instant rollback
Production validation
Safer releases

Blue-Green Deployment Lifecycle

flowchart LR

Version1

--> DeployGreen

DeployGreen

--> TestGreen

TestGreen

--> SwitchTraffic

SwitchTraffic

--> RemoveBlue

Deployment Workflow

sequenceDiagram

participant Developer

participant OpenShift

participant Green

participant Service

participant Users

Developer->>Green: Deploy Version 2

Green-->>Developer: Health Check Passed

Developer->>Service: Switch Selector

Service->>Users: Route Traffic to Green

Users->>Green: Production Requests

Traditional Rolling Deployment

flowchart LR

Pod1V1

--> Pod1V2

Pod2V1

--> Pod2V2

Pod3V1

--> Pod3V2

Pods are replaced gradually.

Blue-Green Deployment

flowchart LR

BlueEnvironment

GreenEnvironment

Users

--> BlueEnvironment

GreenEnvironment -. Ready but Idle .- Users

Both environments run simultaneously.

Spring Boot Deployment Architecture

flowchart LR
    GIT["Git Repository"]
    CI["CI Pipeline"]
    IMAGE["Container Image"]

    BLUE["Blue Deployment"]
    GREEN["Green Deployment"]

    SVC["Service"]
    ROUTE["Route"]
    BROWSER["Browser"]

    GIT --> CI
    CI --> IMAGE

    IMAGE --> BLUE
    IMAGE --> GREEN

    BLUE --> SVC
    GREEN --> SVC

    SVC --> ROUTE
    ROUTE --> BROWSER

Blue Deployment

Deployment YAML

apiVersion: apps/v1
kind: Deployment

metadata:
  name: payment-blue

spec:

  replicas: 3

  selector:
    matchLabels:
      app: payment
      version: blue

  template:

    metadata:

      labels:
        app: payment
        version: blue

Green Deployment

apiVersion: apps/v1
kind: Deployment

metadata:
  name: payment-green

spec:

  replicas: 3

  selector:
    matchLabels:
      app: payment
      version: green

  template:

    metadata:

      labels:
        app: payment
        version: green

Service Configuration

Initially, the Service routes traffic to Blue.

apiVersion: v1

kind: Service

metadata:
  name: payment-service

spec:

  selector:
    app: payment
    version: blue

Traffic Switch

After Green is verified:

selector:

  app: payment

  version: green

Only the selector changes.

OpenShift automatically redirects all requests.

Traffic Flow

Before deployment:

flowchart LR

Users

--> Service

Service

--> BluePods

After deployment:

flowchart LR

Users

--> Service

Service

--> GreenPods

Validation Before Traffic Switch

Green environment should pass:

Application startup
Health checks
Database connectivity
API testing
Performance testing

Only then should traffic be switched.

Health Checks

readinessProbe:

  httpGet:

    path: /actuator/health

    port: 8080

Only healthy Green Pods receive traffic.

Instant Rollback

Suppose Version 2 contains a critical issue.

Simply point the Service back to Blue.

flowchart LR

GreenIssue

--> Service

Service

--> BluePods

Rollback takes only seconds.

Banking Example

Payment Service upgrade.

flowchart TD

Customers

--> Route

Route

--> PaymentService

PaymentService

--> BluePods

PaymentService

--> GreenPods

BluePods --> Database

GreenPods --> Database

Initially:

Traffic → Blue

After testing:

Traffic → Green

CI/CD Pipeline

flowchart LR
    DEV["Developer"]
    GIT["Git"]
    JENKINS["Jenkins"]
    BUILD["Build Image"]
    GREEN["Green Deployment"]
    TESTS["Smoke Tests"]
    SWITCH["Switch Service"]
    PROD["Production"]

    DEV --> GIT
    GIT --> JENKINS
    JENKINS --> BUILD
    BUILD --> GREEN
    GREEN --> TESTS
    TESTS --> SWITCH
    SWITCH --> PROD

Blue-Green vs Rolling Deployment

Feature	Rolling	Blue-Green
Zero Downtime	✅	✅
Two Environments	❌	✅
Instant Rollback	Limited	✅
Infrastructure Cost	Lower	Higher
Production Validation	Partial	Full
Deployment Speed	Gradual	Instant Switch

Advantages

Zero downtime
Easy rollback
Production validation
Reduced deployment risk
Improved customer experience
Minimal service interruption

Challenges

Requires double infrastructure
Database schema compatibility
Higher resource consumption
More complex release process

Best Practices

Use immutable image tags.
Validate Green thoroughly before switching.
Automate health checks.
Keep database changes backward compatible.
Automate Service selector updates.
Monitor application metrics after traffic switch.
Remove Blue only after production stability is confirmed.

Common Mistakes

❌ Deleting Blue before validating Green.

❌ Performing incompatible database migrations.

❌ Skipping smoke tests.

❌ Switching traffic before readiness probes pass.

❌ Using mutable image tags such as latest.

Enterprise Use Cases

Blue-Green Deployment is commonly used for:

Banking payment platforms
Healthcare applications
Airline reservation systems
Insurance policy management
Financial trading platforms
SaaS applications
E-commerce checkout services

These applications require minimal downtime and fast recovery.

Summary

Blue-Green Deployment is one of the safest deployment strategies available for production systems.

Key takeaways:

Two production environments (Blue and Green) run simultaneously.
Users continue using Blue while Green is validated.
Traffic is switched by updating the Service selector.
Rollback is nearly instantaneous because Blue remains available.
This strategy is ideal for mission-critical Spring Boot applications running on OpenShift.

Interview Questions

What is Blue-Green Deployment?
How does Blue-Green differ from Rolling Deployment?
How is traffic switched between Blue and Green?
Why is rollback faster with Blue-Green Deployment?
What are the disadvantages of Blue-Green Deployment?
Why are readiness probes important?
How does OpenShift support Blue-Green deployments?
What role does the Service play in Blue-Green Deployment?
When should you choose Blue-Green over Rolling Deployment?
Which enterprise applications benefit most from Blue-Green Deployment?