In Part 1 of this series I have explained what the process template is, and how you can download and upload process templates from/to TFS server. Customizing process template using Process Editor is simple and you can refer the Process Template documentation for that. Here I will explain more about the structure of various process template xml files, which you can even modify without using process editor.
Work Items Type
Team members use work items to track work to be done within TFS. Team members can create a new work item based on a default work item type such as bug, requirement, risk, or task. Each Process Template comes with a set of default work item types, which depends on the installed methodology, such as MSF for CMMI Process Improvement or MSF for Agile Software Development. A work item type is a template from which new work items of that type are created.
Work Item type xml files are located within [Process Template]/WorkItem Tracking/TypeDefinations directory. Each work item will have its own XML file, named as [WorkItem name].xml
Work item type xml can be divided into three major sections – Fields, Workflow and Layout
This section consists of list of all fields which are defined within this work item type. Each field tag will encapsulate all rules defined for that particular field.
<FIELD type="Integer" name="Id" refname="System.Id" />
<FIELD type="String" name="Title" refname="System.Title">
<HELPTEXT>Short description of the bug used to differentiate it in a list or report</HELPTEXT>
<FIELD type="String" name="Assigned To" refname="System.AssignedTo">
<HELPTEXT>The person assigned to act on the bug, either to fix it or to verify the fix</HELPTEXT>
<FIELD type="TreePath" name="Area Path" refname="System.AreaPath">
<HELPTEXT>The area of the product with which this bug is associated</HELPTEXT>
<FIELD type="TreePath" name="Iteration Path" refname="System.IterationPath">
<HELPTEXT>The iteration of the product with which this bug is associated</HELPTEXT>
Workflow section can further divided into two parts,
This section list out all states through which work item can pass on. And each state tag will encapsulate list of fields which have to be empty or required for that particular state.
This section list out all the transitions which can take place between different states. Each transition will encapsulate actions, reasons and fields.
<TRANSITION from="Active" to="Resolved">
<ACTION value="Microsoft.VSTS.Actions.Checkin" />
<REASON value="As Designed" />
<DEFAULTREASON value="Fixed" />
<SERVERDEFAULT from="clock" />
<COPY from="currentuser" />
This section defines the work item user interface, and way controls will be places in the UI. Controls are grouped and positioned using <Group> and <TabGroup> controls.
<Control FieldName="System.Title" Type="FieldControl" Label="&Title:" LabelPosition="Left" />
<Control FieldName="Microsoft.VSTS.CMMI.HowFound" Type="FieldControl" Label="&How found:" LabelPosition="Left" />
Work Item Queries
These are the queries on the work item database that are available to every project member. This initial set of queries can easily be changed once a project has begun.
Work Item query files are located within [Process Template]/WorkItem Tracking/Queries directory. Each work item query will have its own WIQ file, named as [WorkItem Query name].wiq
Contents of these query files are very much similar the way SQL queries are written. Such as test-case work item query file contents are as follows,
SELECT [System.Id], [System.State], [Microsoft.VSTS.Common.Priority], [System.Title] FROM WorkItems WHERE [System.TeamProject] = @project AND [System.WorkItemType] = 'TestCase' ORDER BY [System.Id]