Зависимости между BuildConfigurations в TeamCity при развертывании

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

Зависимости между BuildConfigurations в TeamCity при развертывании

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

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

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

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

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

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

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

С Уважением

Фредерик

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
0
245
1

Ответы 1

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

Basically, there are options to resolve your case:

Option 1: use "Promote" action form the build's Actions top-right menu (or change the type of the Deploy* configurations to deployment and use the action from the block on the build results. This is the preferred way: before deploying you select the build to deploy and "promote" it to the next environment. There is also an experimental hidden feature to hide the "Run" button: add "teamcity.ui.runButton.caption" configuration parameter in the build configurations to empty value.

Option 2: do not use snapshot dependency, use only artifact dependency on the latest successful build. However, when you run the build you cannot be sure that the last successful build you see will be deployed: while the build is standing int he queue, another Dev.DeployToDev can finish and then be deployed as the last successful.

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

Другие вопросы по теме