TFS Alerts for Team Leads

TFS has a great (but not perfect) events and alerts system – you can be sent emails about work item changes, source control check-ins and build completion. TFS Power Tools adds Alerts Explorer to Visual Studio, which is a must-have for configuring alerts as the built-in Project Alerts is very basic.

Alerts Explorer allows very sophisticated filters to be set up, but that power can be confusing. I have found that in a development team lead role just two special alerts provided the oversight I needed. Here’s how to set them up.

Alert 1: Check-in Policy Override

Check-in policies (along with folder security) are invaluable for source control management – they can enforce check-in comments and linked work items, and prohibit specific file types being checked-in. However, users can simply override the check-in policy! In one way this is helpful, because it allows work to continue past an overly-restrictive policy, but in every other way it’s madness – people can ignore your carefully constructed policies whenever they like.

Fortunately there is a good compromise – you set up an alert telling you when the check-in policy has been overridden. That way, the user can override the policy if they think they really must, but you get to review what happened and take action if necessary. I found that simply telling people that you get an alert when the policy is overridden was a sufficient deterrent 99% of the time.

This alert is a slight modification of a template that comes with the TFS Power Tools. Note that all source control users must have the power tools installed if you are using any of the check-in policies that come with the power tools, or you will receive an alert every time they check-in (which is quite useful, as you can then tell them to install the power tools!)

Alert 2: Build Failure

The Build Notifications tool that comes with Visual Studio is OK, as it generates system tray alerts that are near-synchronous with build completion. But it’s not much help if a build failed an hour ago or overnight. An email alert can cover this instead.

Note that I have not simply chosen StatusCode = Failed as I also want to be alerted on builds that are “partially successful” i.e. that have test failures. I’ll give users the benefit of the doubt on Stopped builds and assume that builds are only stopped for valid reasons. You may decide differently for your team.