Process Implementation and TFS(Team Foundation Server)- Part1

Posted by S Singh under Software Development Practices

I am going to focus this post to explore the process implementation capabilities and features of TFS. Let me start by sharing my understanding of a Process and then see how TFS can help me implement it.

Process to me sounds like a set of rules/ guidelines that we define to seamlessly implement and integrate various lifecycle stages of our projects. This in turn brings maturity and   discipline to the whole software development practice. It also provides us with some meaningful data to identify the improvement opportunities

Let us consider a Scenario: 

Let’s say I have defined a process based on my projects’ characteristics.  By defining the process I mean the following:

•  Define the project life cycle and phases (Analysis, Coding and Unit Testing, Testing , Bug Fixing)
•  Define types of work items and their attributes (Enhancements, issues, bugs, change requests)
•  Define the work break down structure 
•  Define the workflow(Ex: Creation->Analysis ->coding ->Testing-> bug fixing-> closure)

 Now how can I implement this using TFS?

 TFS Approach: 

• We start with creating the project in TFS by choosing the right process template. By default TFS ships with two process templates:
  • MSF for Agile process template( In general, Use this template if your project is of short duration with quick release cycles and does not rely on any documented/formal processes or any compliance to processes standards are not mandated)            

  • MSF for CMMI Process Improvement template ( This template is more useful if your project is of long duration with predictable/defined release cycles and does rely on documented/formal processes Compliance to processes standards are mandatory.)   

 The template choices are not restricted to the above two. There are several other process templates available online that can be downloaded and integrated with the TFS. You can also create your own template or modify the existing ones using TFS process template editor . We will be looking into it in more detail later.  How to customize a process template using TFS process editor

• Now that we have created the project in TFS with a specified process template. We can create and track the workitems as defined in the template. First let me give you an idea of how the workitems are defined in a process template. In other words – Workitem’s Anatomy: Structure and data of the workitem type are stored in the database of the Team Foundation Server. We can export and import it to an XML file using the command line utilities: WitImport, WitExport.  You can also use the process template editor for the same.

 There are three sections to it: 

• Fields
• Workflow
• Form

 Let’s look at the details of each one by one. This will help you create your own custom workitems.  

• Fields

We can also consider them as the workitem attributes (i.e. Data to be stored for each workitem). Each field has the following attributes: 

1. Name : Field name
2. Data type: Supported datatypes are like string, integer and double as well as some complex types as DateTime, PlainText, HTML, History and TreePath (to specify where in the area or iteration that workitem fits in)
3. RefName: A refname has to be a unique identifier for example MyCompany.StartTime. Qualifier names System and Microsoft are reserved. System qualifier is used for fields which store the data which are required to be present in every workitem type. Examples of System qualifier can be System.Name. Microsoft qualifier is used to qualify fields which are more specific to the workitem types, and are shipped with the default process templates.
4. Reportable:If the field is to be reported then we need to provide whether the field will be put in the OLAP cube as ‘dimension’, ‘measure’ or ‘detail’.

   1. Dimension – Use this for fields that have lists of valid values. Work Item Type and State are good examples of dimensions. The Dimension field can be used to filter reports.
   2. Detail – This option is a good choice for unrestricted text fields because it lets you use them in reports. However, any reports that you build using these fields must use the relational database instead of the cube.
   3. Measure – Measures are the numeric values in your reports. Each measure will appear in both the Current Work Item measure group and the Work Item History measure group. 

1. Rules:There are some predefined rules that you can associate with the fields. These rules are: REQUIRED, READONLY, FROZEN (as soon as a field has a value after a commit the value can no longer be modified.), EMPTY, CANNOTLOSEVALUE, NOTSAMEAS (with a refname of other field), VALIDUSER (with or without specific group name), AllowedValuesMatch (With a pattern), Prohibited values etc… The rules can also be applied conditionally by using the elements like: WHEN, WHENNOT, WHENCHANGED and WHENNOTCHANGED. Ex: <When field=”System.Name” value=”Jon”> means that apply the rule only if System.Name value is equal to ’Jon’ 

         

  Workflow

Each workitem is designed to go through a workflow and you can define that workflow using States and Transitions elements.    

• States – These are set of values that a workitem can have during its life cycle stages. Ex: Active, Complete etc…
• Transitions - transition of a work item from one state to other. Possible routes a workitem can take ex: - Active to Complete, Active to deferred etc… We have to provide one transition compulsorily. That transition is from nothing (denoted by “” as initial state) to any other state which we want should be the initial state of the workitem as soon as it is created.  Only the transitions that are defined in the workflow can happen. Every transition should have a reason for the transition associated with it. All the possible reasons should be defined in the definition of the transition. We may also give a default reason which may be used if the user does not explicitly select a reason while activating the transition.

 Transitions can be triggered in two ways:

a)     when the user decides to change the state of a workitem

b)     on a specific action: Say check-in  

Please observe the XML structure below to understand the details:

Reason:

<WORKFLOW>

<STATES>

<STATE value=”Created”>

<STATE value=”Closed” />

</STATES>

<TRANSITIONS>

<TRANSITION from=”" to=”Created”>

        <REASONS>

                <REASON value=”New”>

        <REASONS>

</TRANSITION>

<TRANSITION from=”Created” to=” Closed”>

        <REASONS>

                 <DEFAULTREASON value=”Deferred”/>

                 <REASON value=”No Plans to Fix”/>

        </REASONS>

</TRANSITION>

</TRANSITIONS>

</WORKFLOW>

Action:

<TRANSITION from=”Development” to =” Build”>

<ACTIONS>

<ACTION value=”microsoft.vsts.actions.checkin”/>

</ACTIONS>

</TRANSITION>