Sunday, September 16, 2007

Bamboo Disappointment

Being a big fan of Atlassian's Confluence and Jira, it was with much anticipation that installed Bamboo, the continuous integration (CI) engine they've released. Perhaps these high expectations led to my ultimate disappointment with Bamboo, but truly the features I've come to expect in a commercial CI product are nowhere to be found.

No concept of inherited project structure.
If you have 20 modules you would like to build, defining behavior and properties for each is a daunting task. QuickBuild and AntHillPro both allow for a hierarchal organization of modules, so that a child may inherit properties (like environmental variables, build targets, etc) of its parent. In Bamboo, when creating a "Plan", I can clone an existing module, but that's it. Should I have the need to change a property for all plans, I'll be forced to configure each through the web GUI. A tedious process -- even with Cruisecontrol I could search & replace config.xml in a text editor to make wholesale changes.

Alien nomenclature
In Bamboo, you have top-level "projects", and beneath them you have "plans", which represent the modules being built. I've never used the word "plan" before when describing a module's build, and frankly the limited options offered by Bamboo to govern build behavior makes it a dubious word choice.

No passing of properties
It is sometimes desirable to direct a CI engine to pass arbitrary properties to one's build process, and vice versa. I don't mean "static" environmental variables, rather I refer to dynamic properties like "version number". No such functionality is present in Bamboo. Luntbuild and Quickbuild both allow for this using OGNL expressions.

No concept of build promotion
Most commercial CI products have evolved to include "Application Lifecycle Management", so you may describe how a build can go from being development-status to gold. Implicit in this is a workflow allowing QA to promote and release builds. None of this is even hinted at in Bamboo -- it does not even tag your build.

Summary
Features that Bamboo stresses seem misplaced. You'll see much mention of its heralded "Build Telemetry", on the product's site. Through this feature, you can generate nice graphs and statistics about one's build. But honestly, I've regarded charts and graphs in CI engines as a feature present because they're easy to add. While its fun to see how often one's build has been broken, I've never seen a lasting need for such statistics.

These are merely the shortcomings I've experienced, but I'm sure there are others -- like remote builds (where the CI Engine is deployed to multiple servers) for which I've no immediate need, but will no doubt be experienced by others. Its hard to see what advantages Bamboo offers beyond a free product like Luntbuild besides a pleasing user interface. Indeed, Luntbuild's features like OGNL expressions and Eclipse plugin makes it, in my opinion, more feature-rich than Bamboo.

My favorite build server remains QuickBuild. It was with tremendous ease that I was able to control and manage many modules at once. To be fair, though, its been awhile since I've looked at AntHill Pro or TeamCity from JetBrains, both products that looked promising when I reviewed early versions.

1 comment:

Edwin said...

Hi Keith,

Thanks for checking out Bamboo and giving some feedback about our product! As always, we are continually trying to improve our product and appreciate your honest feedback. It's also great to hear the points you mention here are ones that we have given considerable thought internally, and I guess, validates that we are thinking on the right lines.

Just a few points with regards to some of the issues you mentioned:
- Hierarchical project structure - we have given some thought to this and found it potentially confusing and difficult to manage using hierarchical configuration structures in Bamboo. To this end, we are looking towards a bulk edit feature in Bamboo which allows you to concurrently modify many plans together.

- Nomenclature - this was one of the things which caused much internal debate here, as we struggled to find a term which was really "correct". As the uses for each "plan" can vary, we did not find the term "module" sufficient. At Atlassian, for example, we use Bamboo to build Confluence in a number of ways (e.g. functional tests on Tomcat with MySQL, functional tests with Resin and HSQL). Each was, in a way, the complete Confluence project using different configurations.

- Passing of properties - In Bamboo, we do have the capability to pass some properties to your build process via variables. This is extensible by a plugin framework which can leverage off these values as well. Is this the feature you are looking for?

- Build Telemetry - I would agree that the telemetry information Bamboo provides is not necessarily useful 100% of the time. However, it does provide valuable insight to explain project trends over time at a high level if applied appropriately. Furthermore, Bamboo plugins allows you to extend these statistics (e.g. coverage, find bugs). At Atlassian, for example, we use these statistics to help us discover performance issues during testing. Team leads also use these stats to monitor the health of our projects. Furthermore, we found that the value of the feature really picks up as the size of the build history grows and we have a bigger set data in the system

Having said all that, we really do appreciate you taking the effort to put down your feedback on our product! If you'd like to learn more about Bamboo and the improvements we are putting into our releases, you may want to keep an eye out on the Bamboo releases page.

Cheers,
Edwin (Atlassian)