Blue Green Deployment in Jenkins: Step-by-Step Guide

To implement blue-green deployment in Jenkins, create two identical environments (blue and green) and use a Jenkins pipeline to deploy to the inactive one while the active serves traffic. After testing, switch the traffic to the updated environment by updating load balancer or DNS settings within the pipeline.

Syntax

A typical Jenkins pipeline for blue-green deployment includes stages to deploy to the inactive environment, test it, and switch traffic. Key parts are:

• environment: defines blue and green targets
• stages: deploy, test, and switch
• script: controls logic to choose active/inactive environment

groovy

pipeline {
  agent any
  environment {
    BLUE = 'blue-env'
    GREEN = 'green-env'
  }
  stages {
    stage('Determine Target') {
      steps {
        script {
          currentEnv = sh(script: "curl -s http://loadbalancer/current", returnStdout: true).trim()
          targetEnv = currentEnv == env.BLUE ? env.GREEN : env.BLUE
          echo "Deploying to ${targetEnv}"
        }
      }
    }
    stage('Deploy') {
      steps {
        echo "Deploying application to ${targetEnv}"
        // Deployment commands here
      }
    }
    stage('Test') {
      steps {
        echo "Testing ${targetEnv} environment"
        // Test commands here
      }
    }
    stage('Switch Traffic') {
      steps {
        echo "Switching traffic to ${targetEnv}"
        sh "curl -X POST http://loadbalancer/switch?env=${targetEnv}"
      }
    }
  }
}

Example

This example Jenkins pipeline script demonstrates a simple blue-green deployment. It checks which environment is active, deploys to the other, runs tests, and switches traffic by calling a load balancer API.

groovy

pipeline {
  agent any
  environment {
    BLUE = 'blue'
    GREEN = 'green'
  }
  stages {
    stage('Get Active Environment') {
      steps {
        script {
          activeEnv = sh(script: "curl -s http://localhost:8080/current-env", returnStdout: true).trim()
          targetEnv = activeEnv == env.BLUE ? env.GREEN : env.BLUE
          echo "Active environment: ${activeEnv}"
          echo "Target environment for deployment: ${targetEnv}"
        }
      }
    }
    stage('Deploy to Target') {
      steps {
        echo "Deploying app to ${targetEnv} environment"
        sh "./deploy.sh ${targetEnv}"
      }
    }
    stage('Run Smoke Tests') {
      steps {
        echo "Running tests on ${targetEnv}"
        sh "./smoke-test.sh ${targetEnv}"
      }
    }
    stage('Switch Traffic') {
      steps {
        echo "Switching traffic to ${targetEnv}"
        sh "curl -X POST http://localhost:8080/switch-env?env=${targetEnv}"
      }
    }
  }
}

Output

Active environment: blue
Target environment for deployment: green
Deploying app to green environment
Running tests on green
Switching traffic to green

Common Pitfalls

• Not verifying the inactive environment: Deploying without testing can cause downtime if the new version is broken.
• Failing to switch traffic properly: Forgetting to update the load balancer or DNS means users stay on the old version.
• Hardcoding environment names: Makes the pipeline less flexible and harder to maintain.
• Ignoring rollback plans: Always prepare a way to revert if the new deployment fails.

groovy

/* Wrong: No environment check, deploys directly */
pipeline {
  agent any
  stages {
    stage('Deploy') {
      steps {
        echo 'Deploying to blue environment only'
        sh './deploy.sh blue'
      }
    }
  }
}

/* Right: Dynamically choose environment and switch traffic */
pipeline {
  agent any
  environment {
    BLUE = 'blue'
    GREEN = 'green'
  }
  stages {
    stage('Determine Target') {
      steps {
        script {
          currentEnv = sh(script: "curl -s http://loadbalancer/current", returnStdout: true).trim()
          targetEnv = currentEnv == env.BLUE ? env.GREEN : env.BLUE
          echo "Deploying to ${targetEnv}"
        }
      }
    }
    // Further stages...
  }
}

Quick Reference

• Maintain two identical environments: blue and green.
• Deploy to the inactive environment while the active serves users.
• Run tests on the inactive environment before switching.
• Switch traffic by updating load balancer or DNS settings.
• Include rollback steps in your Jenkins pipeline.

Key Takeaways

Use Jenkins pipeline to automate deployment to inactive environment for zero downtime.

Always test the new environment before switching user traffic.

Switch traffic by updating load balancer or DNS within the pipeline.

Avoid hardcoding environment names; use variables and logic.

Prepare rollback steps to handle deployment failures safely.