Implementing Team Build, part 1

Our company is certainly not the first to jump onto the Team Foundation Build system for managing builds, but probably not the last either. We CM's inherited a CruiseControl.Net installation which had grown to include quite a few features, and naturally we wanted to keep those. These were what we needed, that weren't supported with 'basic' Team Build process templates and actions:

• Automatic update of assembly information.
• Build dependencies, i.e. building of one product automatically queues the build of another (and another, and...).
• Unit testing with NUnit, continuously and at intervals. (We have a lot of tests, roughly 8000, and one single test run could sometimes take as much as 7+ hours).
• Building installation packages.
• Automatic e-mail to users upon build or test failure.

In fact, we almost went with JetBrain's Team City because it had all these features from start. But luckily, we decided to try to implement these features by extending Team Build first. It has been quite a trip, but now we're nearly there.

Following that decision, we naturally wanted to add the 'winning' features of Team Build as well:

• Changeset and Work Item integration
• Gated check-in's
• Build retention
• Symbol server

In the following posts, I'll try to go through our implementation step by step.