Archived content

Archived date: 2019-05-22

This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed.

Introduction

In Part 1 of this series, you migrated the Daytrader3 application from IBM® WebSphere® Application Server Liberty 8.5.5.0 to the latest version of Liberty server. In Part 2, you migrated the Daytrader3 application that is running in an on-premises Liberty 17.0.0.2 server to the cloud platforms of IBM Cloud Private (with Docker and Kubernetes) and IBM Cloud (with Cloud Foundry). In Part 3, you added build automation to the monolith by using the Maven industry standard build lifecycle and augmented the lifecycle with plug-in bindings to support continuous integration of the monolith. Now, in Part 4, you configure Jenkins for build automation, continuous integration, and continuous delivery.

In this article, you upload the DayTrader project to GitHub. Then, you configure Jenkins Pipelines for build automation and continuous integration by using the Maven command-line interfaces (CLIs) from Part 3. You also configure Jenkins Pipelines for continuous delivery to IBM Cloud (Cloud Foundry) and IBM Cloud Private (Docker/Kubernetes) by using the CLIs that are provided by those platforms.

To continue with Part 4, you must have the workspace and WebSphere Liberty server from Parts 1, 2, and 3. If you did not complete the steps in these parts, download Part3Final.zip from the GitHub repository.

Prerequisites

Understanding Jenkins

The Jenkins Pipeline has the following classified and configured stages:

  • Build automation: This stage is automatically triggered whenever developers commit their code to the master branch. Code in each module is compiled and then unit tested. Each module provides its own unit tests. If any of the unit tests fail, this stage fails.
  • Continuous integration: This stage is not automatically triggered because the integration tests that are run in this stage might take a while to complete. Therefore, you might not want to run them every time something is committed to the GitHub repository. Instead, this stage is started manually. It performs the build, deploys the application to a local test server, and then runs the integration tests. If the integration tests fail, this stage fails. Otherwise, this stage passes. The local test server can be a stand-alone Liberty server or a Liberty server in a Docker container.
  • Continuous delivery: This stage is triggered whenever the Continuous integration stage passes. It uses the target runtime APIs to deploy the results from the previous stage. For DayTrader, the results include the Liberty server configuration and its application. At the completion of this stage, the application runs in the target environment and is ready for the QA team to perform their tests.

Jenkins has long been the industry standard platform for continuous integration. And, with the addition of Pipelines and pipeline configuration as code in 2016, Jenkins is rapidly becoming the industry standard for continuous integration and continuous delivery for on-premises and cloud deployment targets.

IBM DevOps Services on IBM Cloud provides similar capabilities for cloud deployments. Although we could deploy DayTrader to IBM Cloud by using a toolchain based on IBM Cloud, we would need an on-premises platform for deployment to IBM Cloud Private. For simplicity, we chose Jenkins for the continuous integration and continuous delivery of the Daytrader application for both IBM Cloud and IBM Cloud Private.

Chef and Puppet are two other tools that are often mentioned in the continuous integration and continuous delivery space. However, they are mainly aimed only at continuous delivery and do not provide as much support for continuous integration.

Upload the projects to GitHub

With your personal GitHub account, create a GitHub repository. You will also use this personal GitHub account later in this tutorial for the Jenkins Pipelines. Then, upload the DayTrader projects by using Eclipse.

Create a GitHub repository

Create a GitHub repository that is named daytrader-ee6-CF.

  1. Log in to GitHub. Create an account if necessary.
  2. Click Start a Project.
  3. Set Repository Name to daytrader-ee6.
  4. Click Create Repository.
  5. Copy the following URI:

    https://github.com/davemulley/daytrader-ee6

Upload the DayTrader projects to the GitHub repository

You can upload Maven projects to GitHub by using the command line, but in this tutorial, you upload it by using Eclipse:

  1. In your Eclipse workspace from Part 3 of this article series, select Window -> Show View -> Other -> Git -> Git Repositories.
  2. Right-click the Git Repository view, and select Paste Repository Path or URI.
  3. In the Source Git Repository window:

    1. Paste the URI that you copied from GitHub.
    2. Under Authentication, enter your user name and password, and click Next.

      GitHub Eclipse Configuration

  4. In the Branch Selection window, click Next.
  5. In the Local Destination window, click Finish.
  6. In Eclipse, open the Navigator view.
  7. Right-click daytrader3-ee6, and select Team -> Share Project.
  8. In the Configure Git Repository window, for Repository, select your repository, and then click Finish.

    Configure Git Repository for daytrader-ee6

  9. Repeat steps 7 and 8 for the dt-ejb, Rest, and web projects.
  10. To upload the project contents, commit the changes. In the Navigator view, select daytrader-ee6 -> Team -> Commit.
  11. Maximize the Git Staging view.
  12. Select all of the unstaged changes, right-click, and select Add to index. This step moves the changes to the Staged Changes view.

    Staged Changes View

  13. In the Commit Message box, enter First Commit, and click Commit and Push to push the projects to GitHub. This process might take a few minutes to complete.

Create the Jenkinsfile for unit test

Before you configure a Jenkins Build Automation Pipeline for the DayTrader application, you must complete these actions:

  1. Download and start Jenkins on a machine that also has Maven installed (see Part 2).
  2. Install the GitHub Branch Source Plugin in to Jenkins.
  3. Create the Jenkinsfile for unit test (as explained in Step 2).

You can store the Jenkins configuration as source code by using a Jenkinsfile. In this step, you create a Jenkinsfile to run the clean and test maven commands against the dt-ejb, Rest, and web projects that will compile the code and then run unit tests for each project.

In the root of your DayTrader GitHub project, create a file that is named Jenkinsfile-buildautomation, and populate it with the following code:

pipeline {
 agent any
 stages {
 stage('Build Automation') {
 steps {
 sh '''
 echo "BUILD NUMBER: ${BUILD_NUMBER}"
 cd dt-ejb
 mvn clean test
 cd ../Rest
 mvn clean test
 cd ../web
 mvn clean test
 '''
 }
 }
 }
}

Configure the Jenkins Build Automation Pipeline

  1. To start Jenkins, enter:

    java –jar Jenkins.war

  2. Go to http://localhost:8080, and log in to the Jenkins UI as an administrator.
  3. In Jenkins, click New Item, and for the name of the project, enter daytrader-ee6 Build Automation.
  4. For Project Type, select Multibranch Pipeline. If you don’t see Multibranch Pipeline as an option, install the GitHub Branch Source Plugin in to Jenkins. Click OK.
  5. On the Configuration page, under Branch Sources, select Add Source -> GitHub.
  6. For Credentials, select your GitHub credentials. You might need to add your GitHub credentials first by clicking Add.
  7. In the Owner field, enter your GitHub owner name. For Repository, select the daytrader-ee6 project.

    GitHub repository configuration

  8. Scroll down to the Build Configuration section. For Script Path, enter Jenkinsfile-buildautomation.

    Script Pat

  9. Scroll down to the Scan Multibranch Pipeline Triggers section. Select Periodically if not otherwise run. Set Interval to 1 minute.

    Setting the trigger

  10. Click Save. Jenkins now scans the repository to detect the current branches.
  11. After the scan finishes, from the Jenkins menu bar, click daytrader-ee6 Build Automation.

    Jenkins menu bar

  12. When Jenkins lists the detected branches in the GitHub repository, click master.
  13. If Jenkins did not start a build for you, click Build Now to start a build. The following figure shows a completed build.

    Jenkins Stage View

  14. To view the build logs, hover over the green box under in the build section, and click Logs from the menu.

    View the Logs

The Jenkins Build Automation Pipeline is now configured to run when a change is detected in GitHub. You can test this pipeline by committing a change to the GitHub repository and waiting up to a minute for Jenkins to trigger a new build.

Configure the Jenkins continuous integration and continuous delivery pipeline for IBM Cloud (Cloud Foundry)

Next, you configure a Jenkins continuous integration and continuous delivery (CI/CD) pipeline to push the DayTrader application to IBM Cloud (Cloud Foundry). This Pipeline will be manually triggered.

Create the Jenkinsfile for CI/CD with IBM Cloud (Cloud Foundry)

Create a Jenkinsfile to perform the following actions:

  1. Compile the code by running the clean and install maven commands against the dt-ejb, Rest, and web projects.
  2. Run the clean verify command against the daytrader-ee6 project to build the EAR file.
  3. Deploy the EAR file to a local WebSphere Liberty profile instance.
  4. Run the integration tests.
  5. Connect to IBM Cloud.
  6. Push the application.

This Jenkinsfile has a few sections that you should be aware of. The Parameters section uses parameters for the IBM Cloud login information and application name. This way, when a build is triggered, the values are provided dynamically in the Jenkins UI.

The Jenkinsfile also has two stages:

  • Continuous integration: This stage runs the maven commands to compile the code and build the EAR file. It also locally configures and starts the Liberty server instance (named Daytrader3Sample) and runs the integration tests. If the tests are run successfully, the stage is marked as completed.
  • Continuous delivery: This stage uses the Cloud Foundry CLI to log in to IBM Cloud and push the Daytrader3Sample Liberty server instance. This stage is marked as complete when the application is started in Cloud Foundry. You can use the Cloud Foundry CLI on any Cloud Foundry platform. The CLI is not specific to IBM Cloud.

In the root of your daytrader-ee6 GitHub project, create a file that is called JenkinsfileCF, and populate it with the contents in the following listing.

Tip: You can replace the values in the parameters section with your values. However, it is not necessary because you can provide the values later in Jenkins when you trigger a build.

pipeline {
 agent any
 parameters {
 string(name: 'CF_USER', defaultValue: '<your userid>')
 string(name: 'CF_PWD', defaultValue: '<your password>')
 string(name: 'CF_ORG', defaultValue: '<your org>')
 string(name: 'CF_SPACE', defaultValue: 'dev')
 string(name: 'CF_APP_NAME', defaultValue: '<your app name>')
 }
 stages {
 stage('Continuous Integration') {
 steps {
 sh '''
 # build dt-ejb project
 cd dt-ejb
 mvn clean install
 # build Rest project
 cd ../Rest
 mvn clean install
 # build web project
 cd ../web
 mvn clean install
 # build EAR, create Liberty server, run tests
 cd ../daytrader-ee6
 mvn clean verify –Pci-liberty
 cd ..
 '''
 }
 }
 stage('Continuous Delivery') {
 steps {
 sh '''
 #!/bin/bash
 cd daytrader-ee6/target
 echo "CF Login..."
                    cf api https://api.ng.bluemix.net
 cf login -u $CF_USER -p $CF_PWD -o $CF_ORG -s $CF_SPACE
 echo "Deploying...."
 if cf app $CF_APP_NAME; then
 echo "Application already exists, pushing new version..."
 cf push $CF_APP_NAME -n $CF_APP_NAME -f ../src/main/resources/config/manifest.yml -p wlp/usr/servers/Daytrader3Sample
 else
 echo "New Application, push and restage required..."
 cf push $CF_APP_NAME -n $CF_APP_NAME -f ../src/main/resources/config/manifest.yml -p wlp/usr/servers/Daytrader3Sample
 cf restage $CF_APP_NAME
 fi
 '''
 }
 }
 }
}

Configure the Jenkins Pipeline for CI/CD for IBM Cloud (Cloud Foundry)

  1. In Jenkins, in the upper-left corner, click the Jenkins menu to return to the home page.
  2. Click New Item.
  3. Name the project daytrader-ee6 CF CICD.
  4. For Project Type, select Multibranch Pipeline, and click OK.
  5. In the Configuration page, under Branch Sources, select Add Source -> GitHub.
  6. From the Credentials list, select your GitHub credentials. You might first need to click Add to add your GitHub credentials.
  7. In the Owner field, add your GitHub owner name, and then for Repository, select your daytrader-ee6 project.
  8. Scroll down to the Build Configuration section, and change Script Path to JenkinsfileCF.

    Script Path for JenkinsfileCF

  9. Scroll down to the Scan Multibranch Pipeline Triggers section. By default, the pipeline is not triggered automatically because you only run this pipeline manually.
  10. Click Save. Jenkins now scans the repository to detect the current branches.
  11. When the scan finishes, in the menu bar, click daytrader-ee6 CF CICD.
  12. When Jenkins lists the detected branches in the GitHub repository, click master.
  13. If Jenkins started a build for you, stop the build now. You must enter the correct properties to start the build. In the Build History section on the left side of the page, click the red X icon next to Build #1. When prompted, click OK to cancel the build.

    Stop the build

  14. Click Build With Parameters to start a build and change the properties as required, and then click Build.
  15. In the Build History section on the left side of the page, click the current build number (#1 in this example), and select Console Output to view the build in action.

    Console Output

After the build is completed, the application should be deployed to IBM Cloud.

Successful Deployment to IBM Cloud

The Jenkins CI/CD Pipeline is now configured to run when manually triggered.

Configure the Jenkins CI/CD Pipeline for Cloud Private (Docker/Kubernetes)

In this section, you configure a Jenkins CI/CD Pipeline to push the DayTrader application to IBM Cloud Private (Docker/Kubernetes). This pipeline is manually triggered. You need at least version 1.6.1 of kubectl, which you can download as explained in “Accessing your IBM Cloud private cluster by using the kubectl CLI” in IBM Knowledge Center.

Create the Kubernetes JSON files for Automated Deployment

In Part 2 of this series, you started an instance of the DayTrader application in IBM Cloud Private manually by using the IBM Cloud Private Management Console UI. In this step, you create two JSON files to use with the kubectl CLI to automate the process. You can use these files with any Kubernetes platform. They are not specific to the IBM Cloud Private platform because they use the Kubernetes API.

To create the JSON files:

  1. In the root of your daytrader-ee6 GitHub project, create a file that is called app.json, and populate it with the contents in the following listing.
{
  "apiVersion": "extensions/v1beta1",
  "kind": "Deployment",
  "metadata": {
    "name": "wlp-daytrader-jenkins",
    "namespace": "default",
    "labels": {
      "app": "wlp-daytrader-jenkins"
    },
    "annotations": {
      "deployment.kubernetes.io/revision": "1",
      "kubernetes.io/change-cause": "Initial application creation."
    }
  },
  "spec": {
    "replicas": 1,
    "selector": {
      "matchLabels": {
        "app": "wlp-daytrader-jenkins"
      }
    },
    "template": {
      "metadata": {
        "labels": {
          "app": "wlp-daytrader-jenkins"
        }
      },
      "spec": {
        "containers": [
          {
            "name": "wlp-daytrader-jenkins",
            "image": "master.cfc:8500/default/daytrader-ee6",
             "ports": [
              {
                "containerPort": 80,
                "protocol": "TCP"
              }
            ],
           "env": [
              {
                "name": "DAYTRADER3_CONTEXT_ROOT_URL",
                "value": "http://localhost:9080/daytrader"
              }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "terminationMessagePolicy": "File",
            "imagePullPolicy": "IfNotPresent"
          }
        ],
        "restartPolicy": "Always",
        "terminationGracePeriodSeconds": 30,
        "dnsPolicy": "ClusterFirst",
        "securityContext": {},
        "imagePullSecrets": [
          {
            "name": "admin.registrykey"
          }
          ],
        "schedulerName": "default-scheduler"
      }
    },
    "strategy": {
      "type": "RollingUpdate",
      "rollingUpdate": {
        "maxUnavailable": 1,
        "maxSurge": 1
      }
    }
  }
}

You use this JSON file to deploy the wlp-daytrader-jenkins application instance by using the Docker image that is tagged as master.cfc:8500/default/daytrader-ee6.

  1. In the root of your daytrader-ee6 GitHub project, create a file called service.json, and populate it with the contents in the following listing. Change the nodePort value to an open port on your IBM Cloud Private proxy.
{
  "kind": "Service",
  "apiVersion": "v1",
  "metadata": {
    "name": "wlp-daytrader-jenkins",
    "namespace": "default",
    "selfLink": "/api/v1/namespaces/default/services/wlp-daytrader-jenkins",
    "labels": {
      "app": "wlp-daytrader-jenkins"
    }
  },
  "spec": {
    "ports": [
      {
        "name": "http",
        "protocol": "TCP",
        "port": 80,
        "targetPort": 9080,
        "nodePort": 31420
      }
    ],
    "selector": {
      "app": "wlp-daytrader-jenkins"
    },
    "type": "NodePort",
    "sessionAffinity": "None"
  }
}

You use this JSON file to expose the wlp-daytrader-jenkins application as a service that is bound to port 31420 on the IBM Cloud Private proxy.

Generate the kubectl CLI token

To log in to IBM Cloud Private from a command line using the kubectl CLI, you must use a service account token. For manual tasks, you can obtain a token from the IBM Cloud Private Management Console. This token works for 12 hours but not for an automated task that is performed by Jenkins. The solution is to extract a service account token from IBM Cloud Private that doesn’t expire. You can find the detailed steps in option 2 of the “Configuring the Kubernetes CLI by using service account tokens” article.

To generate the kubectl CLI token:

  1. Configure the CLI by using the configuration that you extracted from the IBM Cloud Private Management Console:

    1. Log in to your IBM Cloud Private management console.
    2. Select User Account -> Configure Client.
    3. Copy the cluster configuration details that are displayed on the command line, and press Enter.
  2. Issue the command:

    kubectl get secret –namespace=default

  3. Locate the name kubernetes.io/service-account-token as shown in the following figure.

    kubernetes secrets

  4. Enter the following command, and use your secret token name:

    kubectl get secret default-token-mcffm –namespace=default –o yaml

    The following figure shows an example of the output.

    Encoded Token

    The token is encoded. You must decode it so that you can use it.

  5. Copy the token value from the output in step 4. Do not copy any additional spaces or characters outside of the token value. Decode the token by using the following command:

    echo <token> | base64 –d

  6. Copy the decoded token (shown in the following figure) to a text document for later use.

    The decoded token

Create the Jenkinsfile for CI/CD with IBM Cloud Private

Create a Jenkinsfile to perform the following actions:

  1. Compile the code by running the clean and install maven commands against the dt-ejb, Rest, and web projects.
  2. Run the clean verify command against the daytrader-ee6 project to build the EAR file.
  3. Deploy the EAR file to a Docker image.
  4. Run the integration tests against Liberty in a Docker container (if the tests are successful).
  5. Connect to IBM Cloud Private.
  6. Push the Docker image.
  7. Use the kubectl CLI to create a new application and service definition.

This Jenkinsfile has a few sections that you should be aware of. The Parameters section uses parameters for the kubectl CLI login information. This way, when a build is triggered, the values are provided dynamically in the Jenkins UI. This Jenkinsfile also has the following stages:

  • Continuous integration: This stage runs the maven commands to compile the code and build the EAR file. It also configures and starts the Liberty server instance (named Daytrader3 Sample) inside a Docker container, and runs the integration tests. If the tests are run successfully, the stage is marked as completed.
  • Continuous delivery: This stage uses the Docker API and kubectl CLI to log in to IBM Cloud Private, push the Docker image, and create a new Application and a new Service. This stage is marked as completed when the application is started in IBM Cloud Private.

To create the Jenkinsfile, in the root of your daytrader-ee6 GitHub project, create a file that is called JenkinsfileICp and populate it with the contents that are shown in the following code listing.

Tip: You can replace the values in the Parameters section with your values. However, it is not necessary because you can provide the values later in Jenkins when you trigger a build. ICP_TOKEN is the value for the secret token that you extracted in the previous section.

pipeline {
    agent any
    parameters {
        string(name: 'ICP_MASTER_CFC', defaultValue: 'master.cfc:8500')
        string(name: 'ICP_MASTER_8001', defaultValue: 'https://172.21.20.136:8001')
        string(name: 'ICP_TOKEN', defaultValue: 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tbWNmZm0iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjBjNGEzOWY2LTc2YzEtMTFlNy1hODhjLTAwNTA1NjlhNGJhMiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.Jknkvowh-UF-4mgmi0J5BsrSvpzX8yazAceONtQZ4pb0ZGsOOTcQuClc4KQeszAbBqjOLbj0f9FchphAWfhRU02hLaNqsPRIgBL4HhnJNVUrt5Yox5N2z5EWoDLtVLGP6-Ulkp_7L-wEva2uNd4GI7utbr8wNytO6Fkcym0szmGkKJXJjEuIzH6x4P5dI61uPgbyy3XSEpvgkl1sNGK9LqpFA-GGFg6Lpa6Jt09MDV6XU3eY7ELYx7YzI1QYaNH9GkiinimoU8m9QRuw_NFsQLRGM6w2JIwVRf1Ne1R_7QK6fVIQAw8_k9tNwrSgYCYQEpftH4UebmNx0gmsiu-40A')
    }
    stages {
        stage('Continuous Integration') {
            steps {
                sh '''
                   cd dt-ejb
                   mvn clean install
                   cd ../Rest
                   mvn clean install
                   cd ../web
                   mvn clean install
                   cd ../daytrader-ee6
                   mvn clean verify –Pci-docker
                   cd ..
                   '''
             }
        }
        stage('Continuous Delivery') {
            steps {
                sh '''
                    echo "docker login to master.cfc"
                    docker login -u admin -p admin $ICP_MASTER_CFC
                    echo "docker tag"
                    docker tag dhvines/daytrader-ee6:0.0.1-SNAPSHOT $ICP_MASTER_CFC/default/daytrader-ee6
                    echo "docker push"
                    docker push $ICP_MASTER_CFC/default/daytrader-ee6
                    echo "kubectl login"
                    kubectl config set-cluster cfc --server=$ICP_MASTER_8001 --insecure-skip-tls-verify=true
                    kubectl config set-context cfc --cluster=cfc
                    kubectl config set-credentials user --token=$ICP_TOKEN
                    kubectl config set-context cfc --user=user --namespace=default
                    kubectl config use-context cfc
                    #!/bin/bash
                    echo "checking if wlp-daytrader-jenkins already exists"
                    if kubectl describe service wlp-daytrader-jenkins; then
                        echo "Service already exists, delete first"
                        kubectl delete service wlp-daytrader-jenkins
                    fi
                    if kubectl describe deployment wlp-daytrader-jenkins; then
                        echo "Application already exists, delete first"
                        kubectl delete deployment wlp-daytrader-jenkins
                    fi
                    echo "Create application"
                    kubectl create -f app.json
                    echo "Create service"
                    set +e
                    kubectl create -f service.json
                    echo "finished"
                '''
            }
        }
    }
}

Configure the Jenkins Pipeline for CI/CD

  1. In Jenkins, click the Jenkins menu in the upper-left corner to return to the home page.
  2. Click New Item.
  3. For the name the project, enter daytrader-ee6 ICp CICD.
  4. For Project Type, select Multibranch Pipeline, and click OK.
  5. On the Configuration page, under Branch Resources, select Add Source -> GitHub.
  6. For Credentials, select your GitHub credentials. If you need to add your GitHub credentials, click Add.
  7. In the Owner field, add your GitHub owner name, and for Repository, select your daytrader-ee6 project.
  8. Scroll down to the Build Configuration section, and change Script Path to JenkinsfileICp.

    Script Path for JenkinsfileICp

  9. Scroll down to the Scan Multibranch Pipeline Triggers section. By default, the pipeline is not triggered automatically because you only run this pipeline manually.
  10. Click Save. Jenkins now scans the repository to detect the current branches.
  11. After the scan is finished, from the Jenkins menu bar, click d aytrader-ee6 ICp CICD.
  12. When Jenkins lists the detected branches in the GitHub repository, click master.
  13. If Jenkins started a Build for you, stop the build now. You must provide the properties correctly to start the build. In the Build History section on the left side of the page, click the red X icon next to the build, which is #1 in this example. When prompted, click OK to cancel the build.

    Stop the build

  14. Click Build With Parameters to start a build. Change the properties as required, and then click Build.
  15. In the Build History section on the left side of the page, click the current build number, and select Console Output to view the build in action.

    Console Output

After the build is completed, the Daytrader3 application is deployed to IBM Cloud Private. The Jenkins CI/CD Pipeline is now configured to run when you manually trigger it.

Conclusion

Your application is ready for the final step in this article series, which is to refactor it to microservices. Later iterations of the pipelines that you created here might introduce the notion of branches. If they do, the Build automation stage will be triggered by changes to the development (dev) branch instead of the master branch. Similarly, the Continuous integration stage might be triggered when you merge your dev branch with an Integration test (IT) branch. Finally, you might have a General Availability (GA) branch. If you have a GA branch, merging the IT branch to the GA branch might trigger the Continuous delivery stage. You can add branches to the delivery pipeline by using various methods. For more information about branching strategies, see this article on Git workflows.