Approach to Process Customization with TFS

I was recently asked to provide some insight for a friend on process template customization.  I pointed him to the documentation but promised the following short blog to round out the approach...

If you are going to customize your process templates, I propose the following based on my lessons learned:

1. Perform process customizations on a development/test environment and import the process templates onto your production servers AFTER they've been debugged.  It is possible to define work item fields incorrectly and not be able to fix it later, so don't break your production server.  For that matter, Virtual PC is great for this because of undo disks.
2. Assuming work items are a big part of your customization, create a scratch team project for customizing the work items.  This project should be based on the process template that you're going to customize (e.g., MSF for Agile Software Development).
3. Use WITIMPORT and WITEXPORT to refine your work item definitions within that scratch project.  (Check under the Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies if you need to find the path.)
4. If you get into trouble with a incorrectly defined field, use WITFIELDS (same path) to delete it.
5. If you need to revise the MS Project field mapping, use TFSFieldMapping (also in the PrivateAssemblies path).
6. As need, define project groups in the scratch project to support work item constraints.  Take note of what you've defined as you'll need to add them to your process template definition.
7. You can use Team Explorer to create any custom work item queries for your process template.  Use the Save As File option to export them to .WIQ files for use in your process template.
8. You can use the scratch project to customize the project portal for reference purposes.  However when it comes time to generate the WSS template XML, it will be by hand.  Nonetheless, this approach can be good if you need to get sign-off from someone with the document library structure and document templates.
9. As you make changes, create work items in the scratch project to verify that they function as expected.  Walk them through the various states if you are doing workflow and/or managing constraints based on team project groups.
10. Once you're relatively happy with your scratch project, download the process template for your scratch project using the Team Explorer Process Template Manager.  This will be the template that was used to create the project and not a snapshot of the current state of the team project.
11. As needed, change the name and description of your process template in the root ProcessTemplate.xml file.
12. Move you new XML work item definitions into the TypeDefinitions folder modify the WorkItems.XML file to register them.
13. Move any custom work item queries into the Queries folder and modify the WorkItems.XML file to register them.
14. If you customized the MS Project mappings, update the FieldMappings XML file as appropriate.
15. If you added any custom project groups, modify GroupsAndPermissions.XML to update those changes.
16. Manually modify the document library and document library content modifications in the WSSTasks.Xml file.
17. As necessary, modify the VersionControl.XML file to update the default TFVC permissions based on your custom groups.
18. When you are finished, use the process template wizard to Upload the template.  If it fails, look at the log file and fix your XML.
19. Uploading the template is not the end.  You need to create a new team project to verify that it works.  You may need create many team projects as you iteratively fix your XML definitions.  As such, you should be aware of the TfsDeleteProject command line utility or, better yet, the Virtual PC undo disk.
20. Finally, exercise your new team project.  I have been able to successfully create team projects but still have critical problems in my process templates.
21. If at this point you're happy with your work, move the updated process templates onto your production server.

This covers many of the basics, but not everything.  There are several approaches to custom reporting.  If you do any significant work item modifications, you can expect to break existing reports, so this is something to be aware of...

In addition, I didn't discuss the process guidance.  There is a separate tool and the use of InfoPath to ease the generation of the process guidance web pages.  But that is a detailed post unto itself.