Bamboo 4.0 - interview with James Dumay
• Julian Simpson
Bamboo 4.0 is out today. I had a brief chat with James Dumay (@i386) from Atlassian, who is the Product Manager for Bamboo.
What's new with Bamboo?
The Bamboo team has been hard at work for the last few months rethinking and rebuilding the way developers use and interact with CI when a team uses branches. Many thought leaders have come to the conclusion that feature branching and continuous integration are ultimately incompatible because all branches cannot be tested easily. Bamboo 4 is all about proving this wrong.
For example, when a developer commits to a new branch, the developer must go to the CI server to clone and update the build configuration to take into account the new branch. This is needed to ensure commits to the branch are tested correctly by running the full test suite. This is a big problem because a developer has to remember to manually create a new build for their branch each time, as otherwise code does not get tested for large spans of time. And let's face it, we are a lazy bunch when it comes to processes.
Keeping the configuration between the main build and the branches synchronised is a lot of work and we end up with a maintenance headache.
Bamboo 4.0 solves all these problems by sharing build configuration between the main build and the branches. Working with branches and CI has never been faster and easier.
If you are using Git or Mercurial, Bamboo can automate even more for you. Bamboo will automatically setup a new build when a developer pushes a new branch to the repository and will also automatically clean up any branch build configurations that have been unused. This means that your CI server doesn't remain cluttered with dead branches (of course all of this is configurable and we never delete branches in your repository).
The other problem is that when we create the branch and manually setup a build for it, we are not sure whether the changes on the branch will integrate with the master branch until it's time to merge the branch into master (or another branch for that matter). If you don't run the full test suite before pushing your changes back to master, then you could be potentially slowing the whole team down by introducing bugs and failing tests.
For Git and Mercurial repositories, Bamboo will attempt to merge changes from (or to) the master branch then executes a build against the merged changes. If the build passes, the changes are optionally committed and pushed to either the branch or the master. That's fantastic for situations where you need to keep your branch updated with the latest changes from master or want to automatically push changes on the bug fix branch back onto master when the build passes.
We think we have really nailed it and we can't wait for developers to start working with branches and CI together the right way.
We're in an age where CI servers are all very similar, what makes Bamboo stand out?
Ecosystem
Firstly and foremostly, we truly believe Bamboo is the best CI server out there and it only gets better if your team is using JIRA, Fisheye and Bitbucket. Mention a JIRA issue in a commit message and Bamboo will automatically provide detailed information about that issue on the UI wherever the commit is displayed. If your repository is indexed in Fishseye, then looking at the commit details is only a single click away in Bamboo. As Atlassian builds and acquires more products, Bamboo will add integrations with them (so stay tuned!). We've already got a plugin that allows you to broadcast build notifications to the entire team using our cool new communication tool, HipChat.
Bottling best practices
One thing our team and I believe in strongly is that Bamboo should be flexible enough to work your way, not the way that ivory-tower droids think development should strictly work.
Our approach is to marry best practices with flexible features wherever possible to allow you to setup your CI server the way you want it. For example, Continuous Delivery influenced the design of the Stages feature heavily. Stages are the flux capacitor of Continuous Delivery - they not only make it possible, but make configuring it pretty painless. Stages give developers control over their workflow by allowing the steps in the build and deploy pipeline to be split into groups. A Stage can be automatically triggered when the build runs or be launched manually by pushing a button - whatever works better for the team.
The kicker is that Stages let you run a few steps sequentially, then run a few steps in parallel, then go back to sequential execution. For example, you can run compile, package and deploy steps in sequence, then run a several batches of tests in parallel, then switch back to running one step at a time as you deploy the package to a staging environment (only if, and only when , all your batches of tests finish successfully!). You could then have another stage that deploys into a production environment. Going back and forth like that is a huge pain to configrure with other CI servers as the configuration tends to be rather brittle. We have tried to make configuring deployment pipelines like this as easy as possible in Bamboo.
Extensibility and stability
Having a stable API is a must for anyone who wants to rely on plugins. In Bamboo 3.1, we introduced the concept of Tasks which represent user configurable steps of the build process. The Task API been stable for over four major releases, from Bamboo 3.1 all the way to Bamboo 4. Right now we are working with a host of commercial software tool vendors to integrate their tools as Tasks. They simply wouldn’t have had the confidence to try to do this without the stability or the simplicity that the Task API has to offer. That fact has really shined through with the amazing growth we have seen in the number of plugins available for Bamboo since Tasks were introduced.
Design
We believe that not only should tools make it easier todo your job but they should look, feel and behave great if you are going to use them day in and day out. No CI server is as easy to understand and work with as Bamboo. Every day, we think about how to make Bamboo's UI as clear and simple as possible so teams can find the information they need faster, and get back to the business of making awesome software.
24/7 Support
Bamboo support is 24/7 which is a rarity in our space. Our support team kick ass - plain n' simple. They go out of their way to help resolve issues when things go wrong and feed info directly back to the Bamboo dev team. If you contact support at Atlassian, you are going to get a fast response.
Analysis: Atlassian are raising the bar; taking things of clear value (auto merging of loony tunes features branches, etc.) and making the accessible. Not a bad strategy, and shows you that James has done his share of developer time.
Sponsor Danger: Atlassian sponsor this blog, and I am disclosing this interest.