Step 3 - Trigger Deployment

In complex systems, it's often better to separate the "Build" logic from the "Deploy" logic. In this step, we push the image to a Development repository and then trigger a separate deployment job.

Jenkinsfile

Here is the Jenkinsfile for this step. Source code: 30-03-Jenkinsfile-docker-build-push-dev-repository-trigger-dev-deploy.

pipeline {
  agent any
  options {
    disableConcurrentBuilds()
    disableResume()
    buildDiscarder(logRotator(numToKeepStr: '10'))
    timeout(time: 1, unit: 'HOURS')
  }
  tools {
    maven 'maven-3.6.3' 
  }
  environment {
    DOCKER_REGISTRY = "vigneshsweekaran.jfrog.io"
    DOCKER_REPOSITORY = "docker-helloworld-dev-local"
    IMAGE_NAME = "hello-world-java"
    IMAGE_TAG = "1.${BUILD_NUMBER}"
    DOCKER_CREDENTIAL_ID = "jfrog-credential"
  }
  stages {
    stage ('Build') {
      steps {
        sh 'mvn clean package'
      }
    }
    stage ('Docker Build') {
      steps {
        script {
          docker.build("${DOCKER_REGISTRY}/${DOCKER_REPOSITORY}/${IMAGE_NAME}:${IMAGE_TAG}")
        }
      }
    }
    stage ('Docker Push') {
      steps {
        script {
          docker.withRegistry("https://${DOCKER_REGISTRY}", "${DOCKER_CREDENTIAL_ID}") {
            docker.image("${DOCKER_REGISTRY}/${DOCKER_REPOSITORY}/${IMAGE_NAME}:${IMAGE_TAG}").push() 
          }           
        }
      }
    }
    stage ('Trigger deployment') {
      steps {
        build wait: false, job: 'deploy',  parameters: [string(name: 'IMAGE_TAG', value: "${IMAGE_TAG}")]
      }
    }
  }
  post {
    always {
      deleteDir()
    }
  }
}

Detailed Explanation

Environment Block

We specifically target the docker-helloworld-dev-local repository here. This ensures that every build initially goes to the Development repository, preventing untested code from reaching QA or Prod.

Trigger Deployment Stage

• build step: Use this to trigger another Jenkins job (in this case, named 'deploy').
• wait: false: We do not wait for the deployment to finish. The build job succeeds as soon as the deployment job is triggered.
• parameters: We pass the IMAGE_TAG (the version we just built) to the deploy job, ensuring it deploys exactly what we just built.

Important Tips

Tip

Passing parameters between jobs is crucial for maintaining artifact consistency. Never rely on "latest" when triggering downstream jobs.

Next Step: Deploy from Multiple Repos

Quick Quiz

Quick Quiz

#

Which step is used to trigger another Jenkins job?

build

trigger

job

run

The build step is used to trigger other jobs from within a pipeline.

#

What does wait: false do when triggering a downstream job?

It starts the job and immediately finishes the step without waiting for the job to complete

It waits for the job to complete

It pauses the pipeline indefinitely

It fails the build if the job fails

wait: false makes the trigger asynchronous, colloquially known as "fire and forget".

#

Why might you separate Build and Deploy into different jobs?

To allow independent control, better resource management, and cleaner separation of concerns

Because Jenkins requires it

To slow down the pipeline

To use more agents

Separation allows for better granularity, failure isolation, and permission management between building artifacts and deploying them.

📬 DevopsPilot Weekly — Learn DevOps, Cloud & Gen AI the simple way.
👉 Subscribe here