Управление выпусками VSTS — несколько определений выпусков, которые используют общие среды.

Я пытаюсь разобраться в проблеме, с которой я столкнулся при управлении релизами. Кажется, у меня есть решения этой проблемы в других инструментах автоматического развертывания, таких как uDeploy, но мне интересно, можно ли с этим справиться в VSTS RM.

Вот мой случай:

Я хотел бы автоматизировать развертывание нескольких (10+) компонентов службы Windows в моем приложении, а также компонента пользовательского интерфейса.

Все артефакты создаются с использованием одного определения сборки TFS.

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

Создание более 10 определений релиза, по одному для каждого компонента, кажется безумием, тем более что конфигурация среды будет повторяться для всех определений.

Но в то же время, если я использую одно определение, как я могу настроить развернутые компоненты?

Создать задачу для каждого компонента под одним определением и включить/отключить задачу для каждого выпуска? В каком случае мне придется постоянно обновлять определение выпуска?

«Окружающая среда» для каждого компонента? И развертывать только в «компонентной среде», которую я хочу развернуть?

Любой совет по этому поводу очень обязан.

Заранее спасибо.


person Reubenator    schedule 09.08.2016    source источник


Ответы (1)


Здесь у вас есть несколько действительных подходов. Либо ваши компоненты действительно независимы друг от друга, и вы хотите создавать (и развертывать) их только тогда, когда исходный код был изменен, поэтому разделение определений сборки и определений выпуска имеет больше смысла . (подумайте об этом как о том, что у каждого компонента есть собственный конвейер выпуска)

Или у ваших компонентов есть какие-то зависимости, и было бы разумнее развернуть все веб-компоненты сразу, всю серверную часть сразу, например. Тогда меньше определений сборок и определений выпусков для каждой роли имеет больше смысла. (и позволит вам точно настроить запуск)

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

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

Кроме того, даже если среды могут технически помочь вам достичь того, что вы пытаетесь сделать, в моем понимании они предназначены для материализации таких вещей, как «qa», «staging» и «production» в процессе продвижения сборки. (по сравнению с продвижением источника)

Надеюсь, это поможет.

person baywet    schedule 10.08.2016