If you’re a Bamboo OnDemand subscriber, you could be forgiven for feeling a stab of jealousy every time a new batch of awesome features comes out for the on-premises Bamboo offering. ”When, oh when, will it be my turn?”, you pined. Well, if you logged into your Bamboo OnDemand instance this morning, you already know that the wait is over. Bamboo OnDemand is now roughly on par with Bamboo 4.1. ”Roughly”, because there are still a few differences such as not being able to install plugins or use commercial version control systems.
The collection of features now available in Bamboo OnDemand is large enough to fill a book (regular readers know I’m not one for brevity!). My strategy here today is to call out the biggest n’ bestest of ‘em, and point you to resources that’ll take you deeper in. So bookmark this page. Reference it. Love it. Repeat.
Better AMI Support
You’ll need to update custom any custom AMIs used by your build agents to make them compatible with today’s upgrade, but going forward this won’t be necessary. In addition, BoD now offers a stock image for building on Windows as well as support for EC2 spot instances.
Read more about AMI & Agent Support here: Atlassian OnDemand Release Notes – July 2012
DVCS & External Repo Support
The people have clamoured for it, and so the people shall have it! BoD can pull code from external Git and Mercurial repos hosted on Bitbucket, GitHub or on your own network. That goes for SVN repos on your own network, too. Using Git submodules? No problem. Want to pull code from a hosted SVN repo and a Bitbucket Mercurial repo into the same build? Done.
Read more about DVCS & multiple repo support here: What’s New in Bamboo 3.3
All your builders and post actions are belong to
us Tasks. Tasks are the granular steps that make up your Plan: checkout source code, call MSBuild, execute a script… etc. Your existing builders were converted to Tasks as part of the BoD upgrade, and we think you’ll find it to be a great usability improvement.
Read more about Tasks here: Configuring Tasks
Many users’ workflows require a set of requests and approvals for deploying code to an environment. And many many users would like to compile, test and deploy to a QA env with each commit –but deploy to production much less frequently. Manual stages let you construct a single pipeline, and add “gates” or “valves” to satisfy those use cases. You’re welcome.
Read more about Manual Stages (and other cool features) here: Bamboo 3.2 Release Notes
For a couple of years, the developer community has been complaining that using short-lived branches to build new features simply doesn’t play nicely with continuous integration. We’ve taken a big step toward proving them wrong. As soon as Bamboo knows there’s a new branch in your repo, it will clone any associated Plans and point them at the new branch. Branches are automatically discovered in Git & Mercurial repos, with auto-discovery for SVN coming soon. Très facile!
Because automatic branch discovery wasn’t enough. We wanted more! With each commit to a branch, BoD can now grab code from a second branch, merge the two, run your Plan against the merged code, and if successful, push the merged code to either branch. Great for ensuring longer-lived branches don’t drift to far from the main line, or for two developers collaborating on a feature using their own feature branches.
Read more about Automatic Merging here: Using Automatic Merges
When I was a test engineer, I would’ve killed for this. But you don’t have to! No more commenting out tests or dorking around with your suite.xml file. Just click a button to neutralize a busted test. It’ll still get run so you can see when it’s fixed, and you’ll see your count of quarantined tests on each build result summary so you don’t loose track of them.
Read more about test quarantine here: Putting Tests in Quarantine with Bamboo 4 (Yes, the zombie apocalypse has indeed arrived.)
BoD has issues. And how! Forget all that inefficient context switching, and create Jira issues from any build results page in Bamboo.
Read more about Jira Issues here: Top 5 Reasons Creating Jira Issues from Bamboo Makes Your Team Awesome-r
Broken Build Tracking
Team leads and scrum masters have better things to do than hound people to fix the build. With broken build tracking you can assign one person to be the default owner of broken builds for each Plan, or have responsibility assigned to users who made changes since the last passing build. Bamboo will nag them on your behalf until the build is green again.
Read more about Broken Build Tracking here: Bamboo 4.1 Announcement Blog
Failed Stage Do-Overs
Everyone needs a do-over sometimes. Maybe a build config needed tweaking. Maybe your QA environment down just as you were deploying to it. Re-running only the Stage that failed can save you a whole lot of time. And time is money, so… yeah.
Read more about Failed Stage Do-Overs here: Bamboo 3.2 Release Notes
Bamboo OnDemand is now resting on a more stable platform than before, so expect fewer stability hiccups going forward. We’ve also made custom AMIs for your build agents easier (even updated the templates, so you might not need to customize at all!), and made Windows images available by default. Très facile (redux).
But it’s also the end of an era. This is the last announcement I intend to write about BoD upgrades. Why? Because they simply won’t be a big deal anymore. We’ve retro-fitted our upgrade process such that BoD will be upgraded with new versions of Bamboo at the same time, possibly even before, those versions are available for installation behind your firewall. This is one “good bye” I think we’re all happy about!