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.