Just read an interesting post by Tim Barcz. It’s about a team struggling to adopt agile practices, and if given a chance to start over, what they should set up first: a CI build or a unit testing process.

I don’t understand why someone would even have to choose between them. Setting up a regular CI build (with that i mean a simple compile + running all the tests) for a project should never take more than 10 minutes, tops. That is assuming that you already have a build server in place, obviously. But with Team City being so incredibly easy to install and configure, that can no longer be an issue.

So what does it take then? Drop in a simple, standard build script which builds your project and runs the tests, add a build configuration and you’re done. Setting up a basic CI build should never take more work than that, unless you have some very specific needs, or the project structure is somewhat messy… as in: it doesn’t compile if you don’t have certain assemblies in folders that are either hardcoded or ‘assumed’ to be there… which should be avoided at all times

Seriously though, long build scripts or requiring a lot of time to set up a new CI build are all signs that your CI process in general needs some refracturing (nope, not a typo).

And in case you needed some motivation: even TFS 2008 allows you to set up a CI build in less than 5 minutes of work

I’ve been playing around with TeamCity a lot lately. It’s really amazing how easy to use and powerful it is. Definitely my favorite CI server for the time being… i’m even running it at home now for my personal projects.

There was one issue at work that was somewhat hard to fix though. TeamCity has fantastic integrated support for NUnit, but unfortunately it doesn’t write NUnit’s output to XML files like nunit-console.exe does. After a bit of browsing, i found a post on the TeamCity forums that discussed a workaround on how to get the output. Unfortunately the workaround is a bit cumbersome as it requires you to you create an XML file which contains the arguments that TeamCity would pass to its NUnitLauncher task.

I believe in ’script reuse’ as much as i believe in ‘code reuse’, so every project’s build script merely imports a generic build script and then it just overwrites some variables that the generic script uses and then it kicks off the usual build process. Since all of our projects will now be built by TeamCity Build Agents, and we definitely need to have NUnit’s results xml file i wanted to automate this whole thing as much as possible.

So instead of having to create (and thus, maintain) a cumbersome xml file for each project, i wrote an MSBuild task that would generate the xml file containing the arguments on the fly during the build, and would then pass those xml arguments to TeamCity’s NUnitLauncher. This way we get to keep all of TeamCity’s NUnit integration goodness, while still keeping the NUnit result files around as well.

So now in my MSBuild file, i can just do this:

As you can see, there is nothing project-specific in there so this just integrates nicely into each build that we need. The only limitation to this approach is that TeamCity’s NUnitLauncher will write one NUnit result file for each assembly containing tests. Apparently there is no way in the current version of TeamCity to get it to combine those results. We use an extra tool to analyze the NUnit output after the tests have run, and unfortunately it requires all of the results to be in one file. I looked around for a way to merge the output of several NUnit result files, but i didn’t find something that was already available. So i wrote another MSBuild task that would merge the output into one xml file:

Now we finally have all of TeamCity’s goodness while we still get to run our post-test analysis on the NUnit result file that contains the testresults of all the test assemblies

You can find the code of the MSBuild tasks here. They are BSD-licensed so feel free to use them if you need them.

As part of Martin Fowler’s Signature Series, a new book on Continuous Integration has been released written by Paul Duvall (with guest contributions from other authors as well). The book is called Continuous Integration: Improving Software Quality and Reducing Risk… should be pretty interesting. I already ordered my copy