TFS - The fascination world of Process Templates

What is a Process Template?

A process template is a set of XML files which define the artifacts of a team project. This post is an attempt to take a peek into the process template, highlighting the structure and the process of making changes to the process template and thus the process. I am using the infamous three dots "..." do indicate missing code or XML stuff, to try an keep the length of this post manageable.

Process Template Architecture

The process template architecture is made up of the (1) new team project wizard, (2) XML process definition files and (3) process template plug-ins. If you have installed the TFS Power Tools you will also have the pleasure of meeting the (4) Process Editor, which integrates seamlessly into the Visual Studio IDE.

The process template plug-ins are components that run when a team project is created, setting up required artifacts and performing configuration. Microsoft ships the following plug-ins:

• Classification, which defines initial areas and iterations.
• Reporting, which defines initial reports and sets up the reporting site.
• Portal, which defines the initial project portal.
• Groups, which defines the initial users and groups, as well as their permissions.
• Work Item Tracking, which defines initial work item types, queries and work item instances.
• Version Control, which defines the initial version control security permissions and check-in notes.

Process Template Files

Looking at the Light Weight Process Template, we have the following XML files:

• ProcessTemplate.xml
  • Root XML file that defines the entire process template and its XML files.
  • It is subdivided into the areas Name, Description, Plug-Ins and Task Groups, as shown by the following extract:
    <?xml version="1.0" encoding="utf-8"?>
    <ProcessTemplate>
      <metadata>
        <name>Light Weight Scrum - v2.0 (Beta)</name>
        <description>Choose the Light Weight Scrum process for projects with short or long lifecycles and delivery-oriented teams who can work
          without lots of intermediate documentation. Light Weight Scrum is an iterative, feature-driven development process for building
          applications. Iterations in Scrum are called Sprints and usually last from two weeks to one month. This process, like MSF for Agile
          Development, is a flexible guidance framework that helps create an adaptive system for software development. This agile methodology
          anticipates the need to adapt to change, and focuses on people as the most important component to the success of a project. It also
          emphasizes the delivery of working software and promotes customer validation as key success measures. Choose MSF for CMMI Process
          Improvement over Light Weight Scrum, if your organization is undertaking a broad quality assurance and process improvement initiative
          or your team needs the assistance of explicit process guidance rather than relying on tacit knowledge and experience.</description>
        <plugins>
          <plugin name="Microsoft.ProjectCreationWizard.Classification" wizardPage="false" />
          <plugin name="Microsoft.ProjectCreationWizard.Reporting" wizardPage="false" />
          <plugin name="Microsoft.ProjectCreationWizard.Portal" wizardPage="true" />
          <plugin name="Microsoft.ProjectCreationWizard.Groups" wizardPage="false" />
          <plugin name="Microsoft.ProjectCreationWizard.WorkItemTracking" wizardPage="false" />
          <plugin name="Microsoft.ProjectCreationWizard.VersionControl" wizardPage="true" />
        </plugins>
      </metadata>
      <groups>
        <group id="Classification" description="Structure definition for the project." completionMessage="Project Structure uploaded.">
          <dependencies />
          <taskList filename="Classification\Classification.xml" />
        </group>
        <group id="Groups" description="Create Groups and assign Permissions." completionMessage="Groups created and Permissions assigned.">
          <dependencies>
            <dependency groupId="Classification" />
          </dependencies>
          <taskList filename="Groups and Permissions\GroupsandPermissions.xml" />
        </group>
        <group id="Portal" description="Creating project Site" completionMessage="Project site created.">
          <dependencies>
            <dependency groupId="Classification" />
            <dependency groupId="WorkItemTracking" />
            <dependency groupId="VersionControl" />
          </dependencies>
          <taskList filename="Windows SharePoint Services\WssTasks.xml" />
        </group>
        <group id="Reporting" description="Project reports uploading." completionMessage="Project reports uploaded.">
          <dependencies>
            <dependency groupId="Classification" />
            <dependency groupId="Portal" />
          </dependencies>
          <taskList filename="Reports\ReportsTasks.xml" />
        </group>
        <group id="WorkItemTracking" description="Workitem definitions uploading." completionMessage="Workitem definitions uploaded.">
          <dependencies>
            <dependency groupId="Classification" />
            <dependency groupId="Groups" />
          </dependencies>
          <taskList filename="WorkItem Tracking\WorkItems.xml" />
        </group>
        <group id="VersionControl" description="Creating version control." completionMessage="Version control task completed.">
          <dependencies>
            <dependency groupId="Classification" />
            <dependency groupId="Groups" />
            <dependency groupId="WorkItemTracking" />
          </dependencies>
          <taskList filename="Version Control\VersionControl.xml" />
        </group>
      </groups>
    </ProcessTemplate>
• Classification\Classification.xml
  • Defines areas and iterations:
    <?xml version="1.0" encoding="utf-8"?>
    <tasks>
      <task id="UploadStructure" name="Creating project structure" plugin="Microsoft.ProjectCreationWizard.Classification"
               completionMessage="Team project structure created.">
        <taskXml>
          <Nodes>
            <Node StructureType="ProjectLifecycle" Name="Iteration">
              <Children>
                <Node StructureType="ProjectLifecycle" Name="Sprint 0" />
                <Node StructureType="ProjectLifecycle" Name="Sprint 1" />
              </Children>
            </Node>
            <Node StructureType="ProjectModelHierarchy" Name="Area" />
          </Nodes>
          <properties>
            <property name="MSPROJ" value="Classification\FileMapping.xml" isFile="true" />
          </properties>
        </taskXml>
      </task>
    </tasks>
  • ... and the mapping to Project, as per FileMapping.xml:
    <?xml version="1.0" encoding="utf-8"?>
    <MSProject>
      <Mappings>
        <Mapping WorkItemTrackingFieldReferenceName="System.Id" ProjectField="pjTaskText10" ProjectName="Work Item ID" />
        <Mapping WorkItemTrackingFieldReferenceName="System.Title" ProjectField="pjTaskName" />
        ...
        <LinksField ProjectField="pjTaskText26" />
        <SyncField ProjectField="pjTaskText25" />
      </Mappings>
    </MSProject>
  • In essence the file defines how a work item type field (WorkItemTrackingFieldReferenceName) is mapped to a project column (ProjectField) and what name should be displayed to the user (ProjectName).
• Classification\FileMapping.Xml
• Groups and Permissions\GroupsandPermissions.xml
• Reports\ReportsTasks.xml
• Version Control\VersionControl.xml
  • Defines the initial version control security permissions and check-in notes, as shown in the Process Editor screen dump:
    
• Windows SharePoint Services\WssTasks.XML
  • Defines the SharePoint portal ... let's use the Process Editor which makes for easier reading than XML:
    
• WorkItem Tracking\workitems.xml
  • Defines work item types (references to the definition files, with examples listed below), initial work items and work item queries (references to the WIQ files).
• WorkItem Tracking\TypeDefinitions\backlog.xml
  WorkItem Tracking\TypeDefinitions\defect.xml
  WorkItem Tracking\TypeDefinitions\impediment.xml
  WorkItem Tracking\TypeDefinitions\review.xml
  WorkItem Tracking\TypeDefinitions\userstory.xml

A final look at the work item type definition ... which we move to customisation

The work item type definition file contains the following:

• Name and Description
  
• WORKFLOW

  • The extract below shows the workflow and states, as well as transitions and reasons. The rules are evident in the Microsoft.VSTS.Common.ActivatedBy, ensuring that the field can only be populated with a valid user and the field may not be empty.

• Form

• Fields

Work Item Tools

We should cover WITEPORT, WITIMPORT, WITFIELDS, GLEXPORT and GLIMPORT, BUT, we will do that later and assume we have the Process Editor Power Tool at our disposal ...

How do we customise a Process Template?

Customisation Steps

1. Download an existing template using the Process Template Manager, unless you wish to hand craft the base XML files.
   
2. Customise the process template by (1) hand if you love XML and have loads of energy, or (2) using the Process Template Editor that ships as part of the TFS Power Tools. Note that an association is created with the Process Editor and a TFS process template XML file when you install the Power Tools. This means that should you double-click the ProcessTemplate.xml file, you are automatically  beamed into the Process Editor, not the XML file editor.
   
   
   For example, adding a new field is as easy as completing a dialog:
   
3. Upload customised template using the Process Template Manager.
4. Create project(s) from customised template.
5. Customise process template work item type changes when and as needed.

This topic used to be as daunting as reporting, but thanks to the Power Tools, the experience is becoming a pleasant one. :)