Как компания, мы создаем пакеты NuGet из различных репозиториев git в DevOps Azure. После того, как пакет протестирован и утвержден, его следует передать в организацию Azure DevOps.
Я все еще борюсь с настройкой конвейера сборки / выпуска с использованием каналов DevOps Azure. Пакеты должны стать доступными для тестирования, прежде чем они будут переданы в организацию.
Несмотря на то, что Microsoft предоставляет множество рекомендаций и рекомендаций, я все еще не могу найти работоспособное решение. Я объясню решения, которые я пробовал до сих пор:
Раствор А
Использование одного канала для всей организации. Пакеты автоматически отправляются в канал @local и по окончании тестирования в представления @prerelease и @release. Трубопровод используется следующим образом:
- Мы работаем в соответствии с Git-потоком с ветвями разработки, функций и мастера.
- Сборка CI запускается в ветви разработки
- Пакет с суффиксом перед выпуском помещается в канал @local.
- Приемочные тесты выполняются в других инструментах, если включить флажок предварительной версии в диспетчере пакетов NuGet в Visual Studio.
- Когда пакет принят, создается релиз и запускается новая сборка.
- Пакет выталкивается
Проблемы Решение A:
- Когда пакет принят, он должен быть переведен в представление @release, но имя пакета по-прежнему содержит суффикс -pre.
- Когда пакет принят, по моему мнению, новая сборка не требуется, разве вы можете выполнить это из ветки релиза?
- Хотя пакет виден только в Visual Studio с префиксом, его можно переместить с суффиксом в представление @release.
- Когда пакет продвигается, его следует копировать и хранить без суффикса.
Раствор B
Использование выделенного канала для каждого репозитория git (рекомендуется Microsoft) и публикация пакетов NuGet для этого канала из сборок CI. Каждый пакет отправляется на канал @local без суффикса. Когда пакет протестирован и принят, пакет переводится в представление @release. Каждый выделенный канал настроен как исходный источник (представление @release), пакеты из представления выпуска будут «кэшироваться» в общем канале, который используется в организации всеми группами разработчиков.
Проблемы Решение B:
- Пакеты, которые становятся видимыми из вышестоящих источников, добавляются / кэшируются только после завершения одного развертывания / сборки. Вы не можете применить это, когда пакет повышен до представления @release.
- Все команды разработчиков должны подписаться в Visual Studio на все каналы NuGet, чтобы установить последнюю версию пакета. (30 git репо = 30 каналов)
Общие вопросы:
- Работает ли git-flow, когда мы создаем только пакеты NuGet?
- Должны ли мы работать с предварительными выпусками или сохранять их в виде @ перед выпуском без суффикса?
- Неправильно начинать новую сборку, чтобы иметь пакет без суффикса. После того, как предварительная версия пакета протестирована, она должна быть переведена только в представление выпуска.
- Должны ли мы собирать пакет в сборке CI и использовать релизную сборку для выпуска пакета. Я видел людей, использующих PowerShell с переменными среды для продвижения пакета из одного выпуска в другой.
Я знаю, что есть много вопросов, но я уже довольно долго борюсь с этой проблемой. Я надеюсь, что кто-то может дать мне несколько хороших предложений.
Спасибо!