February 8, 2007

Adventures with Team Build and Continuous Integration

Today I made good headway in establishing a base CI build for a new project at work, hosted in TFS and Team Build. We're using the Automaton engine, which seems to work well enough. There are some blind spots with this tool and/or Team Build and that are configuration knobs that I am used to with CruiseControl.NET, like controlling the interval between builds, etc.

I set out to make the build incremental and found this post by Buck Hodges to be helpful.

After some hacking around in the database (to modify the subscription that Automaton setup for CheckinEvent notifications) I finally have the following setup:

Incremental Build
Event Filtered on Two Directories watching for changes on both the Solution root, and the build type root so that if I change the build script, it will kick off a new build (this is what I manually updated in the database).
Unit Tests Executing -- I setup a list called ContinuousIntegration so that developers can control which Unit Tests should be executed by the build process.
Enabled Code Coverage -- It is pretty sweet to get the Code Coverage reports as part of the Build Report

Not quite there yet. Some items that I want to get figured out and employed on this growing build process:

Code Coverage Thresholds -- I'd love to figure out a way to Fail a build if Code Coverage falls under a certain threshold that I specify in my .proj script.
Custom Build Number -- I don't really like the out of the box build number/labeling. Furthermore, I'd like to figure out a way to pass the build number down the chain to set the build number as part of the assembly level file/product version numbers.
Static Analysis -- Is there a way to enable and integrate reporting of the Static Code Analysis into each Build?

Tags: team system, team build, continuous integration, msbuild, code coverage, unit testing, agile