Пару слов об интеграции в TFS системы управления дефектами с системой управления версиями
Введение. Продолжаю удивляться делиться опытом перехода из SVN на TFS (или как правильно подметили Team Foundation Version Control (TFVC)).В предыдущем посте был описан опыт чисто системы управления версиями.В этом посте я хотел бы поделиться маленьким (но важным) сценарием использования интеграции системы «контроля версиями» с системой «управления дефектами» (или как это называется Work Item Tracking).
Один из наиболее частых (у меня, и как мне представляется у других) сценариев интеграции систем «контроля версий» и «управления дефектами» это привязка к «дефекту» релевантных изменений в «контроле версий». Часто так получается, что один «дефект» (или задача) решается с помощью нескольких изменений (ревизий).Кажется, что этот сценарий абсолютно не поддерживается SVN и отлично из коробки поддерживается TFS, по крайней мере так представляют дело продавцы от Microsoft.
В реальности мы используем в SVN простой прием, который позволяет несколько вещей: — прежде всего можно связать каждую ревизию SVN с некоторым количеством «дефектов» TFS; — и наоборот, кажый дефект можно связать с некоторым количеством ревизий; — далее в окне истории можно видеть колонку с номерами TFS дефектов для каждой ревизии; — понятно, что по клику открывается веб интерфейс дефекта; — естественно история редактируется (т.е. дефекты можно менять).
Программист когда выполняет коммит, может указать номер дефекта: 
История показывает колонку с номерами дефектов: 
История, реализованная TortoiseSVN, обеспечивает очень легкий способ нахождения всех ревизий, относящихся к конкретному «дефекту»: просто пишешь номер «дефекта» в фильтре истории и получаешь сразу все изменения данного дефекта. Отмечая отфильтрованные ревизии можно видеть сразу все файлы данных ревизий.
Не из коробки? Ну да. Может быть кустарно выглядит? Может быть.
Теперь посмотрим какой уровень интеграции я получил на TFS (контроль версий и управление дефектами). Мне известно 3 способа работы с TFS (исключая командную строку): из Windows explorer, из Visual Studio и через веб-интерфейс.
Делаем «Check in» из Windows Explorer (Power Tools 2013): Таб «Work Items» позволяет искать «дефект» по номеру только в текущем запросе. Если по какой-то причине нет запроса — нет коммита. Так что, пржде чем чекинить убедись в наличии трапа запроса, по которому можно найти «дефект».
Делаем «Check in» из Visual Studio: Студия позволяет добавить номер «дефекта» по запросу и собственно номеру.
Веб-интерфейс для данного сценария не релевантен.
Теперь как искать ревизии по номеру «дефекта»: Windows Explorer (Power Tools 2013) не имеет поиска, чтобы узнать какой «дефект» привязан к ревизии, нужно выбрать ревизию и переключить таб. Таким образом найти все ревизии данного «дефекта» не представляется возможным.
Студия так же не имеет поиска (ревизий по «дефекту»), но позволяет по «дефекту» (таб Links) узнать его ревизии. Теперь можно кликать по этим линкам, что бы увидеть какие файлы были изменены. Не нашел способа увидеть все измененные файлы (да и в Студии это просто не удобно).
Веб-интерфейс конечно более цветаст и неплох для визуализации изменений одной ревизии, но все равно не походит для нескольких ревизий.
Вывод: Power Tools выглядит убого для данного сценария. Студия выигрывает у TortioseSVN за счет запросов при чекине.Поиск и визуализация изменений (особенно когда есть несколько ревизий) существенно лучше поддерживается в TortioseSVN.Немного (или много) раздражает смена инструментов (Power Tools, Studio и web), так нет такого, который работает лучше остальных.
Замечания: — Извините за терминологию: иногда сбиваюсь.— Согласен, что я «не разобрался в TFS прежде чем использовать». Помогите разобраться.
