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.

JiraStash-and-Bamboo-Integration.jpg

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:

Branchconfig.jpg

  • 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.

    Continuous Integration : Artifacts Storage
    if [ -d $BAMBOO_Artifact_Home_Directory/artifacts ]
    then
       if [ -d $BAMBOO_Artifact_Home_Directory/artifacts/${bamboo.shortPlanName} ]
       then
          echo "Directory exists for artifacts"
        else
           mkdir $BAMBOO_Artifact_Home_Directory/artifacts/${bamboo.shortPlanName}
          fi
    else
           mkdir $BAMBOO_Artifact_Home_Directory/artifacts
    fi
    rm -rf $BAMBOO_Artifact_Home_Directory/artifacts/${bamboo.shortPlanName}/
    find ${bamboo.build.working.directory} -name 
           
             -exec cp {} $BAMBOO_Artifact_Home_Directory/artifacts/${bamboo.shortPlanName} \;
           

    • The bamboo provides various environment variables that can be used in the custom scripts, we have used some of them in our script above, in order to store the artifacts into the directories representing their respective ‘branch plans/issue-key’ in the JIRA. The same would be used during the deployment.
    • The build status would be updated on the Stash(for the reviewers reference) and on the JIRA issue. As we have always made a point to include the JIRA issue-key in the every commit message.
    • The bamboo build plan can be optionally integrated with any test suite or JUnits test cases for automated testing (we would focus on this in our future blog ) of the granular development modules, after every successful build.

    Step 3: Configuration of Continuous Deployment from Bamboo

    So lets come down to the continuous deployment, since as per our solution, continuous deployment on the specific environment is done only after a successful code review for the changes committed.

    • Another build plan, deployment trigger plan is created. This plan is triggered by the JIRA workflow transition’s postfunction, once the review is approved on the Stash.Bamboo CLI is used in our case, that triggers this plan along with parameters being passed that are required for the deployment.
    • This trigger plan downloads the artifacts from the storage area corresponding to the JIRA issue and makes it available for the continuous deployment.The JIRA trigger also passes the parameters required for the deployment, like deployment environment details, credentials etc.. The previous blog , highlights the importance of Integrated Release Management approach as core platform for Devops Asset management project in the JIRA for the dynamic deployment environment changes for a Release.

    Artifacts into Deployment Trigger Plan
    cp-R $BAMBOO_Artifact_Home_Directory/artifacts/$bamboo_issue/
           
             ${bamboo. build.working.directory}/
           
  • The success of this plan, triggers the actual deployment plan. This trigger configuration is configured from the deployment plan of bamboo.
  • After the successful deployment, the same are updated on the corresponding JIRA issue using the JIRA Cli task from the bamboo deployment plan.
  • As all the details at the end of each activity on the bamboo CI and Stash are updated on JIRA, all the stakeholders are kept informed on the status of the development and release activity by making JIRA as a centralized tool (grabing the project management capabilities of JIRA ).

Final note on Using Atlassian tools for RM

As described above we can have both CI and CD maintained in a simplified and organised way by the DevOps Engineer with the use of integrated Atlassian tools. And all the stakeholders would be on the same page, as JIRA would be holding all the information of the complete development lifecycle like the status of development, latest successful build and the build number deployed all in the one development panel of the issue. With the automation across the tools, only JIRA would be used to perform all the tasks by DevOps, without going back and forth around the tools for any actions to be performed, like creation of the branch, triggering the build on bamboo and deployment.