Including Code Coverage Results In TFS Alerts

Notifications are a fundamental component of a successful SharePoint continuous integration strategy approach. Maintaining continuous feedback on SharePoint products is an important counterpart of continuous integration for realizing agile SharePoint development. Without timely notifications about the status of a build, mostly broken builds, bottle necks can occur which negate the benefits of a SharePoint CI implementation.

While doing a TFS 2008 upgrade that was heavily used for SharePoint development I was recently doing for a financial institution customizing these emails came up to adapt to the organizations CI policy. Specifically, how one could include the code coverage results in the email.

Under normal circumstances TFS provides a pretty reasonable mechanism to achieve notifications for CI. Individual email alerts are structured around an XSL template found in the TFS server installation directory then under Web Services -> Services -> v1.0 -> Transforms. Adjusting the XSL will change things like the text that the user receives. It is important to note that these files, like most hived files in SharePoint, are mutable with service packs and changing them can mean that future installers will not pick up the files due to the adjusted timestamp. Thus, it is typical to make a backup of the file to restore when applying updates, then rolling in the custom changes that were made previously into the updated files.

Now for the disappointing news. After scouring the completion event schemas for builds there is no field that provides the code coverage metrics, thus it makes it really hard if one wants to include code coverage data. Without this, you can’t not only not add it to the email, but to the Build webform. As a really poor substitute you can get the code coverage data from TSWA though, and you could point the email to look at the code coverage data through that medium. I think it’s a pretty lame solution.


Large SharePoint Components with Continuous Integration Cause Time Outs With Automated Builds

When using TFS as a continuous integration platform with TFS, you may find that time to time with larger pieces that source control queries will start to timeout when automated builds are triggered. Thus, when a build is triggered and the sources are attempted to be pulled down to the build server working directory, you will get an error similar to the following:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets: error : : The operation has timed out.

To get around this problem you can change the timeout settings in the registry for the HKLM in the following location:


@DefaultTimeout: DWORD –> Sets the timeout, in milliseconds, for an individual request (the default is 5 minutes)

This should be done carefully, as actual issues might not bubble up as they should in regards to connectivity.


Setting Continuous Integration For WebParts For Hourly Builds

There will be occasions when building custom WebParts under a Continuous Integration strategy where you don’t necessarily want to just build on check-in, but also want to run continuous builds on a time laced schedule, regardless of whether it has been check-in or not. When attempting to just use triggers, you may find that this doesn’t work exactly.

Firstly, under most orthodox considerations a build is not considered to be under a CI umbrella if it is not triggered by a check-in. However, to get around this issue you can use Check-ins do not trigger a new build as a trigger then use the inbuilt Window scheduler to call TFSBuild.exe while passing in the correct arguments with the /msBuildArguments switch. Batch it up, and you will be ready to rock and roll!