VSTS - Workitem Architecture, Design Considerations and Customization: Part 2
Posted by: Subodh Sohoni
in Category VSTS & TFS (Azure DevOps)
Abstract: In the Part 1 of this article, we documented the structure of a typical workitem. In Part 2, we will discuss the customization of workitems.
VSTS - Workitem Architecture, Design Considerations and Customization: Part 2
In the Part 1 of this article, we documented the structure of a typical workitem. In Part 2, we will discuss the customization of workitems.
Process templates provide the definition of workitems types which are available when the TFS is installed. Each process template uses some common workitem types and some which are specific to that process template. Workitem types Task, Risk, Bug are common to both the process templates that are installed along with TFS. MSF for Agile uses Scenario and Quality of Service Requirement as specific workitem types which are not found in MSF for CMMI process improvement. MSF for CMMI Process Improvement uses Requirement, Change Request, Review and Issue as specific workitem types in addition to common workitem types. For some of the projects and processes these workitem types are sufficient. In many cases we may want to track the same entities but with some additional data. For example we may want to store name of the customer for whom a feature is being created as a subproject. We may want to monitor the progress of the work that is happening. In some of the rare cases it is possible that we want to create a totally new workitem which has unique data to store and trace.
First consideration that we should make is to find whether the data to be stored is really something which is not being captured in some other form. If a similar workitem type exists then we should consider reuse of that. If a field of similar nature in a workitem type exists even reuse of that should be considered. TFS puts the maximum number of fields which can be defined to 1024 so reuse of fields is necessary wherever possible. If no workitem type matches the requirement of data to be stored then only we may think of defining a new one or modifying an existing one.
Let us consider a case where we need to trace that the code review is done by the reviewer before code is checked in. A programmer can inform the reviewer to execute the review by creating a workitem and assigning it to the reviewer. We can think of ‘Task’ workitem type to be used to pass this information. The reviewer may approve the code after review or may suggest changes and reassign the workitem to the programmer. The data to be passed in the case from programmer to reviewer is the location of the code that needs to be reviewed and from the reviewer to programmer we need to pass the suggestions. The reviewer also needs to set the status of the workitem to ‘Approved’ or ‘Not Approved’ or ‘Rejected’ based upon the code quality. These are minimum requirements which I am taking for illustration.
The ‘Task’ workitem does not contain the fields to pass the data which is mention above. It also does not have the states which are required. What it does have is the basic structure of the workitem type and the structure to do the scheduling. We may think of modifying the same workitem type and reuse the basic structure. After modification the changed workitem type can be used as task workitem type or we can change the name to say ‘Code Review’ so that the task workitem type remains unchanged. Definition of ‘task’ workitem type is little different in both the process templates which are provided by Microsoft. The definition of ‘task’ workitem type in ‘MSF for CMMI process improvement’ process template is more elaborate as compared to the definition of the same in ‘MSF for Agile’ process template. We will go with the definition provided in ‘MSF for Agile’ since we do not require additional fields that are present in the ‘MSF for CMMI process improvement’.
Let us take stock of the fields that are present in ‘Task’ workitem. The common fields that are present are: Title, Discipline, Area, Iteration, Assigned To, State, Rank, Reason, Description, History, Links and Attachments. Except for Rank field all are required for our customized workitem type. The special fields which are present to store ‘task’ specific data are: Issue, Exit Criteria, Integration Build, Task Context, Remaining Work, Completed Work, Start Date and End Date. We may replace these with ‘Code Review’ specific fields.
What I will store in the ‘Code Review’ is Name of the reviewer, Name of the programmer, Date on which code review was requested, Date on which code was approved, suggestions for modification in code by reviewer, location of the code for review. We will create all of these as fields in the ‘Code Review’ workitem type.
I created a field named ‘Reviewer’. This field will automatically get value from ‘System.AssignedTo’ field. Ideally it should come from a user group which is designated as reviewers. I also created a field named ‘Requestor’ which is assigned the value as name of the user who is creating this workitem. A filed named ‘Code Location’ points towards the location from where the code to be reviewed can be accessed. It most probably will be a shelve-set name but there is no restriction that I have put. The reviewer can enter comments as necessary in the field ‘Reviewer Comments’.
States which are defined for task are Active and Closed. These fulfil the necessary and sufficient conditions for the task. What we need are states for before approval when the code is sent for approval, when the review is in progress, when code is rejected by reviewer and when code is approved by the reviewer. I give them names: Requested, InProgress, Rejected and Approved. Possible transitions can be: Requested to InProgress, Requested to Approved, InProgress to Rejected, InProgress to Approved, Rejected to Requested. These effectively define the workflow framework of the “Code Review”.
We can do some refactoring by short circuiting InProgress status.On one hand it provides a way to know that reviewer has opened the code; on the other hand it does not provide any additional information. I am of the opinion to keep it but I am keeping the decision open for everyone to implement the way they feel correct.
The form will contain the newly created fields instead of the deleted ones in the ‘Detail’ tab.
Since the modifications involved are extensive, ‘Task’ cannot be used for the purpose it is defined after modifications. Due to this, I will retain the workitem type ‘Task’ as it is and create a new workitem type “CodeReview” .
The XML which is used to create all these can be downloaded from over here.
In Part 2 of this article, we have discussed the architectural and design considerations we should make to modify an existing workitem type or to create a new workitem type. In Part 3, I will try to answer how to do these things in the existing team projects as well as in process template. I hope this article was useful and I thank you for viewing it.
This article has been editorially reviewed by Suprotim Agarwal.
C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.
We at DotNetCurry are very excited to announce the The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).
Organized around concepts, this eBook aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on .NET Standard and the upcoming C# 8.0 too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.
Click here to Explore the Table of Contents or Download Sample Chapters!