Развертывание Octopus и несколько веток / кандидатов на выпуск

Похоже, что большинство организаций, которые стремятся к непрерывному чему-то, в конечном итоге получают сервер CI и непрерывное развертывание до некоторой среды ручной авторизации, а затем требуют непрерывной доставки в производственную среду. Обычно это приводит к стратегии ветвления, чтобы изолировать кандидата на выпуск, чтобы разрешить оперативное исправление.

Я думаю, что такой вопрос вызывает больше вопросов для обсуждения, прежде чем пытаться дать единый ответ ИМХО.

На ум приходят следующие вещи:

1. Есть ли у вас зависимости «исходного кода» или бинарные для каких-либо общих компонентов.
2. Какой у вас уровень интеграции / автоматического регрессионного тестирования.
3. Ваше развертывание организовано TFS или управляется пользователем в Octopus.
4. Есть ли в приложении база данных, требующая рассмотрения.
5. Как контролируется нумерация версий вашего приложения.
6. Какой у вас цикл выпуска.

Раньше, когда я сталкивался с этим сценарием, я бы обратился к стратегии ветвления продвижения кода, которая предоставляет вам одну ветку для поддержки в производственной среде - это хорошо сработало там, где непрерывное развертывание в производственной среде невозможно. Вы можете найти другие стратегии ветвления, обсуждаемые на странице ALM Rangers на CodePlex

Разработчики / тестировщики могут постоянно продвигать код / ​​функции / исправления ошибок через staging / uat. В момент выпуска ветка Dev объединяется с ветвью Release, что вызывает сборку выпуска и создает пакет nuget. Это должно быть выпущено в Octopus точно таким же образом, только это совершенно новый выпуск, а не продвижение предыдущего выпуска. Это должно гарантировать отсутствие конфликтов в нумерации версий, поэтому стратегия может заключаться в изменении основного номера - это будет зависеть от вашей текущей настройки. Однако при этом высказывается мнение, что развертывание управляется сервером сборки, а не Octopus Deploy. В первую очередь TeamCity / TFS обращается к Ocotpus API, а не к пользователю, выбирающему номер сборки в Octopus (известно, что мы допускаем ошибки).

ocoto.exe create-release --version GENERATED_BY_BUILD_SERVER

Для меня самый большой вопрос, который я задаю клиентам, - это «Какое ограничение означает, что вы не можете непрерывно развертывать в производственной среде». Устраните это ограничение (см. Теорию ограничений), и вы избавитесь от необходимости работать над проблемой, которой вообще не должно быть (не всегда так просто, как я знаю)

Я настоятельно рекомендую вам не клонировать проекты в Octopus для разных сред, так как это противоречит интуиции. В конце концов, вы просто говорите Octopus, что нужно получить эту версию пакета nuget для этого приложения и, пожалуйста, развернуть ее в этой среде. Если вы хотите получить пакет из другого канала NuGet для выпуска, вы всегда можете использовать настраиваемую привязку в поле NuGet в Octopus и управлять этим с помощью переменной с областью действия в зависимости от среды, в которой вы развертываете.

Шаг 1. Настройте два фида

Шаг 2. Определите некоторые переменные для этих фидов

Шаг 3. Используйте фид, используя собственное выражение

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

К сожалению, Octopus напрямую не имеет - true поддержки ветвления (пока). Это указано в их дорожной карте для 3.1 в разделе улучшенная поддержка ветвления. Они уже некоторое время обсуждают эту проблему.

Вы упомянули одну идею - клонировать свой проект для каждой ветки. Вы можете сделать это на вкладке «Настройки» (справа) в вашем проекте, который вы хотите клонировать. Это позволит вам продублировать ваш проект и просто переименовать его в одну из ваших веток, поэтому один проект PreRelease или Release Candidate, а другой - ваш основной разработчик (я бы сохранил то же имя проекта). Я предполагаю, что у вас все в одной проектной группе.

В качестве альтернативы вы можете просто изменить свои файлы NuSpec в своих проектах в разных ветвях, чтобы вы могли четко видеть, что развертывается на странице обзора проекта или на панели управления. Таким образом, для вашей RC-ветви вы можете просто добавить суффикс -release в NuSpec в вашей RC-ветви, что является законным (правила семантического управления версиями поговорим о пререлизах в правиле № 9). Таким образом, вы можете использовать один и тот же проект, но иметь разные пакеты для развертывания. Если ваши целевые серверы такие же, то это может быть более «легкий» или более простой подход по сравнению с клонированием.

Я писал здесь о том, как мы это делаем: http://www.alexjamesbrown.com/blog/development/working-branch-deployments-tfs-octopus/.

Это немного похоже на взлом, но в итоге:

• Создать ветку в TFS Создание определения сборки для конкретной ветки
• Создайте конкретное место для ветки для Octopack
• Создайте проект развертывания Octopus для конкретного филиала (путем клонирования вашего «основного» развертывания
• Отредактируйте только что клонированное развертывание, повторно укажите местоположение фида nuget на выходное местоположение вашей ветки, созданное на шаге 3.