Jenkins Pipeline is used to streamline the build process. With various Jenkins plugins, we can define an automated continuous delivery process. Creating Jenkinsfile and committing it to the source code is the current best practice.

The following is how the Jenkinsfile looks at a high level:

pipeline {
  ...
  environment {...}
  stages {
    stage("Build package") {...}
    stage("Build Docker image") {...}
    stage("Push Docker build image") {...}
    stage("Deploy to staging") {...}
    stage("Run E2E tests") {...}
  }
  post {...}
}

Let's go through each stage, one by one. The following is how the "Build package" stage looks:

stage("Build package") {
  steps {
    echo "Git commit: ${env.GIT_COMMIT}"
    sh "mvn clean package"
  }
}

In this stage, we print out the ID of the last commit for reference. Then we invoke the mvn clean package command to build the application.

The following is how the "Build Docker image" stage looks:

stage("Build Docker image") {
  steps {
    sh "cp target/app-0.0.1-SNAPSHOT.jar docker/app.jar"
    sh "docker build -t ${DOCKER_REPO}:${env.GIT_COMMIT} docker/"
  }
}

In this stage, we copy the .jar package into the docker folder. Then we build the Docker image and tag it with the last commit ID. The ${DOCKER_REPO} variable is an environment variable we defined in environment section. The ${env.GIT_COMIT} variable is an environment variable created by Jenkins's Git plugin, with the value of the last commit ID. We can also add the prefix env to our own variables. Here, we omit it to make it easier to tell if a variable is defined by us or not.

The following is how the "Push Docker build image" stage looks:

stage("Push Docker build image") {
  steps {
    withDockerRegistry([ credentialsId: DOCKER_CREDENTIAL, url: '' ]) {
      sh "docker push ${DOCKER_REPO}:${env.GIT_COMMIT}"
    }
  }
}

In this stage, we publish the Docker image we just built to https://hub.docker.com.

The following is how the "Deploy to staging" stage looks:

stage("Deploy to staging") {
  steps {
    sh "ssh ${JENKINS_AT_STAGING} rm -fr /app/env.list /app/start.sh"
    sh "scp ./docker/env.list ./docker/start.sh 
    ${JENKINS_AT_STAGING}:/app"
    sh "ssh ${JENKINS_AT_STAGING} "cd /app && ./start.sh 
    ${env.GIT_COMMIT}""
  }
}

In this stage, we connect to the staging server via SSH to remove the existing env.list and start.sh, then copy the new version over. Once that is done, we switch to the /app directory and execute the start.sh bootstrap script with the last commit ID.

The following is how the "Run E2E test" stage looks:

stage("Run E2E tests") {
  steps {
    sh "cd ${env.WORKSPACE}/frontend && npm run test:staging-e2e"
  }
}

In this stage, we switch to the front-end directory and run the E2E test against the staging environment.

The following is how the "post" section looks:

post {
  always {
    emailext (
      subject: "[Jenkins] ${env.JOB_NAME} Build #${env.BUILD_NUMBER} - 
      ${currentBuild.currentResult}",
      recipientProviders: [[$class: 'DevelopersRecipientProvider'], 
      [$class: 'RequesterRecipientProvider']],
      body: "${currentBuild.currentResult}

Job: 
        ${env.JOB_NAME}
Build: #${env.BUILD_NUMBER}
Git commit: 
        ${env.GIT_COMMIT}
More detail at: ${env.BUILD_URL}"
    )
    sh "docker rmi -f ${DOCKER_REPO}:${env.GIT_COMMIT}"
  }
}

In this section, we define an always condition. The steps defined inside it will be executed, no matter whether the build succeeded or failed. As you can see, we use Jenkins Email Extension Plugin to send an email to the developers, as well as those who requested to be notified. Then, we remove the Docker image we just built.

The following is the commit record of adding Dockerfile and Jenkinsfile: