About once a day, I wish I could go back and ask a question differently or pursue an opportunity that has passed me by. Oh, to hop in a DeLorian and try the deli’s special of the day instead of ordering my usual ol’ turkey ruben!
It was in that spirit that Bamboo satisfied a popular feature request to build from an arbitrary revision number – a way to travel back in time and isolate a particular changeset. And we wasted no time taking advantage of it ourselves. Here’s how:
What Makes Time Travel Possible
Any build plan in Bamboo can be kicked off manually. When doing so, you have the option to make one-off customizations to the configs. Just choose “Run Customized…” from the Run menu. Pretty simple stuff. So let’s skip right to the good part.
Releasing Bamboo OnDemand from a Known-Good Revision
As our OnDemand subscribers know, we release new features and fixes into OnDemand roughly every two weeks. And we put new builds on the QA and Staging environments much more frequently. During the last round of updates to Bamboo OnDemand, the dev team committed changes and triggered builds several times a day. But, as you might guess, not every build passed all the unit and functional tests.
When it was time to put a new build up, the dev team could run the release build from the last known-good revision number instead of waiting for a new passing build. That way, they could give QA something new to work with at a moment’s notice – something they knew had at least passed the unit and functional tests – or run the production release plan from a revision that has been fully vetted. This also gives developers more latitude to try new things. If their cool new idea introduces failures, no worries: they can travel back in time and create a build based on a previous revision.
Compatibility Testing for Fisheye
Though humble and uber-nerdy, Fisheye is one of Atlassian’s most popular products. And it has to work with loads of different version control systems – not to mention multiple versions of those version control systems. So when a compatibility bug between Fisheye and Mercurial 2.3 was discovered, the dev team needed to fix it, like, yesterday. More importantly, they needed a way to ensure future compatibility bugs are caught immediately.
They set up a matrix build that tests Fisheye against all supported versions of Mercurial. Then the team needed to ensure that it was set up properly. So they ran it against a revision from before the compatibility fix was implemented. If tests against Mercurial 2.3 failed, then they’d know the project’s Ant targets and the matrix build were configured correctly.
Sure enough: build failed against the pre-fix revision, while builds against post-fix revisions passed. The system works!
Without the ability to time-travel through their code base, the Fisheye team would have been left with only an it-should-catch-future-compatibility-bugs level of assurance. And let’s face it: that’s not the way to sleep better at night.
Conducting Code Reviews
“Does it work? Did it break anything?” Those are questions so implicit in a code review, you don’t even speak them out loud. And you don’t have to. Run a build against the revision under review (or most recent revision, if several are involved) and let the test results tell the story.
That goes for changes made at the behest of your code reviewer, too. Like this build, kicked off by Bamboo’s dev lead to test an additional change made after a review of his updates to the dashboard filter. And good thing he checked, from the looks of that test failure.
Roads? Where We’re Going, We Don’t Need Roads
These are just three every-day examples of how the flux capacitor in our build system makes life a little easier for Atlassian’s developers and build engineers. Upgrade to Bamboo 4.3 and try it for yourself – it’ll work with any supported version control system.
To paraphrase the venerable Dr. Emmett Brown, “If my calculations are correct, when this baby hits 88 miles per hour, you’re going to see some serious Git.”