В прошлый раз я рассказал о том, как, на мой взгляд, должны выглядеть карты процессов для пользовательской истории, задачи, бага (UserStory, Task, Bug). В этот раз я хочу рассказать, как все это настроить в Visual Studio. Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.
После установки TFS Power Tools, в VS должен появиться новый пункт в меню Tools.
На скриншоте уже показано, что необходимо сделать для того, чтобы начать редактировать элементы задач. Tools > Process Editor > Work Item Types > Open WIT from Server. Такой выбор позволит сразу получить изменения на сервере. В целом все пункты последнего меню говорят сами за себя и с минимальными экспериментами можно получить представление об их действии.
После выбора элемента Open WIT from Server вам будет предложено выбрать TFS Server для подключения, после чего вы увидите свои коллекции проектов и собственно сами проекты. Необходимо выбрать проект в котором вы желаете сделать изменения и далее будет финальный шаг – выбор элемента для редактирование.
В качестве подопытного элемента можем взять Task.
При открытии вы увидите экран с настройками полей элемента Task, нас же на данном этапе интересует закладка Workflow.
На закладке Workflow можно увидеть стандартный вид и расположение элементов State и Transition.
Отлично, теперь обращаем внимание на Toolbox и доступные элементы не смогут смутить ваш ум обилием выбора, так как там только два элемента, которые нам понадобятся.
Естественно, перед тем, как приступать к работе, было бы неплохо нарисовать на бумаге или определить для себя желаемый порядок состояний и причины перехода, определиться с правилами перехода. Будем считать, что у нас уже есть такой порядок по предыдущей статье. Т.е. мы в итоге хотим получить что-то похожее на:
Первым нюансом, на который хочу обратить ваше внимание, будет создание начального состояния. По правилам схемы должен быть хотя бы один Transition Link элемент без начального состояния. На схеме это переход к состоянию Proposed. В данном моменте могут появиться сложности, если создавать предстоящие состояния и новые переходы, и начинать схему с них. Каким-то образом из-за состояний или же истории состояний схема может не сохранятся. Так что мой совет, сохранятся чаще, после каждых элементарных действий.
Если у вас возникли сложности с созданием нового начального состояния, то рекомендую сначала создать промежуточное состояние с новыми переходами, сохранить его. Затем уже старое начальное состояние перевести на новый элемент. Чаще всего это позволяет решить проблему. Так же это может возникать из-за текущего состояния рабочих элементов в самой базе TFS.
Начнем с простого, добавим состояние Hold к нашей диаграмме состояний. На панели инструментов выбираем State и перетягиваем в удобное место. Вообще старайтесь располагать элементы так, чтобы линии не пересекались, это затрудняет чтение.
После того как перетянули элемента состояния State, можно с помощью двойного клика изменить название состояния. Однако будьте точны и внимательны. Двойной клик за пределами названия, приведет к открытию редактора правил для заполнения полей рабочего элемента. Введенное название вы будете видеть при редактировании задач в поле State. На данном этапе нам не нужно будет менять состояния других полей при попадании в это состояние, так что можно перейти к составлению переходов.
Выбираем Transition Link и выбираем стартовую и конечную точки перехода.
Появляется новый элемент перехода. Если попытаться сохранить схему сейчас, то вы получите ошибку, даже две.
«Основной» ошибкой, на которую хочу обратить внимание, является: Open Transition Hold~Active to add at least one Reason. Вторая ошибка тоже важна, указывает на недостижимость состояния, чего не должно быть. Итак, каждый переход к состоянию обязан иметь причину перехода.
Для устранения данной ошибки следует осуществить двойной клик по заголовку элемента перехода, чтобы появилось такое окно:
Данное окно не модальное, так что будьте внимательны, его легко потерять за другими окнами. И оно не «привязывается» к значку студии в панеле задач, как другие студийные окна. Посмотрите на скриншот ниже
Можно заметить, что нет двойной рамки, как скажем у Word. Хотя окно редактирования перехода открыто.
Итак, на появившемся окне нам потребуется вторая закладка Reason, на которой мы сможем ввести обязательные данные.
Отредактировать значения можно либо нажав на Edit, либо по двойному нажатию на выделенную строку. Как видно из интерфейса можно указывать значение по умолчанию. При начале редактирования появится новый экран по размерам полностью совпадающий с первым и перекрывающий его. Оно так же не модальное и все эти окна очень легко потерять.
Вторая закладка нам пока что не потребуется. Но на ней можно настроить некоторые правила для других полей задачи.
Добавление/удаление новых причин/условий перехода происходит по нажатию соответствующих кнопок.
Переключение значений по умолчанию не производится с этого экрана а требует входа в режим редактирования условия.
При этом валидации на наличие двух элементов с маркером «по умолчанию» не происходит, так что будьте внимательны. Итогом становится такой вид:
Здесь я уже добавил еще один переход от Active к Hold и задал условие. После этого все хорошо сохраняется.
Рассмотрим дальнейшие возможные изменения при переходах от одного состояния к другому. Допустим, после перехода от состояния Hold к состоянию Active. Пусть мы хотим поменять значения некоторых полей, или же гарантировать их неизменность.
Для этого снова открываем элемент перехода для редактирования и переходим к закладке Fields.
При добавлении нового поля получаем новый экран, где можно выбрать поля для заполнения. На скриншоте зеленым помечены поля для построения достаточно сложных условий, с красными полями возможны только базовые проверки. К сожалению, большая часть правил проверяется методом научного тыка.
Например, я хочу чтобы во время перехода из одно состояние в другое поле AreaPath не потеряло своего значения. Для этого я выбираю из выпадающего списка интересующее поле.
Перехожу к редактированию его правил:
Выбираю правило
Затем появляется окно с запросом для каких групп пользователей оно будет действовать. Если оставить поля пустыми, то будет работать для всех
После чего жму ОК во всех окнах, пока они не исчезнут. В результате получим вид как на скриншоте:
Если попробовать сохранить, то получим такое вот предупреждение.
Побороть такое если и можно, то сложно, и надо писать дополнительные библиотеки, чем я пока не занимался. Ну и к тому же возможно это лучше организовывать с помощью других средств, как скажем TFS Aggregator. Это скорее тема отдельной статьи. Но для всех полей из пространства Microsoft.VSTS.* правила будут работать. В этом можно убедиться, посмотрев на другие состояния. Поле для экспериментов в целом есть!
Внимательные и опытные читатели наверно заметили, что для некоторых переходов заполнено поле Action, и если вспомнить, то при выполнении Check-In элемент автоматически переходит в другое состояние. К сожалению по умолчанию доступно только событие Microsoft.VSTS.Actions.Checkin. Эти события являются только маркерами для срабатывания других компонентов TFS. К сожалению, в MSDN нет информации как реализовать свои события, как написать свой компонент, который будет откликаться/читать такие значения из раздела Actions в переходе. Хотя это было бы полезно. Например, когда младшие разработчики не чекинят код в основную ветку, а кладут код на полку, в результате чего задача переходит в состояние Need Review.
В целом это почти все возможности по настройке диаграммы состояний. Все остальное только повторение указанных действий. Надеюсь это поможет вам в реализации ваших задумок по улучшению процесса разработки.
Автор: VioletTape
