Определение ролей и сред для нескольких проектов в Octopus Deploy

Мы завершили оценку Octopus Deploy и очень довольны нашим опытом работы с одним проектом. Теперь мы расширяем использование Octopus Deploy для нескольких проектов, и этот шаг привносит новое измерение в наш опыт Octopus. Итак, мы должны проверить следующие утверждения:

  1. Хотя было бы неплохо иметь только один экземпляр каждой среды (например, DEV, STAGE, PROD), одна среда накладывает ограничение одновременного выпуска: выпуск данного проекта развертывается на всех машинах с одной и той же ролью, поэтому, если наша производственная среда состоит из нескольких машин, но у нас на некоторых из них должна быть другая версия выпуска, тогда у нас не может быть только среды Prod, нам нужно разделить ее на несколько групп, например PROD_OSLO и PROD_BERGEN, поэтому мы можем выпустить в производство новую версию только в Осло.

  2. Роли компьютеров являются общими для всех проектов, поэтому, если на компьютере есть роль веб-сервера в среде STAGE, то на этом компьютере будут развернуты веб-приложения для любого выпуска любого проекта. Это означает, что если разные проекты должны использовать разные машины для своей среды STAGE, это может быть достигнуто либо путем создания разных ролей (proj1-web-server и proj2-web-server), либо путем разделения среды STAGE на две (STAGE_PROJ1 и STAGE_PROJ2) . Интересно, есть ли у одной из этих альтернатив какие-либо преимущества.

Если я что-то упустил или неправильно понял, а приведенные выше выводы неверны, пожалуйста, поясните.


deployment octopus-deploy
person Vagif Abilov    schedule 28.01.2014    source источник
comment
Мне было очень трудно поверить, что OctopusDeploy не имеет этой функциональности конвейеров развертывания, разделенных проектами. Я также работал с IBM Urban Code Deploy, и у них есть эта функциональность из коробки. Однако существует разница в ценах на продукты на порядок.   -  person 8DH    schedule 05.10.2016

Ответы (1)


arrow_upward
3
arrow_downward

Я внедрил систему развертывания в своей компании с помощью Octopus, и мы поделимся с нами большинством ваших проблем.

Что касается первого пункта, мы делаем именно это. Мы определили CI, QA, Pre-Production и создали три отдельных производственных развертывания: Production Alpha, < strong> Бета-версия рабочей версии и Полная версия. Альфа и бета содержат отдельные подмножества полной продукции.

Когда дело доходит до разделения проектов по разным физическим серверам, мы реализовали несколько ролей. Мы отошли от маркировки машин как «IIS» или «SQL Server», как это похоже на вас. Наши роли более детализированы и описывают конкретные функции, которые предоставляет машина.

Например, один из наших серверов баз данных может быть помечен как «DB-Sales-Reports», а другой - как «DB-Sales-Engine». Функционально это идентично тому, что вы предлагаете, но мы придаем некоторое семантическое значение тому, что означает тег.

В идеале я хотел бы видеть поддержку для разрешения шага развертывания нацеливаться на машину, которая выполняет «все роли M, цели шага развертывания», которыми я помечен, а не текущее поведение «любой из M ролей. цели шага развертывания "

person Mike Bailey    schedule 28.01.2014
comment
Спасибо, Майк, в твоих ответах есть смысл. - person Vagif Abilov; 29.01.2014