NuGet Enterprise - лучшие практики для разных уровней зрелости пакетов

Мы хотим использовать NuGet для совместного использования сборок среди разработчиков в нашей организации. В настоящее время мы изучаем настройку трех каналов NuGet, например:

Release-feed: Стабильные версии версий сборки.
QA-feed: Ассембли, созданные в главной ветки (наша ветка интеграции).
Разработка: Ассембли, созданные в любой из ветвей функций (совместное продвижение).

Локальные сборки на машинах разработчиков не должны отправляться ни одному из этих каналов. Для этого требуется только сборка, созданная сервером сборки. Наш сервер сборки выполняет три разных типа сборки, в зависимости от веток, отделов разработки, контроля качества и выпуска. Каждый из них имеет соответствующие конфигурации сборки, которые запускаются при изменении источника. При построении каждый из них будет выталкивать встроенные сборки-nuget-пакеты в соответствующий фид. В сборках разработки будет добавлен "-dev" к версии. Строки QA добавят к версии "-qa", а в сборках выпусков будет "чистый" номер версии.

Теперь вопросы:

Что было бы лучшим решением для разработчика, чтобы контролировать, какие пакеты использовать? Я думаю, разработчику вручную нужно отредактировать параметр источника зависимостей, чтобы явно определить, какие каналы собирать сборки from: Иногда вам нужна сборка релизов, иногда сборка QA, и иногда вам даже нужна версия для разработки.
Мы также рассматриваем возможность добавления локальных пакетов сборки в локальный частный канал на каждой собственной машине своих разработчиков, чтобы ускорить сборку. Было бы проблематично, с какой фид можно получить?
Если эти определения создаются разработчиком в файле зависимостей (который также обязательно контролируется версией), то этот параметр будет внесен в фид разработки, когда источник привязан к репо (тот же фокус для строить как разработчик, просто делиться с другими). Это может быть или не быть правильным для фида разработки?
Когда источник затем объединяется в qa-ветвь, фиды, определенные в зависимостях, по-прежнему будут такими, как это сделал разработчик, возможно, получая сборки из фидов разработки. Для построения QA я думаю, что это, вероятно, не то, что мы хотим. Строки QA должны, вероятно, ограничивать каналы только для выпуска сборок, так как вы хотите увидеть, будут ли изменения работать так, как ожидалось, с компонентами Release. Вы не хотите тестировать его с помощью других "непроверенных" сборок QA. Означает ли это смысл и для других?
В релиз-сборке выпускные сборки должны использовать только сборки релизов, я полагаю? У меня такое ощущение, что на этом может быть консенсус, так что, возможно, на самом деле не вопрос все:).

Итак, подведем итог предлагаемому процессу... Во время сборки мы должны:

Следуйте за источниками, установленными разработчиком в спецификациях зависимостей для локальных и сборных версий.
При создании QA и Release сборки фид должен быть ограничен линией Release.

В качестве побочного примечания, каналы QA фактически не будут использоваться никакими другими сборками. Но они будут использоваться отделом QA, поскольку они будут использовать их для тестирования.

Ответ 1

На мой взгляд, процесс, который вы предлагаете, слишком сложный, как для размера вашей команды, так и для размера команды на год вперед.

Я понимаю причины, по которым вы считаете, что вам нужны три отдельных канала (Dev, QA, Release), но я предсказываю, что это станет болезненным для вас через год. Я ожидаю, что вы захотите повысить уверенность в стабильности/качестве пакетов по мере их перехода от Dev к QA к выпуску - вполне разумное требование. Однако отдельные ветки и особенно отдельные сборки для Dev, QA и Release рассматриваются многими как анти-шаблон. В частности, в оригинальной книге Непрерывная доставка от Humble и Farley, настоятельно рекомендуется иметь только одну базу кода, из которой собираются сборки, и любая из этих сборников должна быть способный быть продвинутым до производства, если испытания пройдут: "Создайте свой код только один раз" - это ключ.

Вместо шаблона, который вы начертите, я бы рекомендовал вам:

Используйте инструмент CI, который позволяет вам смоделировать конвейер : Jenkins, TeamCity, TW GO и т.д. Это создает хороший прецедент для протекания артефактов непосредственно из исходный CI полностью доходит до производства без повторной сборки.
Используйте семантическое управление версиями (называемое SemVer в мире .NET), чтобы защитить потребителей пакетов от нарушения изменений и сообщить о характере изменений пакета другим командам.
Используйте ограничения диапазона версии в packages.config, чтобы сборки не были разбиты новыми основными версиями пакетов (с нарушением изменений).
Сделать команды разработчиков ответственными за конкретные пакеты от кода commit до Production - если у одного из пакетов, которые они поддерживают, есть проблемы, им необходимо быстро установить исправление, чтобы другие команды не блокировались. Команды также нуждаются в дисциплине, чтобы гарантировать, что они сообщают о характере изменений пакета через SemVer (это перерыв в изменении? Новая функция? Исправлена ошибка?)
Если вы считаете это необходимым, используйте функцию Prerelease NuGet, чтобы "скрыть" новые версии пакетов из последующих сборок и тестирования. Это может позволить разработчикам более эффективно вносить изменения, но, вероятно, не понадобится, если вы используете конвейеры развертывания, которые позволяют быстро создавать и доставлять новые версии пакетов.

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