Rollback strategies in Jenkins - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Blue-Green Deployment Rollback

In a Jenkins pipeline using blue-green deployment, what is the main advantage of the rollback strategy?

A It requires manual intervention to switch environments.

B It instantly switches traffic back to the previous stable environment without downtime.

C It rebuilds the entire application from scratch before rollback.

D It deletes the previous environment to save resources.

💡 Hint

Think about how blue-green deployment handles traffic between two environments.

Blue-green deployment keeps two environments ready. Rollback means switching traffic back instantly to the stable one, avoiding downtime.

💻 Command Output

intermediate

Jenkins Pipeline Rollback Step Output

What is the output of this Jenkins pipeline snippet when rollback is triggered?

Jenkins

pipeline {
  agent any
  stages {
    stage('Deploy') {
      steps {
        script {
          def success = false
          if (!success) {
            error('Deployment failed, triggering rollback')
          }
        }
      }
    }
    stage('Rollback') {
      steps {
        echo 'Rollback started'
      }
    }
  }
  post {
    failure {
      echo 'Rollback started'
    }
  }
}

A

[Pipeline] { (Deploy)
[Pipeline] error
Deployment failed, triggering rollback
[Pipeline] }
[Pipeline] { (Rollback)
[Pipeline] echo
Rollback started
[Pipeline] }
[Pipeline] echo
Rollback started

B

[Pipeline] { (Deploy)
[Pipeline] echo
Rollback started
[Pipeline] }
[Pipeline] { (Rollback)
[Pipeline] error
Deployment failed, triggering rollback

C

[Pipeline] { (Deploy)
[Pipeline] echo
Deployment succeeded
[Pipeline] }
[Pipeline] { (Rollback)
[Pipeline] echo
Rollback started
[Pipeline] }

D

[Pipeline] { (Deploy)
[Pipeline] error
Deployment failed, triggering rollback
[Pipeline] }
[Pipeline] { (Rollback)
[Pipeline] echo
Deployment succeeded
[Pipeline] }

💡 Hint

Look at how the error and post failure blocks behave in Jenkins pipelines.

The error in the Deploy stage triggers failure. The post failure block and Rollback stage both echo 'Rollback started'.

❓ Configuration

advanced

Configuring Jenkins Pipeline for Canary Rollback

Which Jenkins pipeline snippet correctly implements a canary deployment rollback by checking a health status and reverting if unhealthy?

A

pipeline {
  agent any
  stages {
    stage('Deploy Canary') {
      steps {
        script {
          def healthy = sh(script: 'curl -sf http://canary/health', returnStatus: true) == 1
          if (!healthy) {
            error('Canary unhealthy, rollback')
          }
        }
      }
    }
    stage('Rollback') {
      steps {
        echo 'Rolling back to previous version'
      }
    }
  }
  post {
    failure {
      echo 'Rollback triggered due to failure'
    }
  }
}

B

pipeline {
  agent any
  stages {
    stage('Deploy Canary') {
      steps {
        script {
          def healthy = sh(script: 'curl -sf http://canary/health', returnStatus: true) == 0
          if (healthy) {
            error('Canary unhealthy, rollback')
          }
        }
      }
    }
    stage('Rollback') {
      steps {
        echo 'Rolling back to previous version'
      }
    }
  }
  post {
    failure {
      echo 'Rollback triggered due to failure'
    }
  }
}

C

pipeline {
  agent any
  stages {
    stage('Deploy Canary') {
      steps {
        script {
          def healthy = sh(script: 'curl -sf http://canary/health', returnStatus: true)
          if (healthy) {
            error('Canary unhealthy, rollback')
          }
        }
      }
    }
    stage('Rollback') {
      steps {
        echo 'Rolling back to previous version'
      }
    }
  }
  post {
    failure {
      echo 'Rollback triggered due to failure'
    }
  }
}

D

pipeline {
  agent any
  stages {
    stage('Deploy Canary') {
      steps {
        script {
          def healthy = sh(script: 'curl -sf http://canary/health', returnStatus: true) == 0
          if (!healthy) {
            error('Canary unhealthy, rollback')
          }
        }
      }
    }
    stage('Rollback') {
      steps {
        echo 'Rolling back to previous version'
      }
    }
  }
  post {
    failure {
      echo 'Rollback triggered due to failure'
    }
  }
}

💡 Hint

Remember that sh returns 0 on success and non-zero on failure.

Option D correctly checks if the health check returns 0 (success). If not healthy, it triggers rollback by error.

❓ Troubleshoot

advanced

Troubleshooting Jenkins Rollback Stage Not Executing

A Jenkins pipeline has a rollback stage defined after deployment. The rollback stage does not run even when deployment fails. What is the most likely cause?

A The rollback stage uses <code>echo</code> instead of <code>sh</code> commands.

B The rollback stage is not inside a <code>post { failure {}</code> block or not triggered by error.

C The deployment stage uses <code>try-catch</code> to handle errors and does not rethrow them.

D The rollback stage is defined before the deployment stage.

💡 Hint

Think about how Jenkins decides to run post or subsequent stages on failure.

If deployment errors are caught and not rethrown, Jenkins considers the stage successful and skips rollback.

🔀 Workflow

expert

Optimizing Rollback Workflow in Jenkins Multibranch Pipeline

In a Jenkins multibranch pipeline, which workflow best ensures automatic rollback on failure while minimizing downtime and resource usage?

A Use a separate rollback stage triggered only in the <code>post { failure {}</code> block, which switches traffic back and cleans up failed deployment.

B Always run rollback stage after deployment regardless of success, to ensure clean state.

C Manually trigger rollback job outside the pipeline when failure is detected to avoid pipeline complexity.

D Deploy new version and keep old version running; rollback only after manual approval to save resources.

💡 Hint

Consider automation, downtime, and resource efficiency in your answer.

Option A automates rollback only on failure, minimizing downtime and resource use by cleaning up failed deployments immediately.