Hi!  I’m writing this blog post because I’d like to share my thoughts and tricks about a few upcoming features in Bamboo 4.2. These thoughts will be from a developer perspective who works on Bamboo in a day-to-day basis. So, let’s get started.

Branches in the SCM

Some of you may already know that the Bamboo team uses Mercurial SCM for storing the source code. With the boom of DVCS in Atlassian we were encouraged to utilize more branches when developing Bamboo application. That’s nothing unusual, and I believe most of you – no matter if working in Hg or Git – have already experienced this. So since last year I’ve seen more and more “feature branches” in Bamboo repository, and for example if I run `hg branches` on the Bamboo repository now I’ll see something like this:

As you can see, we have a plenty of branches, and you can notice a few patterns in their names. Most noticeable is that some branches contain relevant Jira issue key incorporated in the branch name (i.e. “mchai-BDEV-474-aspectj”, “kbrazulewicz_BDEV-409“, “BAM-11296 change detection caching”).  That’s because it’s a branch was created for implementing a particular issue and it’s easier to find the relevant branch later if it has something common with the Jira issue. Another thing, but less noticeable, is that some branch names are prefixed with the developer initials – for example let’s examine “jb-BDEV-771”: “jb-” part comes after Jason Berry who is a Bamboo developer, while BDEV-771 is a ticket on our internal Jira tracker. Quite obvious, isn’t it? However, the trick with initial prefixes is that a developer working on multiple branches simultaneously can get back to them more easily – you don’t need to remember exactly what was the issue key is, you can just focus on the branches that start with your initials.  For example in the command-line terminal I can enter `hg up ps-` and hit ‘tab’ to display only the branches of which I’m the creator. Cool.

Branches As Seen in Bamboo

Since version 4.0 we can configure Bamboo to detect every Git & Hg branch and built it as a separate branch Plan. The resulting dashboard in Bamboo looks like this:

Now, here’s something neat in Bamboo 4.2: whenever it detects and creates a new branch, it will capture the issue key found in the branch name and link the Plan-branch with the Jira issue.  The title of the Jira issue then gets saved as the Plan-branch’s description (note that your Jira instance must be linked to Bamboo via Application Links, and have the Bamboo plugin installed – we’ll be releasing an updated version of it in concert with Bamboo 4.2). Why does it matter? Because, as seen in the above picture, one developer can have multiple branches opened.  And if he doesn’t leave enough information in the branch name he will have problems finding the relevant build in Bamboo. “Was it BDEV-555 or BDEV-542 that I wanted to check? Or maybe BDEV-526? Hell, so many numbers to remember… I better just go find some chocolate.” – that sort of troubles. Probably you will end up opening multiple Bamboo tabs in your web-browser for all the branches. That doesn’t need to happen anymore, because with version 4.2 you can hover your mouse over the Plan-branch to check the relevant issue summary (saved as the Plan-branch’s description), like this:

Or just look to the top of the page when viewing build results or configs for your Plan-branch:

So whenever browsing all the branches page in Bamboo one doesn’t need to worry about remembering what issue number was about what. He just needs to check the Plan-branch description. Hurray!

Branch Build Status… in Jira!

But do I actually need to browse Bamboo to see the status of my branches? Usually my daily work follows the pattern:

  1. Check the backlog (or the rapid board, or whatever is the actual list of “issues-to-be-implemented”).
  2. Pickup the most fun™ important issue, assign to it, start working.
  3. Create branch for that issue, commit, push.
  4. Wait for the review and for the green branch-build status. <– this step usually takes some time due to volume of all the CI tests, and because half of the Bamboo team is located in different time zone!
  5. While my branch is under review I repeat step (1). And when the review+build eventually passes, I go back to that branch and merge it to the default.
  6. Close the Jira issue.

You can see that I usually have multiple issues open (waiting for the reviewers across the ocean to respond). Furthermore, you can see that in the above process I usually spend some time in Jira (backlog, manipulating issue) and in Bamboo (to check corresponding branch build status). Good news: in Bamboo 4.2 the latter will become unnecessary. Why? Because we utilize “remote links” in Jira to display the latest branch build status directly in the Jira issue:

The icon indicates the status of the latest build for that branch. So if I broke some tests with my changes I’ll have here the red “Failed” icon, and if I do my work properly then I’ll see the green “Successful” icon. In the Jira issue itself. (!)  No more juggling with the Bamboo tabs in the web browser. And of course if I broke something I can easily navigate to the latest build of my branch directly from the Jira issue page! So since Bamboo 4.2 I don’t have browser tabs opened for every Bamboo branch build I’m interested in – I just have tabs for the Jira issues that I’m currently working on and haven’t finished yet. My computer desktop is much cleaner I’d say.

Seeing the Branch Status and Summary in bash

These changes altogether encourage using plain issue keys as a branch names when working on a new feature. The only problem is that when I use my command-line for interacting with my source repository I’m still left with clueless branch names like “BDEV-555”, “BAM-11551” and similar. I need to have a browser opened with all relevant Jira issues to have some context – like what is that issue about and what is the latest build status. Not very handy when I’m in the middle of branch switching using command-line interface (“hg up BDEV-555” -> check Jira issue in web browser -> no, that’s different issue I wanted -> “hg up BDEV-542” -> check Jira issue in web browser -> yes, that was it -> code code). Fortunately, after a bit of work I’ve hacked bash scripts to display issue summary and the latest build status directly in my bash prompt (branch_description.sh).

These scripts use Jira REST and Bamboo REST to fetch the relevant data and cache them in local .hg directory for a few minutes. So when I switch my working branch I have to wait additional 2-3 seconds, but then I have the issue context directly before my eyes, without the need to open any web browser. Furthermore, if I leave the office in hurry before my branch is built by Bamboo I can easily check the status the next morning – I just need to hit enter in my terminal:

Oops, seems I’ve some tests to fix! I gotta go!


Linking development branches and Jira issues using the issue key is great for your work day flow because you see the information you want no matter which application you’re in. Then combining the power of REST APIs with additional scripts I’m able now to name branches by the relevant issue key only, and perform the so-called “Issue Driven Development” in a daily manner – without the need to juggle all the Jira and Bamboo pages. Huh! Thanks for reading (smile).


Oh!  And Bamboo 4.2 comes out in a couple weeks, so I’ll make our marketing people happy by encouraging you to get started using Plan Branches now with Bamboo 4.1 if you haven’t already.


Story Branch Development Through the Eyes of a Bamboo Developer