This is starting to become a crowded field, with open-source offerings such as Hudson, BuildBot, Continuum, CruiseControl, etc., and commercial systems such as Atlassian's Bamboo. TeamCity has been around for a while, and their offering is both low cost and powerful, and the JetBrains team have a reputation as providers of solid tools.
Among the things I like about the latest TeamCity software are the integration with Amazon's EC2 cloud computing infrastructure, since it makes no sense to build your own machine farm in this day and age, and the Java API for extensibility, since no system like this is ever deployed without a certain amount of customization.
Among the things I don't like about TeamCity are their lack of built-in Git support, and their "pre-tested commit" feature.
The whole pre-tested commit thing is a bit of philosophy. It's extremely seductive, and I can completely understand why people think they want it. But you don't want it, really. Laura Wingerd does a great job of explaining why in her book on Perforce, which I don't happen to have handy or I'd give you the quote verbatim.
But the nub of it is that you want to remove barriers for commit, not add them. Your overall philosphy should be:
- Make building and testing easy
- Make commit easy and encourage it
- Depend on your version control system and your build tracking system to help you monitor and understand test failures and regressions, not to try to prevent them.
There are enough barriers to commit as it is; any continuous integration system should have as its first and most important requirement: make it easy to Check In Early, Check In Often.
At work, we're still fairly happy with our home-grown continuous integration system (the Build Farm), but I can see the writing on the wall: between turnkey continuous integration systems, and cloud computing, the build-and-test experience of the typical commercial software product development staff in 2010 is going to be far different than it was 5-10 years ago.
GIT support is already there, in TeamCity 5.0, as for lowering barriers for commit to repository - this is questionable at least. Are you going to say that code review is bad practice too?
ReplyDeletePersonally, I think commit should not completely break the build (and pre-tested commit is the way to achieve it), otherwise other team members will be affected. I do not think they will be glad to see such a commit, because most likely they wanted to see results of their own changes, but instead of that they'll have to wait till the build is fixed. Then, if build will be fixed some tests may start to fail and it will be harder to discover which changes broke these tests, and so on.
So you can encourage developers to commit often, but chances are this approach won't work well in relatively large teams.