Задание триггеров и причин выполнения сборки

Если требуется, можно поместить построение в очередь вручную, но потребностям вашей команды, как правило, будет соответствовать процесс построения, определенный с помощью автоматических триггеров. Конкретная причина, запустившая построение, записывается в свойство Reason. В этом разделе описывается и объясняется использование всех триггеров построения и причин выполнения построения, доступных при создании определения построения.

• Использование триггеров для решения задач команды

  • Защита от прерывания построения

  • Обеспечение качества с помощью непрерывной интеграции

  • Проверка качества продукта с помощью запуска ночных тестов проверки построения

• Использование автоматических триггеров построения

  • Использование триггера непрерывной интеграции для помещения построения в очередь при возврате изменений

  • Использование триггера последовательного построения для помещения построения в очередь при возврате изменений с учетом ограничений на частоту выполнения построения

  • Использование триггера прокрутки построений для помещения построения в очередь при попытке возврата изменений членом команды с учетом ограничений на частоту выполнения построения

  • Использование запланированного триггера для помещения построения в очередь через постоянные интервалы

• Помещение построения в очередь вручную

  • Помещение построения в очередь

  • Помещение частного построения в очередь

• Использование пользовательского кода для помещения построения в очередь

• Работа с триггерами и причинами выполнения построения

Использование триггеров для решения задач команды

Защита от прерывания построения

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

Обеспечение качества с помощью непрерывной интеграции

Непрерывная интеграция — это методика, предполагающая как можно более частую интеграцию кода в общее хранилище. В процессе интеграции кода прерывание построения или ошибка тестирования своевременно указывают на ошибку в коде. Триггер Непрерывная интеграция используется для реализации непрерывной интеграции. Триггер Последовательные построения аналогичен триггеру Непрерывная интеграция и может быть полезен, если система построения недостаточно мощна, чтобы выполнять построения после каждого возврата.

Триггер Условный возврат позволяет организовать более строгий подход к непрерывной интеграции. Триггер Непрерывная интеграция предупреждает команду о проблемах, например о прерываниях построений или завершившихся ошибкой основных модульных тестов, в то время как триггер Условный возврат предотвращает попадание кода, вызывающего подобные проблемы, в базу кода.

Дополнительные сведения о том, как использовать систему построения для поддержки непрерывной интеграции см. в разделе Настройка сборки CI.

Проверка качества продукта с помощью запуска ночных тестов проверки построения

Для оценки качества построения можно запланировать регулярные тестовые запуски. Эти тесты называются тестами проверки построения или тестами состояния. Эти тесты состоят из широкого набора тестов и предназначены для проверки основных областей приложения того или иного построения. Триггер Расписание можно использовать для реализации запуска ночных тестов проверки построения.

Дополнительные сведения о триггере Расписание см. в разделе Use Schedule to queue a build on a regular interval.

Использование автоматических триггеров построения

Необходимо задать триггер построения для определения построения. В большинстве случаев требуется, чтобы процесс построения запускался автоматически. Для этого можно использовать один из автоматических триггеров, описанных в данном разделе.

Использование триггера непрерывной интеграции для помещения построения в очередь при возврате изменений

Если сборка определена с использованием триггера Непрерывная интеграция, она помещается в очередь каждый раз, когда один из членов команды возвращает изменения. Рабочая область определения построения определяет, для каких файлов срабатывает триггер. Дополнительные сведения о рабочих областях построений см. в разделе Работа с рабочими областями сборок.

Свойство Reason построения, запущенного триггером Непрерывная интеграция, равно IndividualCI.

Использование триггера "Прокрутка сборок" для совместной сборки нескольких возвратов через определенный промежуток времени

Если сборка определена с использованием триггера Прокрутка сборок, система сборки ставит в очередь сборку каждого возврата, пока сборка не будет запущена. При выполнении сборки система ожидает завершения сборки, а затем ставит в очередь другую сборку всех возвратов, сборка которых еще не выполнена. Можно также ограничить частоту выполнения сборок. Для этого установите флажок Выполнять сборку не чаще, чем каждые N минут и укажите целое число от 0 до 2147483647.

Например, можно использовать один агент сборки, который будет завершать сборку каждые 20 минут. Если вы используете триггер Непрерывная интеграция и команда возвращает код 9 раз с 10 до 11 часов утра, последний возврат, возможно, не будет собран до 13 часов. Однако если вы используете триггер Прокрутка сборок и указываете интервал 60 минут, тот же набор возвратов, возможно, будет создан к 11:20.

Рабочая область определения построения определяет, для каких файлов срабатывает триггер. Дополнительные сведения о рабочих областях построений см. в разделе Работа с рабочими областями сборок.

Свойство Reason построения, запущенного триггером Последовательное построение, равно BatchedCI.

Использование триггера прокрутки построений для помещения построения в очередь при попытке возврата членом команды изменений с учетом ограничений на частоту выполнения построения

Этот триггер можно использовать только в командных проектах TFVC ; он не доступен в командных проектах Git .

Если сборка определена с использованием триггера Условный возврат, изменения, которые член команды возвращает в систему управления версиями, помещаются в набор отложенных изменений и в очередь на сборку. Для завершения возврата построение должно пройти успешно. Параметр Рабочая область определения построения определяет, какие файлы управляются определением построения. Дополнительные сведения о рабочих областях построений см. в разделе Работа с рабочими областями сборок.

Свойство Reason построения, запущенного триггером Условный возврат, равно CheckInShelveset.

Дополнительные сведения о реализации триггера Условный возврат см. в разделе Использование процесса сборки с условным возвратом для проверки изменений. Дополнительные сведения о том, каким образом этот тип определения построения затрагивает вашу команду см. в разделе Возврат ожидающих изменений под управлением построения с условным возвратом.

Использование запланированного триггера для помещения построения в очередь через постоянные интервалы

Триггер "Расписание"

Если сборка определена с использованием триггера Расписание и флажок Построить, даже если ничего не изменилось со времени предыдущей сборки не установлен, она помещается в очередь в выбранный день и время, если после предыдущего запуска этого определения сборки были возвращены изменения. Построение помещается в очередь вне зависимости от того, были ли изменения связаны с последним работоспособным построением.

Свойство Reason построения, запущенного таким образом, будет равно Schedule.

Совет

Если вы создаете пользовательский шаблон процесса сборки и в разделе InvokeForReason шаблона задаете свойству Причина значение Schedule, в большинстве случаев также необходимо выбрать ScheduleForced.

Триггер "Расписание" (Reason: ScheduleForced)

Если сборка определена с использованием триггера Расписание и флажок Построить, даже если ничего не изменилось со времени предыдущей сборки установлен, сборка помещается в очередь в выбранный день и время. Построение помещается в очередь вне зависимости от того, были ли возвращены изменения.

Свойство Reason построения, запущенного таким образом, будет равно ScheduleForced.

Совет

Если вы создаете пользовательский шаблон процесса сборки и в разделе InvokeForReason шаблона задаете свойству Причина значение ScheduleForced, в большинстве случаев также необходимо выбрать Schedule.

Помещение построения в очередь вручную

В некоторых случаях не требуется, чтобы процесс построения запускался автоматически.

• Например, определение построения может находиться в разработке и быть не готово для автоматического выполнения.

• Можно создать специальный процесс построения, который требуется запускать только вручную.

В этом случае следует выбрать триггер Вручную. Определение построения будет запущено, только когда член команды запросит это вручную.

Помещение построения в очередь

Вручную можно поместить в очередь любое определение построения, даже если оно определено с иным триггером, нежели Вручную. При ручном запуске построения значение параметра Reason будет равно Manual. Дополнительные сведения о том, как вручную помещать построение в очередь, см. в разделе Помещение сборки в очередь.

Помещение частного построения в очередь

Если требуется выполнить построение для изменений, помещенных в набор отложенных изменений, можно использовать частное построение (также называемое дружественным построением) для проверки изменений с кодом до возврата. При ручном запуске частного построения значение параметра Reason будет равно ValidateShelveset. Дополнительные сведения о том, как вручную помещать частное построение в очередь, см. в разделе Помещение сборки в очередь.

Использование пользовательского кода для создания завершенного построения

Можно разработать пользовательский код, создающий завершенное построение, используя классы пространства имен Microsoft.TeamFoundation.Build. Если построение помещено в очередь таким образом, значение параметра Reason будет равно UserCreated. Дополнительные сведения см. в разделе Расширение Team Foundation: сборка

Работа с триггерами и причинами выполнения построения

Триггеры и причины запуска построения можно использовать в процессе построения следующими способами:

• Задать триггер для процесса построения. В определении построения перейдите на вкладку Триггер и выберите триггер, отвечающий вашим требованиям. Дополнительные сведения о создании нового определения построения см. в разделе Создание или изменение определения сборки.

• Использовать причины запуска построения в пользовательском процессе построения. Можно заключить в действие InvokeForReason ту часть пользовательского процесса построения, которую требуется выполнять, только если построение было запущено по определенной причине. Дополнительные сведения см. в разделе Операции Team Foundation Build: InvokeForReason.