Personal experience: the organization of Workflow in the TFS tracker

We continue to talk about the development organization processes at Positive Technologies. Earlier, we touched on the creation of product distribution kits , the organization of the process of storing and licensing software and the implementation of our own Continuous Integration system.

Today we will talk about how we use the Team Foundation Server (TFS) tool to organize workflow development.
')

A bit about TFS

Team Foundation Server consists of several components.

Version Control System:



Task tracker:



Continuous Integration System:



For our company, TFS is first and foremost a task tracker that most teams use. The second most popular usage scenario is a version control system in which not many projects are stored, but all of them are actively developed. On a residual basis, we use TFS and as an assembly system — for the very same projects whose versions are stored in it.

TFS for task tracking and workflow organization

The system supports development methodologies such as Kanban, Scrum, CMMI. In addition, various types of tasks are supported, including custom ones: Bug, Task, Feature, User Story, etc. Also worth noting is the flexible change system for workflow tasks.

The basic workflow for the Bug task in TFS is as follows:



We see n statuses - initial, final and transitions between states. As a rule, very few people work at the basic workflow - there is always a need to expand it.

In our case, the modified process might look something like this:



The workflow extension was accomplished by adding new statuses and renaming existing ones. For example, the Rejected statuses were added for tasks that were rejected for some reason, Moved for tasks transferred to another project, Pending for tasks that were temporarily suspended.

Renamed statuses: Approved became known as In Progress, it means that the task was taken to work, and Commited was renamed to Resolved, meaning that the task was solved and it was necessary to confirm its completion, or additional work on it.

The appearance of the Bug card changes in the same way. At the very beginning after creating the project, it looks like this:



In its basic form, the system provides some information — at a minimum, there is no template for playback steps, no time metrics, or other fields we need. Such a shortage did not suit us, so we also reworked the appearance of the card to fit our needs.



We added a column with time-tracking fields (Original Estimate, Remaining Work, Completed Work, Daily Work), a template was added to the playback steps to fill in HTML, and a classification of bugs according to various features appeared.

Problems and Solutions

Despite the convenience of the system, there are a number of difficulties in working with Workflow in the TFS tracker:

• There are no calculated fields - “hanging” on fields of additional logic is difficult to implement, even the transfer of time metrics from child elements to the parent ones is not provided.
• There is no multiple choice field - if in Bug or any other work item there is a client field, and an error occurs in several clients, then you cannot select them all, only one value is possible.
• An inconvenient process of changing fields and their types - if an error was made in the field name, then it cannot be corrected; a re-creation of the field with transfer of all values ​​to a new one is required.
• You cannot track changes and roll back them - all the bug templates and TFS configurations are stored as XML, loaded into databases. If you make a mistake and pour it into the database, you will not be able to roll back to the previous version. So you need to remember where and what you changed.
• Inconvenient system of rights to change workflow and lists - it is designed in such a way that if you give the user rights to change the lists of fields, he will automatically receive the rights to change the lists of the entire workflow.

We did not want to put up with these shortcomings, so we had to solve the problems that arise. Here is what we did:

• They began to use the open project TfsAggregator to calculate field logic - a handy tool for calculating time tracking fields, forwarding text values ​​from one work item to another, etc.
• WitCustomControls for the implementation of a combo box is another open source project, a Java-Script plugin that allows you to create multiple-choice fields.
• Gitlab for storing and tracking work item templates — helps track changes in configurations and gives you the opportunity to roll back to the previous version in case of an error.
• Changes to templates of work items, lists, etc. are allowed to be made only by TFS service administrators - this is done to reduce the risk of unauthorized changes to any configurations, lists, etc.

PS The story about the tools we have developed for creating distribution kits was presented as part of a DevOps mitap, which took place in the fall in Moscow.


The link presents presentations of 16 reports presented during the event. All presentations and video presentations will be added to the table at the end of this topic-announcement .

Author : Alexey Soloviev

PPS We remind you that very soon, with the support of Positive Technologies, Moscow will take a course on asyncio + aiohttp from Core developer Python Andrei Svetlov.

We want to offer one free ticket to the seminar to the author of the best question for Andrei - the question he chooses himself and will answer it during the course. Send your questions to: asyncio2016@ptsecurity.com .