Personal experience: organizing Workflow in the TFS tracker



    We continue to talk about development processes at Positive Technologies. Earlier, we touched on the creation of product distributions , the organization of the process of storage and licensing of 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 development workflow.

    A bit about TFS


    Team Foundation Server consists of several components.

    Version control system: Task tracker: Continuous integration system: For our company, TFS is primarily a task tracker that most teams use. The second most popular use case is the version control system, in which not many projects are stored, but all of them are actively developed. By the residual principle, we use TFS as an assembly system for the 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 — including custom — types of tasks are supported: Bug, Task, Feature, User Story, etc. It is also worth noting a flexible system for changing Workflow tasks.

    The basic Workflow for the Bug task in TFS is as follows: We see n statuses - start, end, and state transitions. As a rule, few people work on the basic workflow - there is always a need to expand it. The modified process in our case may look something like this:









    The Workflow extension was accomplished by adding new statuses and renaming existing ones. For example, 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 into work, and Commited was renamed to Resolved, meaning that the task was solved and confirmation of its completion is required, or additional work on it is required.

    The appearance of the Bug card is similarly changed. At the very beginning after creating the project, it looks like this:



    In its basic form, the system provides a little information - at least there is no template for the playback steps, no time metrics and other fields that we need. Such a deficit did not suit us, so we also redesigned the appearance of the card to fit our needs. We added a column with fields for time tracking (Original Estimate, Remaining Work, Completed Work, Daily Work), a template for filling HTML was added to the playback steps, and a classification of bugs by various characteristics appeared.





    Problems and Solutions


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

    • There are no calculated fields - “hanging” on additional logic fields is difficult to implement, even the transfer of time metrics from child elements to parent elements is not provided.
    • There is no multiple choice field - if there is a client field in Bug or any other work item, and several clients encounter an error, then you cannot select all of them, 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, it is necessary to recreate the field with the transfer of all values ​​to a new one.
    • You cannot track changes and roll them back - all bug templates and TFS configurations are stored as XML, loaded into the databases. If you make a mistake and fill it into the database, then you won’t be able to roll back to the previous version. So you need to remember yourself where and what you changed.
    • An inconvenient system of rights for changing workflows and lists - it is arranged in such a way that if you give the user rights to change lists of fields, then he will automatically receive rights to change lists of the entire workflow.

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

    • We began to use the open TfsAggregator project for calculating field logic - a convenient tool for calculating time tracking fields, forwarding text values ​​from one work item to another, etc.
    • WitCustomControls for implementing 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 makes it possible to roll back to a previous version in case of an error.
    • Changes to the templates of work items, lists, etc. are allowed only to the 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 developed for creating distributions was presented as part of the DevOps-meeting, 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 Solovyov

    P. PS We remind you that soon with the support of Positive Technologies in Moscow a course on asyncio + aiohttp from Python core developer Andrei Svetlov will be held.

    We want to offer one free ticket to the seminar to the author of the best question for Andrey - he will choose the question and answer it during the lesson. Send your questions to asyncio2016@ptsecurity.com .

    Also popular now: