Bird
Raised Fist0
Jenkinsdevops~10 mins

Blue-green deployment pattern in Jenkins - Step-by-Step Execution

Choose your learning style10 modes available
Process Flow - Blue-green deployment pattern
Start with Blue environment live
↓
Deploy new version to Green environment
↓
Test Green environment
↓
Switch traffic to Green
↓
Green is live
↓
Old Blue environment idle
This flow shows how traffic switches between two identical environments (Blue and Green) to deploy updates safely.
Execution Sample
Jenkins
pipeline {
  stages {
    stage('Deploy Green') {
      steps {
        echo 'Deploying to Green environment'
      }
    }
    stage('Switch Traffic') {
      steps {
        echo 'Switching traffic to Green'
      }
    }
  }
}
A Jenkins pipeline that deploys to the Green environment and then switches traffic to it.
Process Table
StepActionEnvironment StateTraffic RoutingResult
1Start with Blue liveBlue: live, Green: idleTraffic -> BlueSystem serving users from Blue
2Deploy new version to GreenBlue: live, Green: deployingTraffic -> BlueGreen environment updated, Blue still live
3Test Green environmentBlue: live, Green: readyTraffic -> BlueGreen passes tests, ready for switch
4Switch traffic to GreenBlue: live, Green: liveTraffic -> GreenUsers now served by Green
5Blue environment idleBlue: idle, Green: liveTraffic -> GreenBlue environment ready for next update
💡 Traffic switched to Green, Blue environment is idle, deployment complete
Status Tracker
VariableStartAfter Step 2After Step 3After Step 4Final
Blue environment stateliveliveliveidleidle
Green environment stateidledeployingreadylivelive
Traffic routingBlueBlueBlueGreenGreen
Key Moments - 3 Insights
Why do we keep Blue environment live while deploying to Green?
Because Blue serves users without interruption during Green deployment, ensuring no downtime (see execution_table step 2).
What happens if Green environment tests fail?
Traffic stays on Blue, and Green deployment is rolled back or fixed before switching (implied by execution_table step 3 branching).
Why is Blue environment kept idle after switching traffic?
To have a ready fallback environment for quick rollback if needed (execution_table step 5).
Visual Quiz - 3 Questions
Test your understanding
Look at the execution_table, at which step does traffic switch from Blue to Green?
AStep 4
BStep 3
CStep 2
DStep 5
💡 Hint
Check the 'Traffic Routing' column in execution_table rows
According to variable_tracker, what is the state of the Blue environment after step 4?
Alive
Bidle
Cdeploying
Dready
💡 Hint
Look at 'Blue environment state' column after 'After Step 4' in variable_tracker
If the Green environment fails testing, what would happen to traffic routing?
ASwitch to Green anyway
BTraffic stops completely
CTraffic remains on Blue
DTraffic switches to a new environment
💡 Hint
Refer to key_moments about test failure and execution_table step 3
Concept Snapshot
Blue-green deployment uses two identical environments: Blue (live) and Green (idle).
Deploy updates to Green while Blue serves users.
Test Green, then switch traffic to Green if tests pass.
Blue becomes idle, ready for rollback.
This ensures zero downtime and quick recovery.
Full Transcript
Blue-green deployment pattern uses two environments to avoid downtime. Initially, Blue is live serving users. The new version is deployed to Green while Blue remains live. After deployment, Green is tested. If tests pass, traffic switches to Green, making it live. Blue then becomes idle, ready for the next update or rollback. This method ensures users experience no downtime and allows quick fallback if needed.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard