Knowledge Base  /  Cloud Application Manager  /  Integrating with Jenkins
Knowledge Base  /  Cloud Application Manager  /  Integrating with Jenkins

Setting Up CI/CD with Cloud Application Manager, Jenkins and Bitbucket

Article Code: kb/416

Setting Up CI/CD with Cloud Application Manager, Jenkins and Bitbucket

The Cloud Application Manager Jenkins plugin automates CI/CD on any cloud and SCM. In this article, we use Bitbucket as the SCM.

Note: To get started, you need a Jenkins server with Bitbucket and Cloud Application Manager plugins.

To add Cloud Application Manager build steps in Jenkins jobs, go to the job page. Under Build, click Add Build Step and select a Cloud Application Manager deploy, manage, or update step.

In this article:

  • Previous requirements
  • Setting up the continuous integration environment
  • Reacting to changes in Bitbucket
  • Pull Request lifecycle
  • Previous requirements

Previous requirements

  1. You will need a Bitbucket repository.

    Example: In this repo you can find a Java web application:


    The repo was cloned in the local environment:


  2. You will need a Jenkins instance up and running.
    In our case we are going to deploy the latest stable Jenkins version using a box created in Cloud Application Manager. We created this box for future use when we need to provision a Jenkins environment again. At this point, all we need to do is to deploy this box and a Jenkins master with all the plugin configurations will be setup within minutes.


  3. We will need an Apache Tomcat 8.5.

    In order to keep it simple we decided to create a tomcat box in Cloud Application Manager to deploy the apache tomcat server.


Setting up the continuous integration environment

The objective is to demonstrate how easy it is to set up a continuous integration environment using Jenkins, the Cloud Application Manager Jenkins plugin and Bitbucket as repository.

Below is a diagram of workflow and how all the components work together.


  1. Set up the Jenkins instance (in our case we will deploy the box we have created previously).

    • Deploy the box.


    • Choose the deployment policy box.


    • Deployed.
  2. Configure the Cloud Application Manager cloud in the Jenkins Manager section.


    • In the cloud section, we add the Cloud Application Manager cloud:


  3. Create a Jenkins job in order to see all the pieces working together.


  4. Now we are going to configure the job:


  5. In the Source Code Management section, we have to configure the Bitbucket repository (Git should be installed in the Jenkins node):


    In this case the url will be:
    Enter your credentials in order to access the repository.


  6. In the Build section we add a DeployBox build step in order to deploy our previously created Tomcat box.



    In the previous schema you saw that we selected the Tomcat box with its latest version. We also added the tag “tomcat” to that instance in order to easily locate them in our cloud. In this case, we have selected to deploy this box in the Google Compute Engine (GCE) using the deployment policy box below:


  7. Now, once we have configured the Tomcat box that will be deployed, we need to build the source code that we have downloaded previously from the Bitbucket repository. Using a free style Jenkins job and not a maven Jenkins job, we will have to create a shell script step builder:


    Apache Maven should be previously installed and added to the path in order to execute the order:

        mvn clean install

    As you might have noticed, the last command in the shell deploys the just war created package in Tomcat.

    curl -v -T ${artifact} 'http://manager:manager@'${tomcat_host}':'${tomcat_port}'/manager/text/deploy?path=/'${context_path}''
  8. Let’s see how it works:

    • The job gets the code from the repo:


    • In the next step the job deploys the tomcat box.


    • Now the job executes the build.



    • Notice that it finally deploys the war package in the Tomcat server.


    • And it works!!


  9. All the pieces working together.


  10. Tomcat deployed with Cloud Application Manager Jenkins plugin.


Reacting to changes in Bitbucket

In our previous case, we spent some time setting up our continuous integration environment. We’ve started using Jenkins, Bitbucket and the Cloud Application Manager Jenkins plugin, and so far, we’re pretty happy. The next goal for us is to set up a Bitbucket service hook to trigger our builds.


In the job that we created while setting up our continuous integration environment, we are going to enable notifications when a change is made in the Bitbucket repository. We do that in the Build trigger section in the configure job page.


We now have to make the proper changes in order to enable the hooks from the Bitbucket repository. Adding webhooks pointing to our Jenkins CI server.


We make a change in our source code (previously cloned from the repository) within a local environment by a new HTML paragraph tag.


Once the change (the feature) is done we make the commit in our local repository and the push is made into the remote Bitbucket repository.



After the push into the Bitbucket repository, the job is triggered.


We will confirm that the result is what we expected, the package was properly created and deployed into the Tomcat server.


We can see that our change is ready to be tested. And yes!!, our new paragraph is there.
See the hello world page served from Tomcat.


Just being aware of the push changes in your repo provides many management possibilities depending on the type of development workflow in your company. You have to decide what push hooks will trigger Jenkins jobs. Such scenarios as every push event being able to trigger a Jenkins job or pushing events specific activities in a specific branch truly depends on your development workflow, and can be customized based on your business . As you can imagine the push event is the simplest and yet, most detailed way that you can handle an event. For example take the following classic Git workflow below:


So, assuming that you are using a branch that serves as an integration branch for features (this is the purple branch in the above schema), it may be enough (from the Jenkins perspective) to be notified about the pushes in the integration branch. A Jenkins job would be triggered every time that a new commit is added to the integration branch. The job could also send an email to whoever you want to be notified of build result or other actions that the job is able to do. However, better integration models would be more effective if we could be made aware (in Jenkins) about the different phases of the Pull Request lifecycle. Lets now cover this process next.

Pull Request lifecycle

As you probably know, pull requests are a tool for developers to notify the rest of the team when a new feature is completed. This makes everyone aware that they need to revise the code before merging it from the feature branch into the master. So, being aware of every commit in the repo, as we did in the previous chapter, is cool, but if we’re able to build pull requests from Bitbucket and report the test results, that would be even better. Below you can see the Pull Request lifecycle as a part of our vision about how CI & CD can be implemented.


In the image below you can see the simplest implementation of the previous cycle which will be our working example that we’ll walk through in this setup.


There are several ways to achieve this type of integration, depending on the mechanism involved, whether it be polling or pushing, and the type of repository you are using, Stash or Bitbucket Server.

Feel free to review the wiki pages for the simplest approach for using these Jenkins plugins together:

In this case, our Jenkins server will poll the Bitbucket repository according to the time interval that we have chosen. We have created a Jenkins job to demonstrate how this method works which will configure the SCM as seen in the section below:


We also need to configure the part related to the Bitbucket Pull Request Builder in the “Build Triggers” section:


Once we have configured our plugins we will see the result from the Bitbucket perspective. So, every time we make a new feature in a new branch, we have created the “master_branch_feature_2” containing commit 1:


When we create the Pull Request in Bitbucket this is what we will see:


The commit inside:


Notice that the build was triggered because of commit 1.


The branch being checked out is the master_branch_feature_2.


And as soon as the build ends you will see the result in Bitbucket.


The build result notification:


For means of simplicity we decided to use the plugins combination that you saw above, but there are some other ways to integrate Bitbucket and Jenkins.

You can see all details here.

Contacting Cloud Application Manager Support

We’re sorry you’re having an issue in Cloud Application Manager. Please review the troubleshooting tips, or contact Cloud Application Manager support with details and screenshots where possible.

For issues related to API calls, send the request body along with details related to the issue.

In the case of a box error, share the box in the workspace that your organization and Cloud Application Manager can access and attach the logs.

  • Linux: SSH and locate the log at /var/log/elasticbox/elasticbox-agent.log
  • Windows: RDP into the instance to locate the log at /ProgramData/ElasticBox/Logs/elasticbox-agent.log