JIRA is used as an issue tracking system. It has prompted a large switch over to GIT/Bitbucket for version control systems due to the ease of integration between the two. In spite of the Atlassian connection between JIRA and Bitbucket, Jenkins is still the most widely used tool for continuous integration (CI) and Continuous Delivery (CD). Integrating JIRA and Bitbucket with Jenkins can be beneficial for both for teams that prefer Jenkins in their Release Management Solution.
Jenkins-JIRA and Jenkins-Bitbucket Integration
To integrate Jenkins with JIRA, we need to install the plugin “JIRA Plugin for Jenkins”. Next, we need to use application links with Oauth which acts as the medium of authentication between the two. After the integration of Jenkins with JIRA, all the projects under Jenkins will be visible in the ‘Jenkins Configuration’ window of the JIRA administrator. The ability to configure synchronization as well as enable new projects under Jenkins are available for the administrator of JIRA after the integration.
The Bitbucket repository can be configured directly from within Jenkins jobs. A Jenkins job can pull the code repository for the changes that trigger the build or for a web-hook from the Bitbucket repository that can trigger the build. Since pulling is not very efficient, the preferable method is the Bitbucket web-hook. The web-hook is a post-commit script that triggers continuous integration from Bitbucket. DevOps enhances the efficiency of continuous integration using the appropriate triggering mechanism provided by Jenkins.
The diagram given below shows the integration between the tools and description on the same.
Following their integration, Jenkins configured in JIRA would have all the projects specified with synchronized builds across them. Every new project that is created in Jenkins would be enabled in JIRA and synchronized with the issues associated with it. The image below displays a sample configuration page.“
Integrating JIRA, Bitbucket, and Jenkins to build a platform for effective DevOps:
Continuous Integration With Jenkins
The CI job is triggered in Jenkins (either by SCM pulling or by customized web-hook) when developers push code to Bitbucket. Because there are numerous branches in each repository, any changes made to any one of these branches need to be continuously integrated with a single CI job instead of one job/repository branch. However, according to our solution, continuous deployment is not related to a successful build, but with the state transition of the corresponding JIRA issue. In light of this, it is recommended that the storage of these artifacts be automated and added to the directory to be used during the deployment or delivery by referring to the relevant branch. The commit message should always begin with an issue key in order to link the commits and the builds to the issue in JIRA. These must be incorporated in the pre-commit hook, so that any update whose commit message does not contain the “issue-key” is discarded.
Additionally, the Jenkins job needs to include a repository URL and corresponding credentials. This should be saved as username/password or ssh configured. It requires build triggers (either pull the SCM system or trigger builds remotely by using webhooks/scripts), an invocation of the build tool (Ant/Maven or any other build tool), and some build script for storing of artifacts according to the solutions needs, the Post-Build actions like updating the JIRA issue, and finally, protocol for notifying Bitbucket and archiving artifacts. The deployment task needs to be configured as a separate job because the deployment is not connected with the build job.
Hence, these artifacts should be stored into separate directories corresponding to the JIRA issue (Bitbucket-branch name /JIRA issue-key as directory name). This means that during deployment, the artifacts from CI corresponding to the issue-key of the issue triggering the deployment are deployed onto the required specific environment. According to our solution, the code snippet for storing the artifacts under the directory with its name as Bitbucket branch name is given below:
The Jenkins configuration includes JIRA url and access information, used for updating the JIRA issue after testing for connection and authentication. According to the build success or failure for the corresponding commit, Bitbucket is also updated. The Jenkins build has the detailed information on the revision numbers which initiated the build, and the modifications made since the last successful build. The reviewer decision to approve or decline the change is aided by the presence of the build status at the time of the commits. By configuring SMTP in the Jenkins main configurations, the build status can also be used to notify the necessary stakeholders.
Continuous Deployment with Jenkins
According to our approach, continuous deployment on the specific environment is performed only after a successful code review for the changes committed. When the review is approved in Bitbucket, automation triggers the corresponding JIRA issue to be transitioned to the next state. During the transition,the deployment is initiated from the postfunction automation utilizing groovy scripts or third-party plugins of JIRA. An approach to trigger the deployment from the workflow transition is by groovy script, and preconfiguring the corresponding Jenkins job as parameterised build. The example code snippet is displayed as follows.
Our JIRA solution offers the project in order to store the environment information. The problems faced in this project can be helpful in the development projects for assigning testing environments for deployment. Hence, the deployment details are passed to the Jenkins as parameters when the deployment is initiated from the JIRA workflow postfunction. These details are utilized to deploy the required build onto the mentioned environment. Once the deployment is completed, JIRA is updated with the CI build deployed.
Jenkins typically stores the deployment details in either the global configuration or the particular configuration. This signifies that any modification in the deployment details would also mean modifications in the configuration of the job. This problem is resolved by storing the environment details in the JIRA maintained ‘Asset Management’ project. This is created as per our solution. Whenever someone makes the necessary changes to the environment in JIRA, which would be used for the deployment, the deployment is initiated from JIRA. The build and deployment are performed as a different job. The build server stores the artifacts and the deployment job selects the one meant for the correct deployment. The parameters provided while initiating the deployment job include the ‘issue-key’. The deployment automation will get the artifacts from the build server to deploy them.
Some additional information on Jenkins: Based on the roles in the security configuration of Jenkins, the permission model can be created for users. A ‘View’ can be created in Jenkins for grouping the jobs that are the same or part of the same project. This allows managing Jenkins by DevOps in an organized way. Jenkins has a large number of plugins for building various kinds of projects such as Java, ios, android, etc. and various kinds of deployment including on cloud, private network, etc. by Jenkins configuration.
DevOps has an easy way of handling the build and deployment during the entire release process by using the proper plugins and configuring them. While some teams that use JIRA and Bitbucket prefer to use Bamboo as it provides continuity in their toolchain, Jenkins is currently the most popular CI/CD tool in the market.
Integration doesn’t have to be difficult. It must allow users to create a hybrid toolchain that many teams nowadays prefer over a strictly Atlassian or strictly Jenkins solution. Since integration is important to a successful build and release management process when using such a solution, it is crucial to get it done right the first time. The average DevOps salaries offered is around $60/ hr. As many are being paid far in excess of that figure, the cost of configuration pales in comparison to a problem. If that problem occurs during a critical phase in a product cycle, this problem is even more persistent. Companies must consider reaching out to an expert certified in both Jenkins and Atlassian to speed the process along if they are facing any issue.
