Taming TFS – Default build template

The plan

What do we want form our build server? Well, a couple of things

1. Continuous Integration – build after each commit
   1. Automatic assembly versioning
   2. Strong naming assemblies
   3. Digitally signing selected files
2. Run unit tests
3. Automatic deployment

So what does the default template provide? We have the CI handled – that’s easy, just select it from the “Trigger” section.
Running unit tests – it’s there too. Go to the “Process” section, then “Advanced” – there is an option called “Disable Tests” and it’s off by default – nice.
Automatic deployment – there is the output location in “Build Defaults” section and a “Copy outputs to Drop Folder” in the “Process” section – awesome.
Automatic versioning – hey, we should be able to get that with the “*” character in assembly version and if we use one common AssemblyInfo file for the version it should be good.
Strong naming – that’s just a switch for msbuild and look, there is a “MSBuild Arguments'” param in the “Process” section.
Digitally signing – well, it’s not really there, but it can’t be difficult. So it’s all there – great, almost no work and all requirements covered. But let’s dig a little deeper.

CI trigger – that thing is ok, there’s not much more we could want from it. Execute unit tests – well, as we’re using the Visual Studio Unit Test library, it’s executing and reporting – that should be enough (not sure what’s the story if you’re using a different library e.g. nUnit), but I’m afraid that’s pretty much it for ‘out of the box solutions.

Automatic versioning – not really there (the “*” thing is really just as good as putting random numbers in there), strong naming – yes, it is a param to the msbuild, so that’s actually the least problematic thing (you just need to dig into msbuild params), digitally signing – there’s an external tool for that (“signtool.exe”) but I don’t see a build task for it, automatic deployment – the drop folder contains the build output and that’s far from what we want our deployed folder to look like.
There’s a lot of work here, so let’s get cracking.

As I mentioned before, tfs allows you to customize the build process in any way you want. Version 2010 uses workflow activities to manage the build (unlike the previous versions which used msbuild scripts). You can change the build template using the available activities and you can (and will need to) write your own activities for things that don’t have their building blocks. The important thing is that once you write custom activities, you need to put the binaries into source control and tell the build controller where they are by supplying the custom assembly directory path in controller properties

I will not focus on technical aspects of creating custom build activities (there is a great blog post for that). Here, I’ll focus on achieving the goals mentioned at the beginning. I’ll be expanding the “Default Template” provided with tfs, so stay tuned for more.

Cheers