speeding up your TFS CI builds

If you’re using TFS as your build server for CI builds of .NET projects, you want your CI build to be bleeding fast so devs don’t sit around waiting until their build completes. This is even more the case if you use a gated check-in on that CI build.

The ideal time frame is less than 5 minutes, but as a solution grows and more projects are added it gets hard to stay below that time limit without tweaking the build. With a CI build in this case I mean a build used to check if all code compiles, is integrated with other code and all unit tests pass on it.
This build is not used for deployment. There should be a separate build for that.

So what are the time sinks here in a standard TFS build?

It helps if you know what’s it’s doing, even though it’s pretty straightforward. First your code is fetched from TFS. A local workspace is used on the build server and all files are retrieved. Then the VS solutions build with MSBuild. Code analysis is performed if requested, unit tests run, outputs are copied to your drop folder and build reports are published.

Here are a number of things you can do to speed this up:

• Get only the latest changes, not the full code base every time by not completely cleaning up the workspace. If you only clean up the outputs, it takes a lot less time to update the workspace. The more code you have, the more this counts.
• Code analysis is CPU intensive and slows down your build significantly. Make sure you set this to “as configured” in your build configuration, so it doesn’t run on projects that you don’t want analysed. Then configure your projects in Visual Studio that need CA, and disable it for the rest.
• In the Source and symbol server settings, set “Index sources” to false for the CI build. This feature includes source information into your PDB files which makes things easier to debug later on, but since we’re building strictly for a CI build we don’t need this data afterwards.
• Disable copying output files to the drop folder. The output of the CI build shouldn’t be used for any deployments, so this can all be skipped to speed up the build.
• Look for slow tests. Often these are integration-like tests which will be causing disk I/O by manipulating files or accessing a database etc. You can disable them for the CI build only by adding a TestCategory attribute called “Integration” (or whatever you like) and exclude those from the build in the test settings. Another trick is to put all your integration tests in a separate assembly and exclude the tests from running using the test assembly file pattern.  E.g. With *.Test.dll project Foo’s Foo.Test.dll is included, but Foo.IntegrationTest.dll isn’t.
• Avoid lots of small projects in your solution. Every project will take a few extra seconds to build, so merging them into a single larger project will build faster. Make good use of namespaces instead. For example one assembly for unit tests (or 2 if you take that integration test project in mind) is better than a test project for each regular project.

Pick and choose as needed, but these should give you a considerable boost.
Remember to analyse your build before starting to tweak it. There’s no point in optimizing what’s fast as hell already. A good tool to check out what’s taking so long is the open source TFS Build Explorer. It shows your build steps in a tree-view, including timing info and is a hell of a lot quicker than the default build output from TFS for big builds. Depending on your TFS server version you might have to use an older executable, but they are all available in the download section.

Photo by Éole Wind, cc-licensed.