Setting up TeamCity…

I’m gradually in the process of shifting our CruiseControl based CI service to use JetBrain’s TeamCity Professional solution (both are free).

The main reason for moving to TeamCity is that whilst CruiseControl worked and did our CI adequately, TeamCity provided more bang for your buck (and when the buck is 0, it’s win-win). TC is effectively CC but with a nicer front end and provision for stats about the builds etc. It’s definitely worth checking out if you are just getting into CI. The only major drawback is the source control integration it has – i.e. it only works with selected source control solutions at the moment (SourceSafe etc) – If you have one of these SCC then give it a try!

Anyhews – migration – easy?
Yes and no – Adding my VS2008 projects to TeamCity was a breeze – they’d never been CC’d so no migration required – just point TC to the SourceSafe database, and then tell it which sln file to open.

Migrating the existing VS2005 projects has been a bit harder, and to be honest most of it is to do with the unit test setup, and they way we have some of our solutions setup – dependency nightmares. I’m pretty certain this is covered by a thing called ‘Artifacts’ in the TC world, but I have yet to explore them properly.

Setting up a TC project consists of 3 main steps,
1. Name the project, describe it etc, decide on the numbering of builds – so you can have 1.x where ‘x’ increments, or just ‘x’ (which is default & the same as cruise control).
2. Set up the source control – point it to the right root project, give it a check out name (or not should you choose).
3. Set up the build runner – in all my cases – based on an sln file, but you can use MSBuild, Ant and many more. This is the usual stuff – configuration, etc.

This is enough to get it to run, but there are even more options – you can set up dependencies, triggers and ‘Agent requirements’.

Agents are one of the really cool things about TC, an Agent is basically a machine that does the compilation. You can have 3 Agents in the Professional edition (and pay for more if needed). At the moment the build server we have doesn’t have .NET 3.5 installed on it, so my VS2008 applications won’t build there, but (obviously) my machine does. So I can have one Build Agent on the build server – for all .NET 2.0 apps, and then my machine with .NET 3.5 as another agent.

Effectively my machine can build any of the .NET 2.0 solutions as well, so now we can do two builds at the same time. TC knows which agents are idle and pushes the build requests to an idle agent – based on a ‘power’ order, i.e. the most powerful agent first.

Anyhews – a few more projects to migrate!