Testing and deployment are two integral elements of web development. Adding in automation, they become solutions commonly called “continuous integration” (CI) and “continuous deployment” (CD). 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.
Thus, you can imagine that Continuous Integration and Pull Requests are old friends for almost every development team. Thanks to them, we can improve the code stability and quality while collaborating with other developers in faster-release cycles. Above you can see the Pull Request lifecycle as a part of our vision about how CI & CD can be implemented.
Before we begin, you can reference our documentation for a complete “How-To” guide with step by step information for setting up a Continuous Integration environment. This also includes on how Jenkins reacts to changes in Bitbucket, not only for commits but also for Pull Requests.
Our objective is to share how to use ElasticBox, the Jenkins plugin, Bitbucket as SCM and Jenkins itself as one of the several possibilities you have to manage the Pull Request’s lifecycle. To better describe the process, below is a diagram of the workflow:
In our example, we are going to deploy a Tomcat server, and by using ElasticBox and the Jenkins plugin, you could deploy a complete application stack if you desire.
Assuming you already have a Bitbucket repository and a Jenkins instance (with all the required plugins) running, you simply need to integrate them and leverage them with ElasticBox to fully automate touchless deployments required by the testing environment.
There are several ways to integrate Bitbucket and Jenkins depending on the mechanism involved, polling or pushing, and the type of repository you are using, Stash or Bitbucket Server. For simplicity we chose the Bitbucket Pull Request Builder plugin and the Git plugin in this example. Consequently, in this case the Jenkins server will poll the Bitbucket repository constantly.
The Jenkins Job Configuration can be done following the steps below:
- Access the Bitbucket Repository (remember to add your credentials)
- In order to trigger the job, configure the Bitbucket Pull Request Builder plugin requirements
- Add a DeployBox build step in order to deploy the Tomcat server:
- Create a shell script build step for the source code previously downloaded from Bitbucket and deploy it in the Tomcat server.
Once the changes are pushed, you can create the Pull Request in Bitbucket. Just after the Pull request has been created, this is what you will see:
Please note that the Pull Request in Jenkins has not been built immediately (red circled status in the previous image above). After the cron interval you configured in the Jenkins Job Configuration section, you will see how a new build was triggered and executed:
The Console Log for this type of execution should be showing the following:
- The job is triggered thanks to the polling being executed by pull request builder Jenkins plugin.
- The job gets the code from the repo using Git Jenkins plugin.
- The job deploys the Tomcat instance using ElasticBox and its Jenkins plugin.
- Finally the job executes the build (all the Maven phases) and the war package is deployed in the chosen server using a shell script step build.
(Detailed screenshots are provided in the documentation site)
And as soon as the build ends you will see the result in Bitbucket:
The build was ok, notice the circled notification in the screenshot above. Also in the next image we see that our web application with the pull request changes is up and running in the Tomcat server.
By 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.
- Post services in Bitbucket (push based)
As seen above, POST service management is deprecated in favor of Webhooks 2.0. Please note that the Bitbucket Jenkins plugin only works for Bitbucket push events not for pull request events.
- Jenkins CI broker service (push based too)
Currently, Atlassian Support does not provide assistance for this configuration. In addition, as you will notice, they redirect users to Jenkins Bitbucket Plugin, but that plugin only works for Bitbucket push events, not for pull request events.
- With other combination of plugins you could manage the pull request lifecycle too. For example using these plugins (having Stash but not Bitbucket):
- Git Jenkins plugin
- Pre SCM Buildstep Jenkins plugin
- Stash Notifier Jenkins plugin
- Pull Request Notifier Stash plugin
You can see all details here.
Get a step closer to democratizing software automation configuration and infrastructure. Learn more about Jenkins and Bitbucket, and how they react to changes throughout the Pull Request lifecycle.