On my own, I had among other to:

1. Extend TFS with a plugin to check Policies server-side:.
   • This one enforces our branching strategy,
   • Check quota usage and maximum file size,
   • Restrict the file types that can be stored in TFS (no ISO, VHD, MKV – you can’t imagine what end-users can try to store in source control),
   • Validate project folders hierarchy according to our Design patterns, etc…

   Implementing Policies server-side is minimizing the maintenance efforts (nothing to distribute on all the development workstations), fixes are effective immediately after deployment, Policies are enforced for all clients and nobody can bypass them, …

2. Create customize Build Process Templates to
   • Build Microsoft Setup Projects and Biztalk Projects,
   • Support automatic build deployment,
   • Support online Server maintenance and graceful TFS reboot (waiting on current build to complete before updating or rebooting the server),
   • Validate Build Definitions against our Policies (Build Timeouts, Drop folders location, etc…).

   For any task to be run on Build Servers, we use Custom Build Activities and Custom Build Process Templates, so those tasks can be easily integrated within the Build Schedule, …

3. And finally, create Visual Studio Plugins to automate some TFS operations, e.g.:
   • Right click a Build to retrieve all its binaries and their sources in order to pass them to our in-house SCRM tool (a.o.: for backward compatibility between TFS and our Release Distribution processes),
   • Right click a Build to automatically create an Maintenance Branch from its sources in order to implement some fixes, …

I used to be quite comfortable with the customization of Team Build 2005 and 2008, using custom complex MSBuild Scripts. But I didn’t find it easy to start the customization of Build Process Templates using the online MSDN documentation available for Team Build 2010 (i.e.: actually nothing relevant). I did also initially find difficult to implement the same features server side and client side as equivalent TFS API’s are implemented in distinct Microsoft Assemblies and have distinct signatures…

Fortunately, there are always pioneers who are digging new stuff and publishing their findings on the web. So nowadays we can find a lot of information although the MSDN online documentation is still really poor. Here are my three main sources of information:

• Read the excellent blog of Ewald Hofman for everything related to customizing Team Build.
• Read the great blog of Martin Hinshelwood for everything related to creating Server-Side Event Handlers for TFS.
• Read the incredibly useful blog of Tarun Aurora for everything related the use of TFS API