Our previous blog,Integrated Release Management approach as core platform for Devops has given a clear view on the importance of integration and automation across build management tools for the DevOps. JIRA is used extensively as an issue tracking system, which has prompted a large switch over to GIT/Stash for version control system due to the ease of integration between the two. Despite the Atlassian connection between JIRA and Stash, Jenkins is still the tool most widely used for continuous integration(CI) and Continuous Delivery(CD). Integrating JIRA and Stash with Jenkins can play to the strengths of both for teams that prefer Jenkins in their Release Management solution.
Jenkins-JIRA and Jenkins-Stash Integration
Initially, Jenkins can be integrated with JIRA by installing the plugin “JIRA Plugin for Jenkins”. The next steps involve using application links with Oauth as the medium of authentication between the two. When Jenkins is integrated with JIRA, all the projects inside Jenkins will be visible in the ‘Jenkins Configuration’ window of the JIRA administrator. Both the ability to configure synchronization and to enable new projects created on Jenkins are available for the administrator of JIRA after the integration as well.
Meanwhile, the Stash repository can be directly configured from within Jenkins jobs. A Jenkins job can poll the code repository for the changes that trigger the build or for a web-hook from the Stash repository that can trigger the build. Since polling is not very efficient, the preferable method is the Stash web-hook. The web-hook is nothing but a post-commit script that triggers continuous integration from Stash. DevOps improves the efficiency of continuous integration using the appropriate triggering mechanism offered by Jenkins.
The below conceptual diagram shows the integration between the tools and description on the same.
Jenkins configured in JIRA after their integration would have all the projects listed with synchronized builds
across them. Any new project created in Jenkins would be enabled in JIRA and synchronized with their
corresponding issues. The sample configuration page is shown in the screenshot below.
Integrating JIRA, Stash, and Jenkins to build a platform for effective DevOps
Continuous Integration With Jenkins
When developers push code to Stash, the CI job is triggered in Jenkins (either by SCM polling or by customized web-hook). Since each repository has many branches, any changes on these branches need to be continuously integrated with a single CI job instead of one job/repository branch. However, as per our solution continuous deployment is not tied with a successful build, but with the state transition of the corresponding issue in JIRA. As such, the storage of these artifacts should be automated and placed in the directory to be used during the deployment/Delivery by referring to the appropriate branch. In order to link the commits and the builds to the issue in JIRA, the commit message should always start with an issue key. These need to be included in the pre-commit hook, so that any change that does not include the “issue-key” in its commit message is discarded.
The Jenkins job also needs to include a repository URL and corresponding credentials (which should be stored as username/password or ssh configured), build triggers (either poll 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 as per the solutions needs, the Post-Build actions like updating the JIRA issue, and finally, protocol for notifying Stash and archiving artifacts. Since the deployment is not coupled with the build job, the deployment task needs to be configured as a separate job. Therefore these artifacts should be stored into separate directories corresponding to the JIRA issue (Stash-branch name /JIRA issue-key as directory name) so 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. The code snippet for storing the artifacts under the directory with its name as Stash branch name as per our solution is mentioned below.
The JIRA url and access details are configured in the Jenkins configuration, are tested for connection and authentication, and are used for updating the JIRA issue. Stash is also updated according to the build success or failure for the corresponding commit. The Jenkins build also has the details on the revision numbers which triggered the build, and the changes made with respect to the previous successful build. The presence of the build status at the time of the commits also helps the reviewer in approving/declining the change. The build status can also be used to notify the required stakeholders through mail by configuring SMTP in the Jenkins main configurations.
Continuous Deployment with Jenkins
As per our solution, continuous deployment on the specific environment is done only after a successful code review for the changes committed. When the review is approved in Stash, automation triggers the corresponding JIRA issue to be transitioned to the next state. Meanwhile during the transition, the deployment is triggered from the postfunction automation using groovy scripts or third party plugins of JIRA. One such approach to trigger the deployment from the workflow transition is by groovy script, and preconfiguring the corresponding Jenkins job as parameterised build. The sample code snippet is as shown below.
JIRA of our solution also has the project in order to store the environment details. The issues from this project can be used in the development projects for assigning testing environments for deployment, so that when the deployment is triggered from the JIRA workflow postfunction, the deployment details are passed to the Jenkins as parameters. These details are used for deployment of the required build onto the mentioned environment. Once the deployment is done, JIRA is updated with the CI build deployed.
In the usual way of deployment through Jenkins, the deployment details are stored in the Jenkins global
configuration or the specific configuration, which means that any change in the deployment details would also mean changes in the configuration of the job. This issue is eliminated by storing the environment details in the JIRA maintained ‘Asset Management’ (created as per our solution) project. Anytime a person makes the required changes to the environment in JIRA, which would be used for the deployment, the deployment is triggered from JIRA as the build and deployment are done as a separate jobs. Artifacts are stored on the build server, and the deployment job picks the artifacts meant for the correct deployment. The parameters provided while triggering the deployment job include the ‘issue-key’, and the deployment automation will grab the artifacts from the build server to deploy them.
A bit of additional information on Jenkins: the permission model can be created for users based on the roles in the security configuration of Jenkins. A ‘View’ can be created in Jenkins for grouping the jobs that are alike or part of same project, so that managing Jenkins by DevOps is done in an organized way. Jenkins has huge number of plugins for building various kinds of projects (Java, ios, android, etc.), various different kinds of deployment (on cloud, private network) by Jenkins configuration.
By using the proper plugins and configuring them, DevOps has an easy way of handling the build and deployment during the entire release process. While some teams that use Stash and JIRA prefer to use Bamboo due to their desire to provide continuity in their toolchain, Jenkins is presently far and away the most popular CI/ CD tool on the market. Integration doesn’t have to be difficult, and allows users to create a hybrid toolchain that many teams have come to prefer over a strictly Atlassian or strictly Jenkins solution. Because integration is so vital to a successful build and release management process when using such a solution, it is important to get it done right the first time. With average DevOps salaries hovering around $60/ hr, with many paid far in excess of that figure, the cost of configuration pales in comparison to a problem, especially if that problem occurs during a critical phase in a product cycle. Consider reaching out to an expert that is certified in both Atlassian and Jenkins to speed the process along if you are having trouble.
