Blue-green deployment pattern in Jenkins - Commands & Configuration

Introduction

Blue-green deployment helps you update your app without downtime by running two identical environments. One is live (blue), and the other (green) is updated and tested. Then traffic switches to green, making the update seamless.

When you want to update your web app without making users wait or see errors.

When you need to test a new version of your app in a real environment before making it live.

When you want a quick way to roll back to the old version if the new one has problems.

When your app runs on servers or containers and you want zero downtime during updates.

When you want to reduce risks during deployment by switching traffic instead of replacing code live.

Config File - Jenkinsfile

Jenkinsfile

pipeline {
  agent any
  stages {
    stage('Deploy to Green') {
      steps {
        echo 'Deploying new version to green environment'
        // Simulate deployment commands
        sh 'echo Deploying app version 2 to green environment'
      }
    }
    stage('Test Green') {
      steps {
        echo 'Running tests on green environment'
        // Simulate tests
        sh 'echo Tests passed on green environment'
      }
    }
    stage('Switch Traffic') {
      steps {
        echo 'Switching traffic from blue to green environment'
        // Simulate traffic switch
        sh 'echo Traffic switched to green environment'
      }
    }
  }
  post {
    success {
      echo 'Deployment successful! Blue-green switch complete.'
    }
    failure {
      echo 'Deployment failed! Keeping blue environment live.'
    }
  }
}

This Jenkinsfile defines a pipeline with three main stages:

• Deploy to Green: Deploys the new app version to the green environment without affecting users.
• Test Green: Runs tests on the green environment to ensure the new version works correctly.
• Switch Traffic: Switches user traffic from the blue (old) environment to the green (new) environment.

The post section handles success or failure messages to inform about deployment status.

Commands

This command updates the Jenkins job with the new Jenkinsfile that contains the blue-green deployment pipeline.

Terminal

jenkins-jobs --conf jenkins.ini update Jenkinsfile

Expected Output

Job updated successfully

Starts the blue-green deployment pipeline job and waits for it to finish, showing the console output.

Terminal

jenkins-cli build blue-green-deployment -s

Expected Output

[Pipeline] Start of Pipeline

[Pipeline] echo

Deploying new version to green environment

[Pipeline] sh

+ echo Deploying app version 2 to green environment

Deploying app version 2 to green environment

[Pipeline] echo

Running tests on green environment

[Pipeline] sh

+ echo Tests passed on green environment

Tests passed on green environment

[Pipeline] echo

Switching traffic from blue to green environment

[Pipeline] sh

+ echo Traffic switched to green environment

Traffic switched to green environment

[Pipeline] echo

Deployment successful! Blue-green switch complete.

[Pipeline] End of Pipeline

Finished: SUCCESS

→

-s - Waits for the job to finish and shows the console output

Checks the HTTP response headers from the live app URL to confirm the green environment is serving traffic.

Terminal

curl -I http://myapp.example.com

Expected Output

HTTP/1.1 200 OK

Server: nginx

Content-Type: text/html

Connection: keep-alive

Key Concept

If you remember nothing else from this pattern, remember: run two identical environments and switch user traffic to the new one only after testing it.

Common Mistakes

Deploying the new version directly to the live environment without a separate green environment.

This causes downtime or errors for users during deployment.

Always deploy to a separate green environment first, test it, then switch traffic.

Switching traffic to green environment before running tests.

If the new version has bugs, users will experience failures immediately.

Run thorough tests on the green environment before switching traffic.

Not having a rollback plan to switch back to blue if green fails.

You cannot quickly recover from a bad deployment, causing prolonged downtime.

Keep the blue environment intact until green is confirmed stable, so you can switch back if needed.

Summary

Create a Jenkins pipeline that deploys the new app version to a green environment.

Test the green environment to ensure the new version works correctly.

Switch user traffic from the blue environment to the green environment after successful tests.

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