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.
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.