Как настроить конвейер сборки/выпуска Azure DevOps CI для пакетов nuget (дополнительно)

Как компания, мы создаем пакеты 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 с переменными среды для продвижения пакета из одного выпуска в другой.

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

Спасибо!

Ответы

Ответ 1

@Shayki-abramczyk

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

Но концептуально это не идеально, потому что вы соберете и протестируете пререлизный пакет, а затем объедините изменения с мастером, что снова создаст сборку и выпуск нового пакета (который может быть отправлен другим командам без тестирования). Поэтому нам хотелось бы иметь сборки CI, которые публикуют пакет (без тегов) в нашей команде @local, а когда все тестирование завершено, переместите пакет в представление @release, чтобы сделать его доступным для остальной части организации.

Максимальная 24-часовая задержка будет сокращена до 15 минут в первом квартале этого года Microsoft.

Ответ 2

Что я делаю, так это в своем конвейере сборки, я создаю предварительный релиз и пакет релизов и сохраняю их оба в своих артефактах.

В моем конвейере выпуска я публикую предварительный выпуск пакета в локальном кэше, как только я буду готов к UAT, я одобряю выпуск к UAT, и это публикует его как предварительный выпуск. После завершения UAT он получает разрешение на выпуск, который публикует пакет выпуска.