Rules to Better TFS Customization

For Azure DevOps Server (and old TFS servers) Note: If using Azure DevOps (cloud) then you have no method of tracking changes to the Process Template.

The customized process template is a very important asset for your team, you should use Source Control to store the work-in-progress template so you can track the changes and avoid mistakes.

CheckInTemplateIntoSourceControl — Figure: customized process template in source control

You should also keep a version history log in ProcessTemplate.xml so you can track the deployed version easily.

KeepHistoryForTemplate — Figure: ProcessTemplate.xml with version history log

You will need to update your work item types very frequently once the customization process is started, make sure you have a script like below in your solution, this will help you to upload your process template quickly with one click, which make your development more efficient.

ECHO OFF
ECHO \*\*\*\*\*\*\*\*\*\*\*Importing new definitions\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ECHO ON
witadmin importwitd /collection:http://%1:8080/tfs/%2 /p:%3 /f:"..\CN.SAC.TfsProcessTemplate\WorkItem Tracking\TypeDefinitions\Requirement.xml"
witadmin importwitd /collection:http://%1:8080/tfs/%2 /p:%3 /f:"..\CN.SAC.TfsProcessTemplate\WorkItem Tracking\TypeDefinitions\Task.xml"
witadmin importwitd /collection:http://%1:8080/tfs/%2 /p:%3 /f:"..\CN.SAC.TfsProcessTemplate\WorkItem Tracking\TypeDefinitions\Issue.xml"

ECHO OFF
ECHO \*\*\*\*\*\*\*\*\*\*\*Importing new definitions\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
ECHO ON
witadmin importwitd /collection:http://%1:8080/tfs/%2 /p:%3 /f:"..\CN.SAC.TfsProcessTemplate\WorkItem Tracking\TypeDefinitions\Requirement.xml"
witadmin importwitd /collection:http://%1:8080/tfs/%2 /p:%3 /f:"..\CN.SAC.TfsProcessTemplate\WorkItem Tracking\TypeDefinitions\Task.xml"
witadmin importwitd /collection:http://%1:8080/tfs/%2 /p:%3 /f:"..\CN.SAC.TfsProcessTemplate\WorkItem Tracking\TypeDefinitions\Issue.xml" Figure: quick
deployment script for process template – UpdateProcessTemplate.bat With above script, you can execute the command like below UpdateProcessTemplate.bat <serverAddress>
<collectionName> <projectName>

So, just one command, all of your customized work item types will be updated on the server.

Sometimes you will need to create duplicate work item types, e.g. a task work item may be clones as PlatformDepTask, SystemDepTask; both of these task work items are sharing the same fields, workflow or layouts, but they are configured to be accessible by different department or there is some other minor differences.

You should create a WIT template and use a place holder for the difference, e.g.

<WORKITEMTYPE name="xxxxDepNamexxxxTask">
  ...
</WORKITEMTYPE>

Figure: WIT template with a placeholdera

Then use the following PowerShell script to automatically clone the work item and replace the placeholder with actual text.

$original\_file = '..\WorkItem Tracking\TypeDefinitions\Task\_Template\_DONOTInstall.xml'

$destination\_file =  '..\WorkItem Tracking\TypeDefinitions\Task\_ PlatformDep.xml'
(Get-Content $original\_file) | Foreach-Object {
    $\_ -replace "xxxxDepNamexxxx", "PlatformDep"
    } | Set-Content $destination\_file -Encoding UTF8

$destination\_file =  '..\WorkItem Tracking\TypeDefinitions\Task\_SystemDep.xml'
(Get-Content $original\_file) | Foreach-Object {
   $\_ -replace "xxxxDepNamexxxx", "SystemDep"
   } | Set-Content $destination\_file -Encoding UTF8

Figure: PowerShell script to create duplicate WITs and replace the place holder with actual data

Note: if you are using non-English characters in your template, make sure you add –Encoding UTF8 otherwise you will have some encoding problems.

Sometimes you will need to create duplicate work item types, e.g. a task work item may be clones as PlatformDepTask, SystemDepTask; both of these task work items are sharing the same fields, workflow or layouts, but they are configured to be accessible by different department or there is some other minor differences.

You should create a WIT template and use a place holder for the difference, e.g.

<WORKITEMTYPE name="xxxxDepNamexxxxTask">
  ...
</WORKITEMTYPE>

Figure: WIT template with a placeholdera

The default WIT doesn’t control the valid drop down items in Assigned To filed, this will introduce unnecessary items to be shown in the list which will make your users confused, e.g. TFSBUILD, tfsBuildService should never be used to assign a job. Figure: Bad Example – shown unnecessary values

You can add the following XML in the Assigned To filed definition to control the valid values:

Figure: Use ALLOWEDVALUES to control the values in Assigned to field

Figure: Good Example – shown necessary values

You can see details about your Azure DevOps Server (formerly known as TFS) projects directly in your Microsoft Teams channel. Examples of what you can monitor: