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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения о триггере Расписание см. в разделе Use Schedule to queue a build on a regular interval.Дополнительные сведения о настройке запуска ночных тестов проверки построения см. в разделе Практическое руководство. Настройка и запуск запланированных тестов после построения приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совет
Если вы создаете пользовательский шаблон процесса построения и выбрали Schedule в качестве значения свойства Reason в разделе Ограничение разделов процесса построения на основе причин (триггеров) (действие InvokeForReason) шаблона, в большинстве случаев необходимо также выбрать ScheduleForced.

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

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

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

Совет
Если вы создаете пользовательский шаблон процесса построения и выбрали ScheduleForced в качестве значения свойства Reason в разделе Ограничение разделов процесса построения на основе причин (триггеров) (действие InvokeForReason) шаблона, в большинстве случаев необходимо также выбрать Schedule.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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