Каково точное использование триггеров непрерывной интеграции Run для зафиксированных изменений и других функций в TFS 2017 Gated Build? - PullRequest
1 голос
/ 29 мая 2020

Меня немного смущают параметры, представленные в сборке TFS 2017 в разделе «Триггеры». У меня есть два отдельных определения сборки, одно используется для проверки кода, то есть называется Gated Build, а другое - это сборка вручную, которую мы использовали для удаления \ развертывания кода на наших серверах CI после завершения сборки Gated.

Недавно мы подумали об использовании определений сборки Gated непосредственно для удаления кода, что сэкономит время при запуске сборок вручную по отдельности. Однако при выполнении этого заказа C меня смущает использование различных функций, доступных в разделе «Триггеры», особенно триггеров непрерывной интеграции Запуск для зафиксированных изменений

Я связал Gated Собирайте напрямую с определением выпуска, которое развертывает код после завершения закрытой сборки. Я выбрал обе опции в сборке, т.е. Использовать сопоставление рабочей области для фильтров и Запускать триггеры непрерывной интеграции для зафиксированных изменений . При этом всякий раз, когда я регистрирую код, после завершения сборки запускается определение Release и развертывается код на сервере, но когда я отменяю выбор Запускать триггеры непрерывной интеграции для зафиксированных изменений и регистрирую код, он все еще разворачивает код только потому, что он связан с определением выпуска.

Я искал в Google и пытался понять, как его использовать и другие функции, но мало что понял, я прошел по ссылке , также просто узнал, что она не будет отображаться НЕТ CI в наборе изменений.

Может ли кто-нибудь объяснить точное использование каждой функции \ опции, присутствующей в триггерах, кроме запланированной, или, пожалуйста, дайте мне знать, есть ли какие-либо другие ссылки, блоги, видеоуроки, любой, кто знает, где все функции присутствующие в параметрах триггера подробно объясняются с примерами? enter image description here

Включена опция «Непрерывная интеграция» в сборке CI, благодаря которой она автоматически запускается после завершения стробированной сборки. enter image description here

1 Ответ

1 голос
/ 01 июня 2020

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

  • Для нормальной сборки CI она будет строиться всякий раз, когда кто-то проверяет код, это происходит после того, как изменения были зарегистрированы в TFS.
  • Если вы выберете Gated check-in, он будет принимать регистрацию только в том случае, если отправленные изменения объединяются и собираются успешно, что означает, что только сборка завершилась успешно, изменения могут быть зарегистрированы.

По умолчанию сборки CI не запускаются после закрытой проверки. в процессе завершен, и изменения регистрируются. Однако, если вы делаете хотите, чтобы сборки CI запускались после закрытой регистрации, выберите Запуск триггеров непрерывной интеграции для зафиксированных изменений проверка коробка.

Более подробную информацию обо всех триггерах вы можете найти по нашей официальной ссылке ниже:

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops

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


Что касается того, почему check-in an code it still deploys the code just because it is linked with the Release definition. Этот триггер управляет только вашим определением сборки / конвейером, но не влияет на конвейер выпуска.

Также имеется соответствующий Триггер выпуска . Вы должны дважды проверить это в своей среде.

Образец использования Gated Build в Azure DevOps вы можете найти в этом блоге - Gated Check-ins в Visual Studio Team Services с использованием TFSV C и Git

...