I always mention the importance of and need for teams to automate and integrate their Version Control System (say Stash) with their Issue tracking system. I’ve also encouraged smart teams not to stop there, but to press onwards and integrate these two tools with a continuous integration tool like Bamboo/Jenkins to complete an end-to-end automation of “Release Management”. Dividends for these investments are high, because although a relatively new, a considerable amount of best practices for automation have been discovered in this space, like triggering the build in Bamboo/Jenkins with changes on the Stash repository and deploying it to the pre-defined environment. Still, this integration needs to be tightly coupled with the automation of a CI tool. Often times, the communication of both a successful build and deployment to the all the stakeholders is not concurrent, which usually creates confusion among the teams. There are two drawbacks to this. One, deployment is either completely manual, such as when every deployment is triggered manually. Two, deployment automated based on a successful build, meaning deployment is as at the same rate as the build.
In an organization where there are large sets of developers and testers, there is a specified set of environments for various types of testing(Unit, Functional, performance and other testing) for every release. In the case of failure in any of the environments, they are replaced with standby environments that have to be updated to all the concerned parties. Deployments need to be configured to be done onto the new environments, which, if you’ve been there you’ll know, is a terrible inconvenience for the team deploying the build as they have to reconfigure their deployment every-time there is a change in environment and corresponding access.
Atlassian’s JIRA is an efficient issue tracking tool, which when integrated with other Atlassian development tools like Stash and Bamboo, provides some out of the box functionality, like the creation of branches in Stash from JIRA, as well as providing availability of Stash commits in within the JIRA ticket corresponding to that issue. Due to these great features, instead of talking abstractly about generic tools, this article will focus on the Atlassian toolchain.
Traditional Way
The usual way of performing build and deployment is to treat them as consecutive tasks. This forces the deployment environments to be pre-decided and intact for a complete release, or worse, necessitates them to be reconfigured in the Continuous Integration tool before the deployment to account for changes. Either every change that triggers the build will be deployed to some configured environment, or the deployment has to be manually done by running deployment scripts. Both ways have their own pros and cons. The former approach provides no control over the deployment of the successful build and the latter one means extra time wasted in manually triggering the required deployment. Furthermore, if every commit ends with deployment on the specified branch, this would lock the deployment environment throughout the development phase, thus development in parallel with testing could never be a reality. The testing team always depends on the intermediate team to get the number of builds deployed and never knows about the latest build available for the environment. All the problems of the traditional build and deploy process can be solved with automating the Bamboo/Jenkins Continuous Integration tool in accordance with JIRA. Making the issue tracking tool a central element considerably reduces the communication time among the teams
involved in the release.
Controlled Automated Deployment
It is recommended that every change in the Stash branch/repository is built in the Continuous Integration tool, but deploying every successful build is not an efficient release management process. As already mentioned in our previous blog on “Auto branching and Auto Merging”, the review/pull request approval in the VCS can be aided by checking the build status in the VCS and using the approval therein to change the issue status in JIRA. The same can be extended to trigger the deployment of that approved build onto the required environment. This controls the deployment rate onto the environment as well as removes manual triggering from the deployment, thus answering both the issues of deployment highlighted earlier.
The above approach helps make deployment a controlled process, but nevertheless leaves instances where changes to the deployment environment requires reconfiguration of the deployment procedure. This too can be automated, namely by storing the deployment environment details in the issue tracking system and passing those details to deployment as parameters which would eliminate the burden of maintaining environment details by the developer or the deployment team. Any dynamic change in the deployment environments are thus taken care at the issue tracking level. In addition to this, if the deployment fails or the deployment was not proper even though the deployment was successful, the re-deployment of the build can be automated from the issue tracking system at the click of a button. This can prove very useful in many cases, such as where the deployment environment was not readily set for the deployment, either in terms of connectivity or any undesirable configuration changes on the environment.
Another aspect of deployment is selective deployment in which configuration is done to enable parallel deployment on more than one environment. It is not always necessary that all the environments needs to be deployed with the latest build, and in some cases, it is even counter productive. Based on the business or testing requirement, it can be expected that the deployment will be performed only on the specific environments. As with everything else, this can be automated in the issue tracking system, which can take its cue from the environments to be deployed as input. This automatically triggers the deployment to be done only on the required environments, which also addresses the requirement of re-deployments on the specific environment with the latest build for specific fixes done corresponding to the bugs raised during testing.
For example, a project ‘Asset Management’ can be created in the JIRA for the storage of the environment details ( host-name , IP address, port number, credentials and other info required for the deployments) in the form of issues. During the selection of environments for deployment in the JIRA issue, the ticket within the ‘Asset Management’ project is picked up from the issue list. Thus during the deployment trigger from JIRA, the only input would be the name of the environment that needs to be deployed, all the details would be passed to the deploy plan of Bamboo/Jenkins without any manual intervention. Even in case of change in the environment details, the only place we need to update is the corresponding issue created for the environment. This would eliminate any configuration changes in Bamboo/Jenkins.
Since many developers work on the same code repository at the same time, many builds are triggered at the same time, so deploying the right build from Bamboo/Jenkins into the required environment is a challenge, as the successful build itself does not trigger the deployment in our solution. So automation is also applied to the storage of artifacts for the build done for the particular branch of Stash/VCS corresponding to the specific issue in JIRA. Also as and when the issue is transitioned for deployment, the deployment is triggered for the corresponding build. The latest build deployed is updated on the JIRA issue only if the deployment is successful. This is useful in case there are any defects or failure in the deployment and needs to be re-deployed.
Integrated Status In Issue Tracking System
It is generally recognized that ideally all stakeholders are kept on the same page with respect to the release progress and issue progress. So it is important that everyone is well informed about the progress with one centralized tool, which is the issue tracking system. The consolidated summary/ current status of the issue
should describe the information of all the integrated systems (JIRA , Stash and Bamboo/Jenkins along with the deployment details). The information should be about the branch name created for the issue, number of commits and its details, pull requests and merge information from the Stash and the latest successful build available and the build number deployed on the various environments. The latest build details would definitely help the testing team to check on the latest builds available for the deployment/testing.
This complete end-to-end integration of the Atlassian tools (and Jenkins) with automation takes the release management process to new levels. The normally difficult path to a successful release can now be handled in a very eased way. Since release plays an important event for the enterprises in the IT world, keeping tabs on everything and maintaining accuracy within the proposed time is not just recommended but is essential. In forth coming entries, we shall see the technicalities involved in the integration and automation of JIRA, Stash and Bamboo/Jenkins based on Addteq’s release management solution.
