Let's take a look at the generated Jenkinsfile, which has our pipeline definitions, using the Groovy DSL:

#!/usr/bin/env groovy

node {
    stage('checkout') {
        checkout scm
    }
    stage('check java') {
        sh "java -version"
    }
    stage('clean') {
        sh "chmod +x gradlew"
        sh "./gradlew clean --no-daemon"
    }
    stage('nohttp') {
        sh "./gradlew checkstyleNohttp --no-daemon"
    }
    stage('npm install') {
        sh "./gradlew npm_install -PnodeInstall --no-daemon"
    }
    stage('backend tests') {
        try {
            sh "./gradlew test integrationTest -PnodeInstall
             --no-daemon"
        } catch(err) {
            throw err
        } finally {
            junit '**/build/**/TEST-*.xml'
        }
    }
    stage('frontend tests') {
        try {
            sh "./gradlew npm_run_test -PnodeInstall --no-daemon"
        } catch(err) {
            throw err
        } finally {
            junit '**/build/test-results/TESTS-*.xml'
        }
    }
    stage('packaging') {
        sh "./gradlew bootJar -x test -Pprod -PnodeInstall
          --no-daemon"
        archiveArtifacts artifacts: '**/build/libs/*.jar', 
        fingerprint: true
    }
    stage('deployment') {
        sh "./gradlew deployHeroku --no-daemon"
    }
}

We have multiple stages defined running in a sequence, highlighted in bold; there are nine to be exact. It starts with a checkout of the branch from version control ending with deployment to Heroku (we will learn more about this in the following chapter).

The steps are quite straightforward as most of it is just triggering a Gradle task. Let's look at some of them:

    stage('checkout') {
        checkout scm
    }

The checkout stage does a local checkout of the source code revision that triggered the build:

    stage('check java') {
        sh "java -version"
    }

This check java stage just prints the Java version installed on the Jenkins environment:

    stage('clean') {
        sh "chmod +x gradlew"
        sh "./gradlew clean --no-daemon"
    }

The clean stage first grants execution permission for the Gradle wrapper on a Unix-like OS and then executes the Gradle clean task. The --no-daemon flag disables the Gradle daemon feature, which is not required in a CI environment:

    stage('npm install') {
        sh "./gradlew npm_install -PnodeInstall --no-daemon"
    }

The npm install stage makes sure that Node.js and all of the NPM modules are installed by running npm install via Gradle.

The -PnodeInstall flag ensures that Node.js is installed first if not done already:

    stage('backend tests') {
        try {
            sh "./gradlew test integrationTest -PnodeInstall
               --no-daemon"
        } catch(err) {
            throw err
        } finally {
            junit '**/build/**/TEST-*.xml'
        }
    }

The backend tests stage runs all of the server-side integration and unit tests by triggering the Gradle test task. It will fail the Jenkins pipeline when there is an error and register the test reports on the Jenkins web UI using the JUnit plugin after the test run is complete:

    stage('frontend tests') {
        try {
            sh "./gradlew npm_run_test -PnodeInstall --no-daemon"
        } catch(err) {
            throw err
        } finally {
            junit '**/build/test-results/TESTS-*.xml'
        }
    }

Similar to the previous task, the frontend tests stage runs the client-side unit tests by triggering the NPM test command via a Gradle task. It will also fail the pipeline on an error and register the test reports on the Jenkins web UI:

    stage('packaging') {
        sh "./gradlew bootJar -x test -Pprod -PnodeInstall --no-daemon"
        archiveArtifacts artifacts: '**/build/libs/*.jar',
         fingerprint: true
    }

The packaging stage triggers the Gradle bootJar task with the prod profile and archives the created JAR files with a unique fingerprint:

    stage('deployment') {
        sh "./gradlew deployHeroku --no-daemon"
    }

The final stage is for deployment and it uses a Gradle task for this. We will see this in detail in the following chapter. For now, let's comment out this stage. We will re-enable it later.

Now, let's commit everything to git by running these commands. Make sure you are on the master branch; if not, commit and merge the branch with the master:

> git add --all
> git commit -am "add Jenkins pipeline for ci/cd"

Let's see how we can use the pipeline with the Jenkins server we set up earlier.