A look at TeamCity for Continuous Integration and Build Management

We currently use Cruise Control for our continuous integration and build management at work, and it works for us quite nicely. For the current project we have a few different builds and deployments for building, integration tests, reporting and migration.

We are using a slightly older version of cruise control so the web interface is lackluster, the cc-tray is reasonably low on features (although functional) and we've had some integration issues with TFS (which are normally able to get around). The newer version looks very nice and an improvement on the version we are currently using, however I wanted to try something altogether different, which brings me to TeamCity from JetBrains.

On paper it looks fantastic, with some highlights (as far as .NET is concerned):

• Integration into visual studio.
• Plugins for FxCop, NAnt and Windows tray.
• Gated checkins (Don't need to wait for the new TFS).
• A built in duplicates finder.
• Distributed computing for faster builds!

So overall it really looks like a great tool which could rival CC.NET, and for Java TeamCity could well be a heavenly system for IntelliJ zealots!

Actual installation was a breeze (A bunch of nexts), TeamCity will actually deploy a Tomcat server (Only supplies a web interface) and you have the option to run it as a windows service (I picked yes). It does look like the application is slightly heavy on resources:

The extra java.exe process is for the one build agent I have configured already, we'll get onto this in a bit. Given the functionality it offers we can forgive it's footprint, but I recall CC being slightly easier on resources especially when idle.

Let's take a look at the web interface where all the configuration and administration happens:

Here's a project I've setup earlier, this is the first thing TeamCity will want you todo, setting up a project involves just giving it a name, however you will need to then create a build configuration.

A build configuration consists of:

• General Settings (Build numbers, build fail conditions and hanging build detection (which is nice).
• Version Control settings, of which it supports them all (except git).
• Build Runner, I'll take a look at configuring this in the next post, first with MSBuild and then for NAnt when I get onto more complicated deployments.
• Build triggering, such as trigger a build when someone checks in, but there are some other options.

The fail building scenario options are straightforward:

As I mentioned before, TeamCity will want some agents to be able to run the builds on. In my case I put an agent on the same machine as the TeamCity web server, however this is not necessary. Installing buld agents simply requires you to go to the Agents page, download the appropriate file for your O/S (MS Installer, Java Installer or a ZIP) and follow the instructions. I will attempt to add my quad core machine as a build agent and see how it all works in a future post.

That was a really sketchy first look at TeamCity after getting it installed, future posts will hopefully be more useful :)