2014-01-28 3 views
3

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

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

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

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

+0

Мне было очень тяжело полагать, что OctopusDeploy не обладает этой функциональностью отделяемых друг от друга конвейеров развертывания. Я также работаю с IBM Urban Code Deploy, и они имеют эту функциональность из коробки. Тем не менее, существует различие в ценах между ценами. – 8DH

ответ

3

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

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

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

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

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

+0

Спасибо, Майк, ваши ответы имеют смысл. –

Смежные вопросы