Поля, поддерживающие интеграцию с тестированием, сборками и управлением версиями

Можно настроить типы рабочих элементов, чтобы включить в них сведения, создаваемые автоматическими процессами. Для этого необходимо добавить поля, которые интегрируются с Team Foundation Build, Microsoft Test Manager и Team Foundation (подсистема контроля версий). 

Поля, которые интегрируются с Team Foundation Build

Team Foundation Build— это система автоматизированной сборки Team Foundation Server. Процесс сборки можно настроить, используя Team Foundation Build. Team Foundation Build может создавать рабочие элементы в случае сбоя сборки. Кроме того, этот компонент добавляет сведения о сборке в рабочие элементы, разрешенные в конкретной сборке. Для работы этой функции Team Foundation Build требует, чтобы в определение типа рабочего элемента были добавлены следующие два поля: Найдено в и Сборка интеграции.

В шаблонах процессов по умолчанию, предоставляемых Team Foundation Server, поля Найдено в и Сборка интеграции отображаются в определениях типов для ошибок. Эти поля связывают ошибки со сборками, в которых они обнаружены или исправлены. Можно использовать следующий фрагмент кода для добавления этих полей в определение типа рабочего элемента.

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>

Если в определении типа рабочего элемента присутствует поле Найдено в, Team Foundation Build создает рабочий элемент при сбое сборки и задает для поля Найдено в номер той сборки, в которой возникла ошибка. Если поле Найдено в отсутствует, Team Foundation Build не создает рабочий элемент для сборки со сбоем и все остальные компоненты работают, как ожидалось.

Если поле Сборка интеграции присутствует в определении типа рабочего элемента, Team Foundation Build определяет рабочие элементы, которые были разрешены в каждой сборке. Затем Team Foundation Build обновляет эти рабочие элементы, задавая для них номер сборки, в которой они были разрешены, в поле Сборка интеграции. Если поле Сборка интеграции отсутствует, Team Foundation Build не сохраняет номер сборки в рабочих элементах и все остальные компоненты работают, как ожидалось.

Ассоциации сборки с наборами изменений и рабочими элементами

Стандартная сборка, основанная на шаблоне сборки по умолчанию, связывает наборы изменений и рабочие элементы со сборками. Процедура следующая: сначала извлекается метка предыдущей успешной сборки для определения данной сборки, затем определяется, какие наборы изменений имеются в текущей сборке, но не были включены в предыдущую. Некоторые или все наборы изменений могут включать связанные с ними рабочие элементы. Эти рабочие элементы связываются со сборкой. Эта процедура выполняется в составе действия AssociateChangesetsAndWorkItems.

Автозаполнение списка сборок и глобального списка

При первом помещении сборки для командного проекта в очередь с помощью Team Foundation Build TFS автоматически добавляет глобальный список с меткой "Build — <имя командного проекта>". При каждом запуске сборки в этот глобальный список добавляется элемент LISTITEM с именем сборки.

Добавив элемент GLOBALLIST в определение FIELD, можно предоставить пользователям раскрывающееся меню сборок. Например:

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
        <SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
          <GLOBALLIST name="Builds - TeamProjectName" />
        </SUGGESTEDVALUES>
</FIELD>

Поля, которые интегрируются с Microsoft Test Manager

Используя Test Manager, можно автоматизировать создание ошибок или других типов рабочих элементов при сбое теста. Для получения дополнительной информации см. Отправка ошибок в Microsoft Test Manager.

Когда рабочий процесс создается таким образом, сведения о системе и действия по воспроизведению ошибки записываются в поля Сведения о системе и Шаги для воспроизведения.

Эти поля можно добавить в создаваемые типы рабочих элементов для отслеживания дефектов, используя следующий фрагмент кода:

<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" />
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML" />

Дополнительные сведения о дополнительных полях, используемых Test Manager, см. в разделе Справочник по полям интеграции сборки и тестирования.

Поля, которые интегрируются с компонентом управления версиями Team Foundation

Один из компонентов, доступный в Team Foundation (подсистема контроля версий), позволяет связывать или разрешать рабочие элементы при возврате кода. Если вы работали с определенным рабочим элементом при внесении изменений в код, вы можете задать эту ассоциацию в окне возврата системы управления версиями, когда завершите работу над кодом.

Возможность Team Foundation (подсистема контроля версий) разрешать рабочий элемент зависит от наличия в рабочем элементе определенного действия. Система управления версиями отправляет запрос в компонент отслеживания рабочих элементов, чтобы определить, поддерживает ли рабочий элемент это действие. Если это так, система также отправляет запрос исходного и конечного состояний транзакции. Если действие удается найти, система управления версиями может выполнить для рабочего элемента переход согласно заданным параметрам при выполнении возврата кода.

Примечание

При использовании действия Checkin необходимо задать соответствующие состояния "из" и "в", отражающие необходимое состояние перехода.

Дополнительные сведения о действиях см. в разделе Автоматизация назначений полей на основе состояния, перехода или причины.

Пример действия "Возврат"

<TRANSITION from="Active" to="Resolved">
....
    <ACTIONS>
        <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
    </ACTIONS>
....  
</TRANSITION>

Вопросы и ответы

В: Какие другие поля связаны со сборками и Test Manager?

Ответ. Дополнительные поля см. в статье Справочник по полям интеграции сборки и тестирования.

См. также

Задачи

Какие изменения были внесены по сравнению с предыдущей сборкой?

Другие ресурсы

Определение полей рабочих элементов