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