Как наилучшим образом использовать конвейеры выпуска Azure Devops с микросервисами?

Question

Я перевожу микросервисный конвейер ci / cd из установки teamcity + octopus в Azure Devops.

В настоящее время у нас есть:

• Несколько репо для каждого сервиса и веб-сайта.
• Сборка Teamcity ci, запускающая развертывание осьминога для каждой сборки.
• Запланированный на ночь набор интеграционных тестов запускается для тестирования всей платформы, и, если они успешны, все службы разработки переводятся в нашу ночную среду.
• Раскрутка вручную всех сервисов от nightly-> prod.

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

Кто-нибудь может подсказать, что является наилучшей практикой для того, чего я пытаюсь достичь? Должен ли я иметь один конвейер выпуска, который извлекает все артефакты из всех репозиториев?

Answer 1

Подробное сообщение в блоге, объясняющее причину здесь

tldr…

• Имеет смысл репо на микро-сервис / высвобождаемый модуль / веб-интерфейс.
• Каждый репо / микросервис / съемный модуль / веб-интерфейс имеет сборку CI, которая компилирует, выполняет обширные модульные тесты и создает артефакты сборки.Если какой-либо из этих модульных тестов не пройден, сборка завершится неудачно.
• У вас может быть конвейер выпуска для каждой сборки CI, поскольку эти конвейеры можно использовать для развертывания только отдельной микро-службы, если хотите.
• Для этого сценария вы можете иметь конвейер выпуска, который использует артефакты сборки из каждой сборки CI.Он будет использовать последнюю успешную сборку CI для всех репозиториев.Этот конвейер выпуска будет состоять из 2 (или более, если они вам нужны) этапов.Ночная / тестовая стадия и производственная стадия.Ночная стадия / тестирование захватывает все последние успешные артефакты и развертывает все сервисы.В конце развертывания запускаются ваши интеграционные тесты.И если это пройдет, он перейдет к следующему этапу (прод.), Где у вас будет ручной утверждающий, который утвердит релиз в производстве.
• Так что вот где все становится интересным.Если вы хотите следовать тому же типу рабочего процесса, который в настоящее время использует Роб, вы можете запустить этот всеобъемлющий выпуск по расписанию.В его рабочем процессе, похоже, этот триггер запланирован раз в ночь.Это ограничивает ваш выпуск максимум 1 раз в 24 часа (или столько раз, сколько вы запланировали для своего триггера, и да, вы можете запускать и больше вручную).Это кажется немного ограничительным.Теперь у моего конвейера есть узкое место, основанное на моем запланированном триггере.Если вы хотите, вы можете запускать релиз при изменении артефактов сборки!Таким образом, в любой момент, когда будет успешная сборка для любой сборки CI для каждого отдельного репо, это приведет к запуску конвейера выпуска.Который будет развернут на ночной / тестирование.Запустите интеграционные тесты, и, если все выглядит хорошо, переходят к стадии производства.