Автоматизация назначений полей на основе состояния, перехода или причины
В некоторых случаях может потребоваться автоматический переход рабочих элементов между состояниями на основе событий, которые происходят где-либо в Visual Studio Application Lifecycle Management (ALM) или за пределами Visual Studio ALM.Например, может потребоваться автоматический переход ошибки между состояниями на основе событий, происходящих в средстве отслеживания вызовов.Модель типа рабочего элемента и API-интерфейс отслеживания рабочих элементов расширены и включают поддержку автоматического перехода рабочих элементов между состояниями по команде других систем.
При наличии кода, который изменяет состояние рабочего элемента, можно обобщить этот код, связав действие с соответствующим переходом между состояниями, воспользовавшись элементом ACTION.Значение действия можно передать методу [WorkItem.GetNextState], чтобы получить состояние рабочего элемента после действия.В диалоговом окне возврата системы управления версиями этот метод используется для разрешения ошибок и закрытия задач, связанных с возвратом.
ACTION является необязательным дочерним элементом для ACTIONS.
.gif "Примечание") Примечание |
|---|
API отслеживания рабочих элементов входит в состав пакета SDK для Visual Studio ALM, описанного на следующей странице веб-сайта Майкрософт: Extending Team Foundation. |
Например, средство настроено на автоматический перевод рабочего элемента в состояние "Решено" после того, как пользователь вернет изменение в хранилище.Будучи поставщиком интеграции, вы не знаете, какое состояние разработчик типа рабочего элемента объявил как "Решено"Это может быть "Решено", "Закрыто", "Выполнено", "Готово к тестированию", "Включить в построение" и т. д.Один из вариантов — потребовать от всех разработчиков типов рабочих элементов включить состояние с явным именем "Решено".
Это решение накладывает излишние ограничения.Оно также несовместимо с перспективой глобализации, так как не позволяет локализовать названия состояний.Вместо этого системные интеграторы могут объявить такое действие, как "Возврат" или "Готово", которое вызывает автоматический переход рабочих элементов.Затем разработчик типа рабочего элемента может объявить это действие в соответствующем переходе.
Содержание раздела
Синтаксис элемента ACTION
Обязательные шаги по поддержке автоматизации
Связывание изменения состояния с действием
Подробности действия перехода
Проверка ошибок автоматического перехода
Синтаксис элемента ACTION
Для элемента ACTION используется следующий синтаксис.Значение атрибута задает имя действия и является обязательным.При именовании действий необходимо следовать тем же правилам, что и при задании ссылочных имен полей.Например, Team Foundation (подсистема контроля версий) использует Microsoft.VSTS.Actions.CheckIn для определения перехода, который подходит для рабочих элементов, связанных с возвратом.Дополнительные сведения см. в разделе Соглашения об именовании объектов отслеживания рабочих элементов.
<ACTION value="NameOfAction" />
minOccurs="0"
maxOccurs="unbounded"
Обязательные шаги по поддержке автоматизации
Для интеграции средства с системой отслеживания рабочих элементов это средство должно выполнять следующие шаги:
Определение состояния, в которое должен перейти рабочий элемент при выполнении действия.
Установка рабочего элемента в состояние "to".
API-интерфейс отслеживания рабочих элементов содержит методы для выполнения этих шагов.API отслеживания рабочих элементов является частью пакета Visual Studio ALM SDK.Дополнительные сведения см. на следующей странице веб-сайта Майкрософт: Team Foundation Server SDK.
ПримечаниеДействие транзакции, которая вызвала определенный переход состояния, не фиксируется.Если необходимо отследить действие, которое вызвало переход, можно указать дополнительное поле рабочего элемента для отслеживания или определить значение причины.
К началу
Связывание изменения состояния с действием
Для автоматизации изменений состояний рабочих элементов на разных стадиях рабочего процесса, можно использовать действия изменения состояния.Например, система управления версиями Team Foundation Server должна поддерживать автоматическое изменение состояния рабочих элементов во время возврата.Для этой цели определено действие "microsoft.vsts.actions.checkin".
Создатель типа рабочего элемента может определить тип состояния рабочего элемента "Defect" с состоянием "Working" и использовать его, когда разработчик вносит изменения.Создатель типа рабочего элемента может определить другой тип состояния рабочего элемента "Ready To Build," означающий, что разработчик объявил код, на который воздействовала неполадка для готовности к построению.
Создатель может автоматически изменить состояние рабочего элемента с "Working" на "Ready To Build" во время операции возвращения, объявив следующее:
<TRANSITION from="Working" to="Ready To Build">
<ACTIONS>
<ACTION value="microsoft.vsts.actions.checkin"/>
</ACTIONS>
</TRANSITION>
К началу
Подробности действия перехода
Используйте действия перехода для автоматизации перехода рабочих элементов на различных стадиях рабочего процесса.О действиях перехода следует знать следующее:
Действия перехода являются необязательными.Если текущее состояние экземпляра рабочего элемента содержит запись действия для указанного действия, возвращается состояние «to».В противном случае возвращается значение Null.Интеграции должны обрабатывать возвращаемые значения Null.То есть:
Не давать сбои.
Вести трассировку или журнал, указывающий, что при интеграции не осуществлялся автоматический переход, поскольку требуемое действие не было найдено.
Для каждого типа рабочего элемента, действия для пар «Из состояния/Действие» должны быть уникальными.Это означает, что авторы типов рабочих элементов не могут указать множество состояний «to» для одного действия.
Однако множественные действия над одним переходом поддерживаются, чтобы сделать возможными множественные автопереходы, как показано в следующем примере:
<TRANSITION from="Working" to="Ready To Build"> <ACTIONS> <ACTION value="Microsoft.VSTS.Actions.Checkin"/> <ACTION value="ADatum.Actions.Complete"/> </ACTIONS> </TRANSITION>Названия действий являются программными именами, для которых можно использовать только буквы английского алфавита.
Имена действий должны следовать тому же соглашению для пространства имен, что и ссылочные имена полей, во избежание конфликтов имен действий между поставщиками и клиентами.Соблюдение этого соглашения, однако, системой не обеспечивается.В Visual Studio ALM используются имена Microsoft.VSTS.Actions.<your action>.
К началу
Проверка ошибок автоматического перехода
Интеграторы могут пытаться выполнять два типа автоматического перехода.Первый тип автоматического перехода происходит в ответ на действие пользователя.Второй производится при выполнении автоматизированной операции, такой как вечернее построение.
Автоматические переходы в ответ на действие пользователя Для данного вида автоматического перехода присутствует пользователь и осуществляется реакция на проблему, связанную с правилом.Необходимо убедиться в наличии поддержки ситуации, когда автор рабочего элемента добавляет обязательное поле, которое не распознается интеграцией.Для поддержки таких ситуаций выполняйте автоматический переход и затем проверяйте тип рабочего элемента для нарушения правила.В случае нахождения отобразите форму для разрешения пользователем.
Автоматические переходы без участия пользователя Необходимо предположить, что пользователь присутствует для разрешения этих проблем.В этом случае интеграция должна завершиться документированной ошибкой.В журнал событий следует записать, что была предпринята попытка автоматического перехода, и из него должна быть ясна причина сбоя.
При определении любого типа автоматического перехода определите переход, чтобы каждый рабочий элемент достигал допустимого состояния в конце перехода, не требуя вмешательства пользователя.Иными словами, все правила, определенные для состояния, в которое осуществляется переход, удовлетворяются путем предоставления значений по умолчанию или скопированных значений для всех полей.Если какое-либо поле после перехода становится недействительным, переход состояния завершается неудачей.
Для того чтобы поля не стали недействительными, выполните следующее:
Определите значение DEFAULTREASON для перехода состояния.
Для полей, которые становятся обязательными после перехода состояния, используйте для определения значения поля элементы правил DEFAULT и COPY.
Например, следует создать действие перехода "Возврат", осуществляющее перевод рабочего элемента из состояния "Идет работа" в состояние "Готов к построению".Правила рабочего элемента для «Готов к построению» требуют, чтобы было задано поле «Кем разрешено».Поэтому затем необходимо определить элемент правила DEFAULT или COPY для поля "ResolvedBy" в разделе TRANSITION.Дополнительно нужно будет определить значение DEFAULTREASON, чтобы обязательное поле гарантированно задавалось без вмешательства пользователя.
К началу
См. также
Основные понятия
Когда и где применять правило поля