Thoughtworks has finally released a successor to their venerable Cruise Control – Cruise build server. The UI certainly looks nice and it seems quite flexible. There is even a free version (which is limited to two computers), which is great.
What is not clear though is how this product is different from AntHill, Buildforge, Bamboo, TeamCity, Gauntlet and the likes. The field is certainly becoming crowded – and I haven’t even mentioned numerous open-source contenders. All these products seem to be doing the same thing – organizing your build scripts, interfacing with version control, running builds on a distributed “build server farm”, collecting statistics, publishing reports and providing UI for all these functions.
All these features are important and useful. Ironically, however, what build servers don’t do is automatically building or deploying your software. You still have to write Ant or Maven scripts, define and manage configuration parameters (using properties, XML, environment variables), deal with different environments (if I’m not mistaken, AntHill is the only product that has an explicit concept of an environment). For a complex project this could be a lot of work. Granted, every project is unique (if not, just use the default Maven configuration and you’re done), so this could be a tough nut to crack. It should however be possible for a build server to have enough intelligence to infer how to build a project directly from the code base.
I agree. Whilst a number of the build schedulers provide excellent features ( we use Hudson ) the ‘elephant in the room’ is that, for complex builds, you still potentially have to spend an inordinate amount of time constructing your actual ALM logic/workflow using Ant, Maven, Gant etc to perform ci builds, deployments & releases.
If you don’t undertake this activity then all the snazzy features of your build server are pretty redundant. They don’t usually mention that in the brochure ;-).
Alexander,
It looks like Parabuild http://www.viewtier.com/products/parabuild.htm is missing from your list.
As for the automated deployment, the process is usually more complex than a simple file copy or scp. So, sooner or later you end-up with conditional, possibly stateful logic. This leads to the need for having a scripting language to handle such logic. Such scripting languages already exist: Ant, Maven, Perl, shell etc.
That’s why for a build server it is natural to delegate the actual handling of the deployment to the script. Another thing is that a reliable release system should be able to support running the full build-test-deploy cycle outside of the build server. Your scripts do this.
Yet, systems like Parabuild facilitate automated deployment by providing a means to pass to the script run-time information about deployment, such as a name of the deployment target or a request to perform deployment. Here is the example how automated deployment works when a build is deployed to production: http://www.viewtier.com/support/demo/starting_release_build_for_parabuild_flash.htm