Поддерживаемость сборки TFS xaml против сборки TFS vNext против развертывания Octopus

Мой вопрос касается возможности сопровождения процессов 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 Deploy
      • Создает 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). Но часто мы обнаруживаем, что он уже был развернут с неправильным отпечатком. Итак, мы исправим развертывание и повторно развернем. Или мы обнаруживаем странное поведение развернутого приложения и хотим выполнить повторное развертывание с некоторыми дополнительными функциями трассировки / отладки.

Источник

1 ответ

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

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

Давайте начнем с конца и продолжим работу.

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

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

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

Я установил среду в Octopus для каждой из ваших 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, но иногда мы хотим дважды развернуть один и тот же артефакт сборки в одной и той же среде развертывания. Но единственный проект Octopus уже имеет выпуск 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.

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

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

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

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

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

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

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

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

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

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

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

Build vNext

  • Скомпилируйте код.
  • Выполнить юнит-тесты
  • Запустить Octopack
  • Публиковать пакеты
  • Позвоните в Octopus и создайте релиз
  • Позвоните Осьминог, чтобы развернуть в "Dev"
  • Запустите тесты дыма
  • Запустите интеграционные тесты
  • Позвоните в "Selenium", чтобы запустить тесты Run UI
  • Позвоните в Octopus, чтобы повысить выпуск до "Тест"
  • Запустите тесты дыма
  • Запустите интеграционные тесты
  • Позвоните в "Selenium", чтобы запустить тесты Run UI
  • Позвоните Осьминогу, чтобы Продвинуть выпуск к "Производству" (Возможно с ручной иннервацией)
  • Запустите тесты дыма
  • Запустите интеграционные тесты
  • Позвоните в "Selenium", чтобы запустить тесты Run UI
Источник
Другие вопросы по тегам