A few words about integrating defect management systems with TFS into TFS

Introduction

I continue to be surprised to share the experience of transition from SVN to TFS (or as correctly noted by Team Foundation Version Control (TFVC)).

In a previous post , the experience of a pure version control system was described.

In this post I would like to share a small (but important) scenario of using the integration of a “version control” system with a “defect management” system (or as it is called Work Item Tracking).





')

One of the most frequent (for me, and as I see it for others) scenarios of integrating the “version control” and “defect management” systems is binding to the “defect” of relevant changes in the “version control”. It often happens that one “defect” (or problem) is solved with the help of several changes (revisions).

It seems that this scenario is absolutely not supported by SVN and TFS is supported perfectly out of the box, at least as the Microsoft merchants present it.



In reality, we use a simple technique in SVN that allows several things:

- first of all, you can link each revision of SVN with a number of TFS “defects”;

- and vice versa, each defect can be associated with a number of revisions;

- further in the history window you can see the column with TFS defect numbers for each revision ;

- it is clear that a click on the web opens the interface of the defect;

- Of course the story is edited (ie, defects can be changed).



When a programmer performs a commit, he can indicate the defect number:





History shows a column with defect numbers:





The history implemented by TortoiseSVN provides a very easy way to find all revisions related to a specific “defect”: you simply write the number of the “defect” in the history filter and you get all the changes of the defect at once. By marking filtered revisions, you can see all the revision data files at once .



Not out of the box? Well yes. Maybe looks handicraft? May be.



Now let's see what level of integration I got on TFS (version control and defect management). I know of 3 ways to work with TFS (excluding the command line): from Windows explorer, from Visual Studio, and through the web interface.



Making “Check in” from Windows Explorer (Power Tools 2013) : The “Work Items” tab allows you to search for “defect” by number only in the current query. If for some reason there is no request, there is no commit. So, before you check, make sure that there is a query ladder by which you can find a “defect”.



Make a “Check in” from Visual Studio : Studio allows you to add a “defect” number on request and the number itself.



The web interface for this scenario is not relevant.



Now how to search for revisions by “defect” number:

Windows Explorer (Power Tools 2013) does not have a search. To find out which “defect” is tied to a revision, you need to select a revision and switch the tab. Thus, it is not possible to find all revisions of this “defect”.



The studio also does not have a search (revisions for the "defect"), but allows for the "defect" (Links tab) to find out its revisions. Now you can click on these links to see which files have been changed. I did not find a way to see all the changed files (and in the Studio it is just not convenient).



The web interface is of course more colorful and not bad for visualizing the changes of one revision, but still not suitable for several revisions.



Conclusion :

Power tools look poor for this scenario. The studio wins TortioseSVN by querying with a check.

Finding and visualizing changes (especially when there are multiple revisions) is significantly better supported in TortioseSVN.

A bit (or a lot) annoying change tools (Power Tools, Studio and web), so there is no one that works better than others.



Remarks:

- Sorry for the terminology: sometimes I go astray.

- I agree that I "did not understand TFS before using." Help me to understand.