Зависимости между настройками BuildConfiguration в TeamCity при развертывании - PullRequest
0 голосов
/ 12 октября 2018

Мне трудно понять, как правильно развертывать в различных средах с TeamCity (с точки зрения перекрестных зависимостей BuildConfiguration), и надеюсь получить некоторую информацию о том, как правильно настроить мои SubProjects / BuildConfigurations.Давайте начнем с конкретного примера: я провел этот тест "TeamcityConfigurationTests", чтобы лучше узнать, как TeamCity обрабатывает зависимости, и текущее состояние показывает результат, который я ищу:

enter image description here

У меня есть 3 подпроекта: Dev, Test и Prod - и все связанные задачи для этих «сред» в качестве отдельных конфигураций сборки в этом подпроекте.Это делается для более четкой визуализации того, что происходит, и, если что-то ломается, чтобы иметь возможность сразу увидеть, что сломано (отдельные Build, UnitTest и DeployToDev BuildConfigurations, а не 3 разных шага в одной конфигурации Build).

В идеале я хочу создать свое приложение один раз в шаге Dev.Build и разрешить Dev.UnitTest и Dev.DeployToDev шагов для захвата этого артефакта, запуска тестов и развертывания.То, что я получил для меня, имея снимок и зависимости артефакта.Но у меня возникают проблемы с получением правильного артефакта, когда я хочу выполнить развертывание из Dev -> Test или Test -> Prod .

Моя проблема заключается в правильной ссылке напоследний успешно развернутый артефакт DEV при запуске Test.DeployToTest - и то же самое для получения последнего успешно развернутого артефакта TEST при запуске Prod.DeployToProd .(По сути, я хочу продвинуть артефакт в следующую среду).

Теперь моя проблема в том, что если у меня в Test.DeployToTest есть SnapshotDependency к Dev.DeployToDev и зависимость артефакта от Dev.Build , а источник VCS изменился после запуска Deploy to Dev, он снова запускает все шаги DEV.Это не самая плохая часть, то же самое происходит, когда я запускаю Prod.DeployToProd , если источник VCS изменился с момента первоначальной сборки на dev (из-за всех зависимостей моментального снимка).Это означает, что вместо того, чтобы продвигать Test -> Prod , я собираю и внедряю все, что в настоящее время на VCS, в Dev, Test AND Prod.

Как мне правильно настроить это?

Единственный другой вариант, о котором я знаю, это разрешить Dev.DeployToDev также публиковать тот же артефакт и иметь (LatestSuccessful) ArtifactDependency только в Test.DeployToTest .Я также должен был бы снова опубликовать артефакт в Test.DeployToTest , чтобы позволить Prod.DeployToProd иметь только (LatestSuccessfull) зависимость артефакта от Test.DeployToTest .(Это должно было бы избавиться от SnapshotDependencies, заставляющего предыдущие среды снова запустить сборку / развертывание в случае изменений VCS).Но потом я публикую артефакт 3 раза, а не один раз, когда приложение изначально встроено в DEV - чего я хотел бы избежать.Кроме того, у меня есть случаи, когда для развертывания в Test и Prod не требуется артефакт, поэтому нет артефакта, от которого можно зависеть (по сути, мне нужен только BuildNumber из "зависимой" среды, из которой я хочу продвигаться).

Я надеюсь на некоторый вклад.Спасибо

С уважением

Фредерик

1 Ответ

0 голосов
/ 16 октября 2018

Для всех, кто интересуется, я сделал заявку в службу поддержки JetBrains и получил следующий ответ:

В основном, есть варианты решения вашего дела:

Вариант 1: использовать "Содействуйте «действию» в верхнем правом меню «Действия» сборки (или измените тип конфигураций Deploy * на развертывание и используйте действие из блока в результатах сборки. Это предпочтительный способ: перед развертыванием выберите сборку для развертывания и«продвигать» его в следующую среду. Существует также экспериментальная скрытая функция, позволяющая скрыть кнопку «Выполнить»: добавьте параметр конфигурации «teamcity.ui.runButton.caption» в конфигурации сборки к пустому значению.

Вариант 2: не используйте зависимость моментального снимка, используйте только зависимость артефакта от последней успешной сборки. Однако, когда вы запускаете сборку, вы не можете быть уверены, что последняя успешная сборка, которую вы видите, будет развернута: пока сборка стоит в очереди,другой Dev.DeployToDev может завершиться, а затем развернуться как последний успехфул.

Мы пошли с вариантом 1

...