Microsoft recently made an announcement about a Visual Studio Team Services feature that was due for quite some time. Microsoft now allows limited customization of Process in Visual Studio Team Services. Considering that VS Team Service is a multi-tenant service offered in the cloud, this is a big step towards allowing total customization of the Process.
If you are wondering ‘what is Visual Studio Team Services’, then let me clarify that it is the same set of services which were available as Visual Studio Online (VSO), renamed as Visual Studio Team Services or VS Team Services. In a nutshell, it refers to TFS in the cloud.
This article is published from the DNC Magazine for .NET Developers and Architects. Download this magazine from here [Zip PDF] or Subscribe to this magazine for FREE and download all previous and current editions
So far, the only process templates that were allowed to use on VS Team Service were the ones available out of box - CMMI, Agile and SCRUM. Although they catered to majority of common needs of customers, there were quite a few customers who wanted to have their own definitions of work items, their own work item types and workflows for existing work items. Using a cloud based service like VS Team Service reduces the cost of using the product because we share the infrastructure with other customers. Sharing the infrastructure is good from a cost perspective, but not so good for customization and that’s why Microsoft did not offer customization of VS Team Services earlier. Microsoft knew that not providing the ability to customize, was going to be one of the road-blocks for adoption of VS Team Services. For the last few months, efforts were on to provide some customizability to the processes of VS Team Services and now we are seeing the result of that.
To reach the interface of process customization on the VS Team Service, the route is from ‘Overview’ page of your account > to Account management (Control Panel) page > to View collection administrator’s page > to Process tab on that page. When we reach that page, we see the three out of box process templates – Agile, CMMI and SCRUM.
Figure 1: Existing Processes in VS Team Services
Until now we could export each of these services if needed. Now we get many more options when we click the triangular black icon on the left of any process template name.
Figure 2: Inherit a Process
Our journey for customization starts by creating the inherited process which we will change as needed. Let us create a process named ‘SSGS Agile Process’ inheriting it from ‘Agile’. One thing that you will notice immediately is that you cannot create a new work item type. Let us take the example of our TicketM software. For our TicketM software, we would like to create a Ticket work item type but at this moment there does not seem to be a way to add a new work item type. This is a major setback to what we wanted to do as part of customization of process. OK, so we are constrained to edit an existing work item type only. Let’s hope that within the next couple of months, Microsoft will provide the feature where we can add a new work item type.
Going forward, what we would like to do in the existing work item type definition is the following:
- Create a new field named Customer for a User Story. It should be just a string field with allowed values that for the sake of assumption, are 13 customer names that we have. We would like to assign a default value to it.
- Change the workflow of the User Story so that we have a state for ‘Blocked’ or ‘On Hold’ with some related transitions.
- We also expect that we will be able to create a dependency such that if the state is ‘Blocked’ it should be compulsorily assigned to a user in a specific group of the team project.
With these limited goals let us set out on our journey.
On the newly created process template, we can see a tab for Work Item Types and Fields. We do not see the tab for workflow which is something we wanted. Unless it is hidden somewhere under the Work Item Types, we will have to wait for that too. Out of existing tabs, the Fields tab only listed the various fields for view, which are present in the bucket of fields. It listed those with the work items that use each field. This is good. We would like to see something like this for TFS too.
Figure 3: Fields List
The tab for work item types is more suitable for making modifications to work item type definitions. It lists the work item types in the inherited process template and for each of those work item type, it lists the sections for Overview, Layout and Fields. The overview node shows the fields that are not editable. These fields are the name, description and the color with which it shows the work item in the query results.
Although these fields are read-only, the screen mentions that they are read-only ‘at this time’ which gives an indication and a hope that they may become editable in future.
Figure 4: Work Item Overview
The Fields node is the one that shows the categorized list of fields in the selected work item type. Here we will select User Story, and add a new field to the list. We can select a field in the list and edit its definition.
Figure 5: Edit a Field
What the editor shows is the field definition attributes like Name, Type and Description. These attributes are not editable while editing a field, but are editable when the field is being created. Which means that we can make no mistakes while creating the field definition. There is no chance for correction in case of any error once the field is saved.
Figure 6: Field Definition
In the Layout node, it allows us to set whether that field can be viewable on the form of the work item of that type. It allows us to edit the Label that appears beside the field, and also allows us to place the field in any of the existing groups on the form of the work item type. We can also create new groups that will make logical grouping of new fields.
Figure 7: Field Layout
And finally the options node is where we can set some rules on the field. The first one is whether the field is a mandatory field or not. We can also set the default or initial value of the field. This also means that we cannot set any of the more complex rules that are available in customization of on-premise TFS.
Figure 8: Field Options
When we save these details, we can view the fields list again with the changes appearing in the respective columns.
Figure 9: Field List After Field Edit and New field
Let us now add a new field named Customer as desired by clicking on the button of New Field. We will set it to a text field type. We come to realize that here we have no way to provide ‘Allowed Values’ which are our customer names. This is something that we will need in the earliest updates of this feature.
Figure 10: New Field
After giving the Classification as the group in which to include this field and the option of Required, we will now save the field. It now became part of the process ‘SSGS Agile Process’
When we create the new team project with the newly created process template and create a new User Story in it, we can see the Customer field in the classification section in it.
Figure 11: New Field View
One very nice feature that in my opinion is awesome, is that we can apply this process template to the existing team projects too.
Figure 12: Apply Process to Existing Team Project
Microsoft has taken a baby step towards providing the customization of the Process on Visual Studio Team Services. Although I expected more, right now only possibility is to do customization of fields in work items. Even that is quite limited. I do expect much more out of this feature in the near future. Since it is being done on a multi-tenant services, I do commend Microsoft for providing at the least some beginning to this much awaited feature.