Поддержка TFS xaml build против TFS vNext build против Octopus Deploy

Question

Мой вопрос касается возможности сопровождения процессов vNext / Octopus по сравнению с процессами на основе XAML. Или, скорее, из-за невозможности поддерживать их в здравом уме, заставляя меня поверить, что мы делаем что-то ужасно неправильное.

Дано:

• Microsoft подталкивает к отказу от своих сборок TFS XAML в пользу сборок vNext
• Octopus Deploy - популярная среда автоматизации развертывания
• У нас есть много сборок на основе XAML, но мы начинаем портировать на vNext
• Развертывание автоматизировано с помощью Octopus Deploy

Конкретно, в QA происходит три вида сборок:

• Старые компиляции на основе XAML производят артефакты для развертывания
  • В конечном итоге просто создает код, архивирует его и размещает в известном месте
• Новая сборка vNext производит артефакты для развертывания
  • То же, что и выше
• Сборка развертывания
  1. Определение сборки на основе XAML для каждой среды развертывания. Это источник правды для конкретного развертывания, содержащий все URL-адреса конфигурации, строки подключения, отпечатки сертификатов и т. Д. Определение сборки содержит более 100 параметров сборки. Каждый раз, когда настраивается новая среда, мы клонируем существующее определение сборки XAML и меняем параметры.
     • Эта сборка распаковывает артефакт сборки, генерирует все файлы конфигурации web / app на основе параметров конфигурации и запускает Octopus Deploy с большим количеством параметров, используя octo.exe и ожидая конца
  2. Процесс развертывания Octopus
     • Создает 3 пакета из артефакта сборки, ранее распакованного сборкой XAML, для соответствия трем областям развертывания - веб-ферме, кластеру механизма фоновых заданий и базе данных
     • Доставляет соответствующие пакеты соответствующим щупальцам.
     • Щупальца распаковывают и настраивают соответствующие пакеты

Итак, если у нас есть 50 сред развертывания, то у нас есть 50 сборок развертывания XAML, каждая из которых отражает контекст соответствующей среды. Но сборка развертывания XAML делегирует задание развертывания Octopus, и здесь мы вынуждены иметь 50 проектов Octopus - по одному на развертывание.

Почему это так? Мы рассмотрели возможность иметь только один проект Octopus, но какими будут версии выпуска такого проекта? Для того, чтобы мы могли перемещаться между выпусками gazillion, версия выпуска должна включать:

• Версия сборки развернутого кода, например 55.0.18709.3
• Имя среды развертывания, например, atwfm

Используя приведенный выше пример, мы получаем 55.0.18709.3-atwfm, но иногда мы хотим развернуть один и тот же артефакт сборки в одной и той же среде развертывания дважды. Но единственный проект Octopus уже имеет выпуск 55.0.18709.3-atwfm, так как же снова развернуть 55.0.18709.3 в atwfm, не удаляя уже существующий выпуск?

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

ЭТО АБСОЛЮТНО БЕЗУМНО , потому что проекты Octopus - это боль в обновлении. Предположим, нам нужно добавить шаг - сделайте это в 50 проектах. В Интернете есть отличные советы по использованию автоматизации для редактирования нескольких проектов. Совсем не идеально.

vNext, кстати, имеет ту же проблему. Если мне нужно перенести существующие сборки XAML на vNext, я получу 50 сборок развертывания vNext. Если я решу добавить шаг, мне нужно сделать это во всех 50 сборках !!!

Обратите внимание, что сборки XAML не имеют этой проблемы (хотя у них есть много других), потому что их процесс отделен от параметров. Я могу изменить рабочий процесс один раз, и все сборки XAML теперь обновляются с новым изменением процесса.

Мой вопрос - как люди работают с vNext и Octopus, потому что наш процесс сводит меня с ума. Должен быть лучший способ.

РЕДАКТИРОВАТЬ 1

Я бы хотел уточнить. Иногда мы хотим развернуть одни и те же артефакты сборки дважды . Мы не перекомпилируем их и не используем повторно одну и ту же версию. Нет. У нас уже есть под рукой артефакты сборки с версией сборки, запеченной внутри артефакта. Мы можем захотеть развернуть его во второй раз в той же среде, потому что, например, некоторые базы данных в этой среде были неправильно настроены, и теперь это исправлено, и нам нужно повторно развернуть. Это не означает, что мы можем перезапустить уже существующий выпуск Octopus, поскольку исправление может включать изменение параметров развертывания соответствующего определения сборки развертывания XAML. Следовательно, мы можем быть вынуждены перезапустить сборку развертывания XAML, которая никогда не компилирует код.

РЕДАКТИРОВАТЬ 2

Прежде всего, почему мы запускаем развертывание из сборок TFS XAML, а не из Octopus? Исторические причины. Сначала у нас не было осьминога. Развертывание было выполнено нашим специальным кодом. Когда мы представили Octopus, мы решили сохранить сборки XAML deploymenet по двум причинам:

1. Чтобы сэкономить на переносе всех сборок развертывания XAML со всеми параметрами развертывания gazillion в Octopus. Возможно, это было неправильное решение, возможно, мы могли бы автоматизировать миграцию.
2. Поскольку TFS имеет лучшие возможности для отображения результатов испытаний. Развертывание может закончиться дымовыми тестами, и их результаты должны быть где-то опубликованы. Мы не видим, как Octopus может помочь нам опубликовать результаты, TFS может.

Зачем перераспределять? Например, одним из параметров развертывания является отпечаток сертификата. Когда сертификат обновляется, этот параметр должен быть изменен (у нас есть автоматизация для обновления параметров сборки XAML). Но часто мы обнаруживаем, что он уже был развернут с неправильным отпечатком. Итак, мы исправим развертывание и повторно развернем. Или мы обнаруживаем странное поведение развернутого приложения и хотим выполнить повторное развертывание с некоторыми дополнительными функциями трассировки / отладки.

Answer 1

Здесь многое можно распаковать, но я попробую.

TL; DR Это то, как вы выпускаете релизы, которые причиняют вам всю боль. Измени это и все остальное попадет на место

Позволяет начать в конце и работать в обратном направлении.

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

Итак, используя ваш пример.

Создает 3 пакета из артефакта сборки, ранее распакованного Сборка XAML для трех областей развертывания - веб-ферма, фон Кластер заданий и база данных

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

В моей среде разработки у меня есть один сервер, поэтому я создаю среду под названием "Dev" и добавляю щупальце для этого конкретного сервера. Затем я помечаю щупальце тип развертывания "Интернет", "Работа", "База данных"

Затем я настроил тестовую среду, в которой есть 3 сервера, поэтому я создаю среду и добавляю 3 сервера. Затем я помечаю каждое щупальце типом развертывания "Web", "Job", "Database"

Наконец-то я настроил среду производства. Это имеет 5 веб-серверов, 1 сервер заданий и 1 сервер базы данных. Я добавляю все 7 щупалец в окружающую среду и отмечаю их соответствующим образом.

Теперь мне нужен только 1 проект для развертывания во всех трех средах. В моем проекте у меня 3 шага.

Шаг 1 Развертывание веб-сайта

Шаг 2 Развертывание заданий

Шаг 3 Развертывание базы данных

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

Переменные: Ваши переменные могут быть ограничены областью. Так, например, если строка подключения к базе данных среды разработки равна dev.database.net/Instance, а строка подключения к базе данных тестовой среды - test.Database.net/Instance, вы можете включить их в раздел переменных проекта. Если ваш DNS соответствует именам вашей среды, вы можете даже использовать некоторые встроенные переменные, чтобы упростить добавление сред. т.е. ${Octopus.Environment.Name}.Database.net/Instance

Релизы и номера версий: Так что вот в чем, я думаю, заключается ваша проблема. Добавление имени среды в выпуск и попытка создания нескольких выпусков с одной и той же версией в основном вызывает у тебя вся боль.

Используя приведенный выше пример, мы получаем 55.0.18709.3-atwfm, но иногда мы хотим развернуть один и тот же артефакт сборки в том же среда развертывания дважды. Но единственный проект Осьминога будет уже есть релиз 55.0.18709.3-atwfm, так что как развернуть 55.0.18709.3 в atwfm снова, без удаления уже существующего выпуска?

Здесь есть пара вещей. В Octopus вы можете легко выполнить развертывание снова из пользовательского интерфейса, однако, похоже, вы восстанавливаете артефакт и пытаетесь создать новую версию с тем же номером версии. Не делай этого! Каждая новая сборка должна иметь уникальный и уникальный номер сборки / номер выпуска.

Принцип, который я придерживаюсь, - "построить один раз, развернуть много"

Когда вы создаете выпуск, для него требуется номер версии, затем этот выпуск проходит через среды. Поэтому я создаю свой код, и он получает номер версии 55.0.18709.3, а затем развертываю его в Dev. Когда развертывание будет проверено, я затем хочу «Продвинуть» релиз для тестирования, я могу сделать это из Octopus или получить TFS, чтобы сделать это.

Так что я продвигаю 55.0.18709.3, чтобы проверить, а затем перейти к продукту. Если мне нужно узнать, какой релиз и в какой среде, Octopus сообщит мне об этом через панель управления или API.

Наконец, я могу "организовать" поток релизов через мои среды, используя Build v.next.

Так что мой процесс от конца до конца выглядит примерно так.

Build vNext Build

• Компиляция
• Выполнить юнит-тесты
• Пакетная продукция
• Опубликовать пакет

build vNext Release

• Позвоните в Octopus, чтобы создать релиз, передав номер версии
• При желании разверните релиз в первой среде на своем пути к жизни

Теперь у меня есть все, что мне нужно в Octopus для развертывания в ЛЮБОЙ среде с одним проектом и конфигурацией, специфичной для моей среды.

Я могу либо «Развернуть» выпуск в определенной среде, либо «Продвинуть» выпуск из одной среды в другую. Это можно легко сделать из интерфейса Octopus

Или я могу создать «Promote» с помощью плагина Octopus в TFS и использовать его для организации продвижения кода через среды.

Осьминог Терминология. Создать релиз - это объединяет артефакты и номер релиза в Octopus, чтобы создать неизменную вещь, которая будет развернута в одной или нескольких средах.

Развертывание релиза - действие по переносу вашего кода в определенную среду.

Содействие выпуску - после развертывания кода в одной среде его можно продвигать в другие среды

Если у вас есть определенная последовательность сред, то вы можете использовать функцию «Жизненные циклы» Octopus для обеспечения этого рабочего процесса. но это тема для другого дня!

EDIT1 Response

Не думаю, что редактирование меняет мой ответ, вы можете повторно развертывать один и тот же выпуск столько раз, сколько захотите. что вы не можете сделать, это создать новую версию с тем же номером версии. Возможно, вы захотите отделить эти шаги, не могли бы вы добавить более подробную информацию о том, какие изменения в сборке XAML? Вы можете изменить переменные в выпуске, вы можете обновить их в осьминоге, а затем повторно развернуть

РЕДАКТИРОВАТЬ 2 Ответ

Это проясняет ситуацию. Я думаю, что вам нужно принять удар и перенести параметры в Осьминог. Его управление переменными намного лучше, чем сборки XAML, и хотя сборка vNext сравнима с Octopus, имеет смысл иметь конфигурацию в Octopus. Поскольку сборки XAML находятся на выходе, имеет смысл перенести этот материал сейчас. Хотя это может быть много работы, в конце вы получите гораздо более удручающий рабочий процесс, и вы действительно сможете воспользоваться мощью Осьминога.

Результаты теста. Я согласен, что он лучше подходит для сборки vNext, поэтому на данный момент вы будете использовать build vNext в качестве Orchestrator и Octopus Deploy в качестве инструмента управления релизами.

Процесс будет выглядеть примерно так:

Build vNext

• Код компиляции.
• Выполнить юнит-тесты
• Запустите Octopack
• Публикация пакетов
• Позвоните в Octopus и создайте релиз
• Вызовите Осьминога для развертывания в "Dev"
• Выполнить тесты дыма
• Запуск интеграционных тестов
• Вызовите «Selenium» для запуска тестов пользовательского интерфейса.
• Позвоните в Octopus, чтобы повысить выпуск до "Test"
• Выполнить тесты дыма
• Запуск интеграционных тестов
• Вызовите "Selenium" для запуска тестов пользовательского интерфейса.
• Позвоните Осьминогу, чтобы Содействовать выпуску "Производство" (возможно, с ручной иннервацией)
• Выполнить тесты дыма
• Запуск интеграционных тестов
• Вызовите "Selenium" для запуска тестов пользовательского интерфейса.