I’m kinda the “tools guy” where I work. My default reaction to needing to figure out how to do something is googling to see whether someone else has done it already, and, better, created a tool to do it. Sometimes before I’ve actually tried doing it myself to see where the pain is, but not always…

Anyway, I’ve always been the one that ends up looking after the CI process. We had CruiseControl.NET for our legacy products, running an msbuild project. With our grand rebuild starting, I wanted to use something else (CC is fine, and open-source, but doesn’t seem as actively developed as it used to be, and also had a problem (more related to our environmental choices than itself) where it didn’t consider changes in svn:externals as trigger-worthy). I tried out Cruise from Thoughtworks Studios - that has a really nice chain-of-responsibility paradigm going on, where each build is considered to be a pipeline of stages, and a stage can contain 1+ jobs. Stages in a pipeline are sequential - the next stage cannot start until all jobs in the current one have succeeded. Jobs are parallelisable; given enough available build-agents, all jobs in a stage can be processing in parallel. It’s configurable via XML, but it’s clean, easy, documented XML, so OK. It’s actively developed. It’s free for use with up to 2 build-agents.

However, it’s also really really new, only just v1.1, and although not noticeably broken in any places (and I notice things like that!), it just doesn’t have as many features as Jetbrains’ TeamCity does. TC v4 just came out (actually, v4.0.1 came out today, too), and, well… It does a lot more, out-of-the-box. It also allows use with 3 build-agents for free, and has been battle-tested for longer. Lastly, if I may be allowed a moment of crudity, Jetbrains typically ** gold. I love ReSharper; I actually bought IntelliJ for freelance web-dev at home its HTML/CSS/JS story is so good by comparison to Aptana and Visual Studio; I’ve used dotTrace and got on really well with it - they do **really good work.

So, TeamCity? It installed fine; I did this a week or so ago at work, and I remember nothing noteworthily bad or broken about the installer. Good first impression there, then. The agents are easy to install too - an MSI pulled down from the admin website.

It’s not as brainlessly-simple as Cruise to set up the first build, but it’s not hard either, and I didn’t have to RTFM until later. We have a setup where we have one svn repo for supporting things (tools for xcopy deployment, library DLLs in one tree, and OS projects via svn:externals in a separate tree), and one svn repo for our actual products. Imaginatively we call them “Supporting” and “Products”. We have the standard trunk/tags/branches arrangement in both. This would let us branch with three manual operations (‘til I automate it…) - branch in products, branch in supporting, commit a change to Products’ svn:external to supporting to swap it to the new branch. This is markedly better than our legacy arrangement, that I won’t go into, because it’s embarrassingly frictionful (and I designed it…).

So, a TC CI build is called a project. A project can have different configurations - a configuration can have different version-control roots (for example, pull from different URLs; this one from trunk, this from branches/foo), different agent requirements (eg, NCoverLicense exists, x64 - these get satisfied by defining properties on the agents so one can delegate different build configs to different agents). A build configuration can get triggered by different events - version control checkins, other build-configs completing, and a couple of other things. To be perfectly honest, I haven’t done more than scratched the surface of the features available because I’ve been playing with rake instead ;-)

Happily, there’s a choice of build-runners too, and one of them is a rake-runner. Perfect. I can almost smell the msbuild project and its plethora of angle brackets burning already…

What else does it do? Well, I’ll be looking at getting reporting of ncover going, next, and after that statistics so that we can see a coverage trend chart. I expect to use this post to get reporting happening, and then this documentation to get the trend chart going - and it’s rather nice that the TeamCity documentation is quite comprehensive, too.

The only real problem I think I can predict so far is our needing to buy a license for the software. The free version allows up to 20 users, and/or up to 20 build configurations, with up to 3 agents. The way I want to set up a project is to break it up into stages with parallelisable jobs in the same way that Cruise provides for. This means that one logical build will consist of a build-config each for:

  • clean, generate-assembly-info, compile projects, run the unit-tests, package the output
  • run the integration tests (which requires SQL Server installed on localhost to the agent)
  • run ncover (which requires the agent to have an NCover license)
  • do some other things (ndepend at some point; TeamCity also has a duplicates-finder runner that I want to try out; I’m sure I can think of some things)

So, that’s at least 3 build-configs per logical build, at present. We’ll want the trunk going at all times, and then we’d also prefer to be working in feature-branches, with CI set up (which looks really easy to do, by the way) against each one. We have five developers, so say 2-3 feature branches going at any one point in time - looks like a recipe for a purchase order in the near future, frankly ;-)