В чем разница между зависимостью моментального снимка и триггером готовой сборки в TeamCity?

Question

Мне кажется, что функция зависимостей моментальных снимков полностью заменяет функцию завершенного триггера сборки в TeamCity. Может ли кто-нибудь объяснить больше эффект этих методов, если они приводят к различным цепным поведением? Например, если у меня была цепь сборки A-> B

Действительно ли цепочка ведет себя по-разному между этими тремя установками?

• Установка 1: Один законченных сборки триггер A в B.
• Установка 2: Одиночная зависимость снимка A в B.
• установка 3: Оба законченных сборки триггера A и снимки зависимость Определенного в B.

Я понимаю, что можно рассматривать зависимость от моментального снимка как «И» для всех зависимых лиц, в то время как законченный триггер работы работает как «ИЛИ» между зависимыми. Но в контексте последовательной цепи есть ли разница?

Спасибо, Скотт

Answer 1

Как вы сказали, что есть большая разница, если конфигурационный снимок, зависит от нескольких других конфигов (Z снимок, в зависимости от Х и Y). Но вас это не интересует ...

Это правда, что в тривиальном сценарии A-> B установки 1 .. 3 близки к эквиваленту. Конечно, только если события, которые вызывают A и B, являются взаимно-однозначными (например, оба A и B запускаются в одном корне VCS, или они используют разные корни VCS, но запускаются только вручную). Если это так, то ваша цепочка A-> B является супер-тривиальной и может быть реализована в рамках единой конфигурации сборки.

Другие тонкие различия, которые приходят на ум:

1. Попутный параметров вниз по цепочке.

   • Предположим, что A и B имеют определенный пользовательский параметр «foo». Зависимость моментального снимка A-> B позволяет определить %foo% в A и повторно использовать его в B, используя %dep.A.foo%. Это очень удобно, потому что вам не нужно беспокоиться о сохранении значения %foo% в синхронизации между A и B.
   • Теперь предположим, что вы хотите вручную запустить цепочку A-> B с пользовательским значением %foo% (вы ' ll укажите значение в диалоговом окне «Выполнить ...»).
   • Поскольку TC не может передать значение до цепи (от B до A), вы должны действительно активировать A и указать там настраиваемое значение. Когда A закончит, он вызовет B, который обгонит пользовательское значение. Это Setup 3.
   • Вы не можете достичь этого с помощью Setup 2, то есть путем запуска B с пользовательским значением. У пользовательского значения не было бы доступа к A.

2. Планирование.

   • Предположим, что у вас ограниченный ресурс, и B не может запускаться для каждой фиксации. В итоге вы получаете каждый пробег B, содержащий «(покрытие) нескольких коммитов VCS. В то же время у A нет проблем для каждой фиксации.
   • В Setups 1 и 3, если у вас есть VCS триггер A, вы будете в конечном итоге с
     • Заурядный А для каждой фиксации
     • пробег B с "агрегировать" совершает (каждый запустить покрытие несколько изменений)
   • в Setup 2, если у вас есть VCS триггер B только, вы будете в конечном итоге с агрегированным фиксаций в как а и В. Что может или не может быть то, что вы хотите ...

3. Различные корни VCS.

   • Если A и B имеют разные корни VCS, то программа установки 1 (с VCS Триггер только) и настройки 2 (с VCS запуска на B только) будет вести себя совсем по-другому.

В общем, я согласен с "тянуть" характер зависимостей моментальных снимков (Setup 2) гораздо более привлекательным. При необходимости комбинируйте с триггером (установка 3).

Answer 2

«Зависимость от моментального снимка» и триггер «Готовая конструкция» очень разные. одна из них в основном является «нажатием», а другая - «тяговым», соответственно.

Setup 1: Если я построить конфиги и B где B имеет "Закончено сборки" триггер , то противоположное поведение верно. Срабатывание B не будет иметь никакого влияния на , но запуск будет эффективно вызывать B, когда он закончил.

Setup 2: Если у меня есть точно такая же установка, но вместо B имеет зависимость снимок на , то всякий раз, когда B срабатывает, будет работать первым, или, по крайней мере, проверить чтобы проверить, нужно ли его запускать, перед запуском B. IF только А запускается, тогда B не будет запущен.

Setup 3: Setup-немного отличается, потому что это не просто зависит от «Закончено сборки» триггера или зависимости снимки. он также зависит от начального триггера (VCS, запланированного или любого другого). например, если у вас есть VCS триггер и B имеет как «Закончено сборку» триггер и «моментальные снимки» зависимость от , то вы эффективно получить поведение установки 1. будет получить срабатывание при изменениях VCS и B будет запущен ПОСЛЕ A (с использованием того же моментального снимка).На самом деле, без установки моментального снимка, не гарантируется, что B будет использовать тот же снимок, что и A, который может быть или не быть тем, что вы хотите.

В общем, если вы хотите запустить триггер «слева направо», вы используете BOTH готовые триггеры сборки и зависимости моментальных снимков, чтобы гарантировать святость залога сборки.

Если, с другой стороны, у вас есть свой первоначальный триггер (VCS или по расписанию или любой другой) установки на B, затем с «закончил строить» спусковой крючок несколько сведены на нет, потому что B всегда будет срабатывать первым (но не запускается), а затем он будет запускать все свои зависимости и автоматически запускаться после их завершения.

надеюсь, что это поможет. благодаря!