Blue-green deployment pattern in Jenkins - Deep Dive

Overview - Blue-green deployment pattern

What is it?

Blue-green deployment is a way to update software with almost no downtime. It uses two identical environments called blue and green. One environment runs the current version, while the other is prepared with the new version. When ready, traffic switches from the old to the new environment instantly.

Why it matters

Without blue-green deployment, updating software can cause downtime or errors for users. This pattern helps avoid interruptions and makes updates safer and smoother. It improves user experience and reduces risks during releases.

Where it fits

Before learning blue-green deployment, you should understand basic software deployment and continuous integration concepts. After this, you can explore other deployment strategies like canary releases or rolling updates.

Mental Model

Core Idea

Blue-green deployment switches user traffic between two identical environments to update software without downtime.

Think of it like...

Imagine a restaurant with two identical kitchens. One kitchen cooks and serves meals (current version), while the other prepares a new menu (new version). When the new menu is ready, the restaurant switches all orders to the second kitchen instantly, so customers never wait.

┌───────────────┐       ┌───────────────┐
│   Blue Env    │──────▶│  Users/Clients│
│ (Current App) │       └───────────────┘
└───────────────┘
       ▲
       │ Switch traffic
       ▼
┌───────────────┐
│  Green Env    │
│ (New Version) │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding deployment basics

Concept: Learn what deployment means and why it matters for software updates.

Deployment is the process of putting new software versions live for users. Traditionally, this can cause downtime because the old version stops before the new one starts.

Result

You know why updating software can interrupt users.

Understanding deployment basics helps you see why smooth updates are important.

2

Foundation

Introducing environments in deployment

Concept: Learn about using separate environments to prepare software before release.

Environments are copies of the software setup. You can have a production environment running live and a staging environment to test new versions safely.

Result

You understand the role of environments in safe software updates.

Knowing environments lets you separate testing from live use, reducing risks.

3

Intermediate

Concept of blue-green deployment

Concept: Learn how two identical environments can be used to switch software versions instantly.

Blue-green deployment uses two environments: blue (live) and green (new). You deploy the new version to green while blue serves users. When green is ready, you switch traffic to it.

Result

You grasp how blue-green deployment avoids downtime.

Understanding this switch is key to zero-downtime updates.

4

Intermediate

Traffic switching techniques

🤔Before reading on: do you think switching traffic means restarting servers or changing network routes? Commit to your answer.

Concept: Learn how traffic is switched between environments using load balancers or DNS changes.

Traffic can be switched by changing load balancer settings to point to the green environment or by updating DNS records to direct users there.

Result

You know practical ways to switch user traffic safely.

Knowing traffic control methods helps avoid user confusion or errors during deployment.

5

Intermediate

Implementing blue-green in Jenkins pipelines

Concept: Learn how Jenkins automates blue-green deployment steps.

In Jenkins, you create pipeline stages to deploy to green, run tests, and then switch traffic. Jenkins scripts can update load balancers or DNS automatically after tests pass.

Result

You can automate blue-green deployment using Jenkins pipelines.

Automation reduces human error and speeds up safe deployments.

6

Advanced

Handling database changes in blue-green

🤔Before reading on: do you think database changes can be switched instantly like app code? Commit to your answer.

Concept: Learn challenges and strategies for database updates during blue-green deployment.

Databases are harder to switch instantly. Strategies include backward-compatible changes, versioned schemas, or using feature flags to avoid breaking the old environment.

Result

You understand how to manage database updates safely with blue-green.

Knowing database challenges prevents downtime and data loss during deployment.

7

Expert

Advanced rollback and monitoring strategies

🤔Before reading on: do you think rollback in blue-green means redeploying old code or just switching traffic back? Commit to your answer.

Concept: Learn how to quickly rollback and monitor deployments for issues.

Rollback means switching traffic back to blue if green has problems, without redeploying. Monitoring tools watch performance and errors to decide if rollback is needed.

Result

You can implement fast rollback and monitoring in production.

Understanding rollback as traffic switch saves time and reduces risk during failures.

Under the Hood

Blue-green deployment works by maintaining two identical environments. The system routes user requests to one environment at a time. When a new version is ready, it is deployed to the inactive environment. Switching user traffic is done by updating the load balancer or DNS to point to the new environment. This switch is atomic from the user's perspective, causing no downtime. The old environment remains intact for quick rollback if needed.

Why designed this way?

This pattern was designed to solve downtime and risk problems in deployments. Alternatives like in-place updates risk partial failures and downtime. Blue-green isolates new versions completely, allowing safe testing and instant switch. It trades extra resource cost for reliability and user experience.

┌───────────────┐       ┌───────────────┐
│   Blue Env    │──────▶│  Load Balancer│──────▶ Users
│ (Current App) │       └───────────────┘
└───────────────┘               ▲
       │                       │
       │ Switch traffic         │
       ▼                       │
┌───────────────┐              │
│  Green Env    │──────────────┘
│ (New Version) │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: does blue-green deployment eliminate the need for testing new versions? Commit yes or no.

Common Belief: Blue-green deployment means you don't need to test the new version because it runs separately.

Reality: Testing is still essential before switching traffic; blue-green only helps reduce downtime and risk during release.

Why it matters: Skipping tests can cause serious bugs to reach users despite blue-green deployment.

Quick: do you think blue-green deployment always halves infrastructure costs? Commit yes or no.

Common Belief: Blue-green deployment reduces costs because only one environment runs at a time.

Reality: It actually requires double infrastructure during deployment, increasing costs temporarily.

Why it matters: Underestimating costs can cause budget issues in production environments.

Quick: does switching traffic in blue-green deployment cause downtime? Commit yes or no.

Common Belief: Switching traffic causes downtime because connections must be reset.

Reality: If done correctly via load balancers or DNS with low TTL, switching is near-instant and causes no downtime.

Why it matters: Believing in downtime can discourage using blue-green deployment.

Quick: can database schema changes be switched instantly like app code in blue-green? Commit yes or no.

Common Belief: Database changes can be switched instantly just like application code in blue-green deployment.

Reality: Database changes require careful planning and backward compatibility; they cannot be switched instantly without risk.

Why it matters: Ignoring this can cause data corruption or application errors.

Expert Zone

1

Blue-green deployment requires synchronization of stateful components like caches and sessions to avoid user disruption.

2

DNS-based traffic switching can be delayed by caching, so load balancer switching is often preferred for instant cutover.

3

Rollback speed depends on how quickly traffic can be switched back, not on redeploying old code.

When NOT to use

Avoid blue-green deployment when infrastructure cost is a major constraint or when the application tightly couples code and database changes that cannot be made backward compatible. Alternatives like canary deployments or rolling updates may be better in these cases.

Production Patterns

In production, blue-green deployment is often combined with automated testing, monitoring, and alerting. Jenkins pipelines automate deployment to the green environment, run smoke tests, then switch traffic via load balancer APIs. Rollbacks are done by switching traffic back to blue instantly if issues arise.

Connections

Canary deployment

Alternative deployment strategy with gradual traffic shift

Understanding blue-green helps grasp canary deployment as a more gradual, risk-managed approach.

Load balancing

Core technology enabling traffic switching in blue-green

Knowing load balancers clarifies how traffic is controlled and switched without downtime.

Switching circuits in electrical engineering

Similar concept of switching active paths instantly

Recognizing this cross-domain similarity shows how instant switching is a universal solution to avoid interruption.

Common Pitfalls

#1 Switching traffic before verifying the new environment is fully ready.

Wrong approach:

In Jenkins pipeline:
stage('Switch Traffic') {
steps {
script {
// Switch traffic immediately after deployment
sh 'update-load-balancer --target green'
}
}
}

Correct approach:

In Jenkins pipeline:
stage('Test New Version') {
steps {
script {
sh 'run-smoke-tests --env green'
}
}
}
stage('Switch Traffic') {
steps {
script {
sh 'update-load-balancer --target green'
}
}
}

Root cause:

Not waiting for tests to confirm the new version works causes user exposure to broken software.

#2 Updating DNS without lowering TTL, causing slow traffic switch.

Wrong approach:

sh 'nsupdate -y key -v << EOF
update add app.example.com 300 A 10.0.0.2
send
EOF'

Correct approach:

sh 'nsupdate -y key -v << EOF
update add app.example.com 30 A 10.0.0.2
send
EOF'

Root cause:

High DNS TTL causes caches to delay traffic switch, leading to inconsistent user experience.

#3 Deploying database schema changes that break the old environment during switch.

Wrong approach:

ALTER TABLE users DROP COLUMN old_feature_flag;

Correct approach:

ALTER TABLE users ADD COLUMN new_feature_flag BOOLEAN DEFAULT FALSE;
-- Remove old column only after full migration and switch

Root cause:

Not planning backward-compatible database changes causes failures during blue-green switch.

Key Takeaways

Blue-green deployment uses two identical environments to enable zero-downtime software updates by switching user traffic instantly.

It requires careful traffic management through load balancers or DNS to avoid user disruption during the switch.

Database changes need special handling because they cannot be switched instantly like application code.

Automation tools like Jenkins pipelines make blue-green deployment safer and faster by integrating testing and traffic switching.

Understanding the limits and costs of blue-green deployment helps choose the right deployment strategy for your project.

Practice

1. What is the main goal of the blue-green deployment pattern in Jenkins?

easy

A. To deploy only on weekends

B. To run tests faster by using multiple agents

C. To backup data before deployment

D. To avoid downtime by switching between two identical environments

Solution

1. Step 1: Understand blue-green deployment concept

   This pattern uses two identical environments called blue and green to deploy new versions without downtime.

2. Step 2: Identify the main goal in Jenkins context

   Jenkins automates switching traffic between these environments to keep the service available during updates.

3. Final Answer:

   To avoid downtime by switching between two identical environments -> Option D

4. Quick Check:

   Blue-green deployment = avoid downtime [OK]

Hint: Blue-green means two environments for zero downtime [OK]

Common Mistakes:

• Confusing blue-green with backup strategies
• Thinking it speeds up tests
• Assuming deployment timing is the main goal

2. Which Jenkins pipeline step correctly switches traffic from the blue environment to the green environment?

easy

A. sh 'kubectl patch service myapp -p "{\"spec\":{\"selector\":{\"env\":\"green\"}}}'

B. sh 'kubectl apply -f green-service.yaml'

C. sh 'kubectl scale deployment blue --replicas=0'

D. sh 'kubectl delete pod blue-pod-1'

Solution

1. Step 1: Understand traffic switching in Kubernetes

   Switching traffic means updating the service selector to point to the new environment pods.

2. Step 2: Identify the correct kubectl command

   The patch command changes the service selector to 'green', redirecting traffic from blue to green.

3. Final Answer:

   sh 'kubectl patch service myapp -p "{\"spec\":{\"selector\":{\"env\":\"green\"}}}' -> Option A

4. Quick Check:

   Patch service selector = switch traffic [OK]

Hint: Patch service selector to switch environments [OK]

Common Mistakes:

• Scaling down blue does not switch traffic immediately
• Applying green service config alone doesn't switch traffic
• Deleting pods causes downtime

3. Given this Jenkins pipeline snippet, what will be the output if the green environment is healthy?

stage('Deploy Green') {
  steps {
    sh 'kubectl apply -f green-deployment.yaml'
    sh 'kubectl rollout status deployment/green'
  }}
stage('Switch Traffic') {
  steps {
    sh 'kubectl patch service myapp -p "{\"spec\":{\"selector\":{\"env\":\"green\"}}}'
  }}

medium

A. Traffic remains on blue environment

B. Deployment fails because green environment is missing

C. Deployment applies and traffic switches to green with no errors

D. Rollout status command causes syntax error

Solution

1. Step 1: Analyze deployment commands

   The green deployment is applied and rollout status waits for it to be ready.

2. Step 2: Analyze traffic switch command

   The patch command updates the service selector to green, switching traffic successfully.

3. Final Answer:

   Deployment applies and traffic switches to green with no errors -> Option C

4. Quick Check:

   Healthy green + patch service = success [OK]

Hint: Healthy rollout then patch service switches traffic [OK]

Common Mistakes:

• Assuming rollout status causes errors
• Thinking traffic stays on blue after patch
• Confusing deployment apply with service patch

4. You have a Jenkins pipeline that deploys to green, but users report downtime after switching traffic. What is the most likely cause?

medium

A. The Jenkinsfile syntax is incorrect

B. The green deployment rollout was not completed before switching traffic

C. The blue environment was deleted before switching

D. The service selector was not patched to green

Solution

1. Step 1: Understand downtime cause in blue-green

   Downtime happens if traffic switches before the new environment is ready.

2. Step 2: Identify pipeline mistake

   If rollout status is skipped or incomplete, green pods may not be ready, causing downtime.

3. Final Answer:

   The green deployment rollout was not completed before switching traffic -> Option B

4. Quick Check:

   Incomplete rollout before switch = downtime [OK]

Hint: Wait for rollout status before switching traffic [OK]

Common Mistakes:

• Deleting blue early does not cause downtime if green is ready
• Syntax errors cause pipeline failure, not downtime
• Not patching service keeps old traffic, no downtime

5. In a Jenkins pipeline implementing blue-green deployment, how can you safely clean up the old environment after switching traffic to green?

hard

A. Scale down the blue deployment to zero replicas after verifying green is stable

B. Delete the blue deployment immediately after patching the service

C. Keep both blue and green running indefinitely

D. Restart Jenkins to clear old environment

Solution

1. Step 1: Understand cleanup in blue-green deployment

   After switching traffic, the old environment should be scaled down to free resources but kept until stability is confirmed.

2. Step 2: Identify safe cleanup method in Jenkins pipeline

   Scaling down blue to zero replicas after green is stable avoids downtime and allows rollback if needed.

3. Final Answer:

   Scale down the blue deployment to zero replicas after verifying green is stable -> Option A

4. Quick Check:

   Scale down old env after stable new env [OK]

Hint: Scale down old env only after new env is stable [OK]

Common Mistakes:

• Deleting old deployment immediately risks downtime
• Keeping both running wastes resources
• Restarting Jenkins does not affect deployments