Our previous blog, Integrated Release Management approach as core platform for Devops emphasizes on Integrated Release Management approach as core platform for Devops the importance of integration and automation across build management tools for the DevOps. Bamboo is used as a CI tool by various teams that use Atlassian’s stash and JIRA for continuity in the toolchain, because Atlassian tools have very good coupling between them when integrated among themselves. The integration is done using applications links, while the authentication between them is done either by Oauth or trusted applications or basic access by DevOps. So, here we shall go through how automation across these tools along with the integration is done, which best suits to our RM solution, that has been described in our previous blogs. In the current context, we shall go through Continuous Integration(CI) and deployment done using JIRA, Stash and Bamboo. Before diving into the technicalities, let me recap the high level terminologies, CI main objective is to integrate development changes early and discover issues earlier in the cycle. CD is primarily for early deployment for testing and continuous Deployment of Pre-tested code onto the Production.
Before going into the configuration of the bamboo build, let me describe briefly the structure of bamboo. Bamboo is divided in build projects and deployment projects. A deployment project can use one or more build projects to capture the artifacts for deployment. And a build project has a single plan in default, and all the plans here are intended to build the code/ any build/environment related tasks for various environments. A bamboo plan has a single default stage, and all the stages created are executed sequentially, with the jobs underneath executed in parallel, whereas the tasks that are present in the jobs are triggered sequentially. So based on the requirement of the project, complete build plan can be broken into stages and so on… There are many inbuilt tasks bundled with the bamboo like, code checkout, tomcat start/stop and many more which are self-explanatory, that help the DevOps in the easy and accurate configuration of the build and deployment activities.
This integration is being done towards our objective of continuous integration and deployment onto the required environments. These Integration and/or Deployment could get triggered on either of cases (1) Checkin of code, (2) On scheduled Time (Nightly builds) (3) On manual trigger. There are many use cases in Software Development Lifecycle where CI & CD becomes lot more relevant on manual trigger e.g. we don’t want to disturb progress by deploying a new build on server while someone is testing previous build or deployment on some environments is more regulated, simple clean project management communication protocols within the organization to not disturb the work in progress environments etc.
Let me explain the details on Integration & configuration in the below steps.
Step 1: JIRA-Bamboo-Stash Integration
It is recommended to use application links across all the Atlassian applications using any of the trusted authenticated means. Stash when integrated with Bamboo, will make all the stash repositories available to the bamboo plans, which are referred in the bamboo as ‘Linked Repositories’. The CI build status would be available on the stash branch for review(success/failure). The issue-key of the JIRA has to be present in the commit message of the stash, so that all the 3 tools are properly integrated and the details are available on JIRA. Similarly with JIRA integrated with Bamboo, we would have the bamboo build and deployment details available on the corresponding JIRA issue. JIRA when integrated with the stash can create the branches in the stash repository from the JIRA issue itself, also the development panel of JIRA displays the stash information related to the commits, pull requests and their status. Hence JIRA would bring all the information related to stash(development) and bamboo(continuous integration and deployment) on a single page.
The simple logical way for describing the integration between the above mentioned Atlassian tools can be highlighted by the below diagram.
Jira-Stash Communication
- JIRA communicates with Stash for the creation of a branch on the respective repository for the development, pull request creation for review and merging to its parent/default branch.
- Stash inturn communicates with JIRA for updating the branches and commits details, and transition of the issue, once the pull request is approved.
Jira-Bamboo Communication
- In case of Deployment triggered from JIRA Transition, JIRA passes on the deployment details to bamboo as it triggers the deployment.
- Bamboo reports JIRA about the build status and the latest successful build available for that issue and the build number deployed on the various environments.
Stash-Bamboo Communication
- Stash makes its repositories available for the bamboo to be linked in its build/deployment plan. And triggers the build in bamboo as and when changes are pushed onto the linked repositories.
- Bamboo conveys the build result for the commit to the Stash, which is available for the review to decide on the approval of the pull request.
Step 2: Configuration of Continuous Integration from Bamboo
The continuous integration can be better described by the following steps along with the screenshot of plan configuration:
- Two build plans are created on Bamboo, one for the continuous integration(we shall refer this as build plan) and another for the continuous deployment(we shall refer this as Deployment trigger plan). There are two plans in here, because the plan branches created dynamically cannot be configured for the deployment in Bamboo.
- The bamboo build plan is bind to a particular stash repository(Linked Repositories) for continuous integration. Tab- Repositories in screenshot
- This bamboo build plan can be configured to create a new child plan for every new branch created on the Stash repository linked to this plan or only the specific branches created based on the reg-ex of the stash branch-name. So that Bamboo can detect the new branch created on the stash (DevOps can easily configure the branch detection time ) and build it. Tab – Branches in screenshot
- The CI is configured to build for any changes on the repository. So, when developers push the code to existing/new branch, the corresponding build plan is triggered in the Bamboo either by Bamboo polling the repository or the web-hook from Stash. As polling is not an efficient way for an enterprise level with many bamboo plans, web-hooks are preferred. The web-hook are nothing but a postcommit script that triggers continuous integration from Stash. Tab – Triggers in screenshot
- And the artifacts are stored in the corresponding directories identified by the ‘plan branchname/JIRA issue-key’ . The artifacts can be configured to share across other build and deployment plans, you may refer http://blogs.atlassian.com/2013/10/sharing-artifacts-between-plans-and-other-best practices for the same. Since in our context, we need to share the artifacts from a plan branch ,we practices/ need to store them and then share it, the storage of build artifacts is similar to the one we highlighted in the Jenkins blog. The code snippet for the same is mentioned below for reference.
