nuget фиды и рекламные акции

Question

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

Одна из идей состоит в том, чтобы иметь несколько каналов Nuget; ci feed, где каждая успешная интеграция публикует пакет, qa-канал, который вы публикуете только версии, которые вы хотите проверить qa, а затем фид выпуска, где вы копируете только пакеты из qa-канала, который они успешно протестировали.

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

Другая идея состоит в том, что, поскольку мы в основном работаем в багажнике, когда я делаю rc наш процесс сборки прекратит добавлять предварительную часть версии. Кажется, что это сработает, а затем продвижение с qa для выпуска фида будет простой копией пакета.

Кто-нибудь делает этот подход и является ли он рекомендуемым? Я что-то пропустил? У меня есть googled, но nit много обсудил детали такого подхода.

Answer 1

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

Чтобы уточнить, сценарий CI -> QA -> PROD установлен как пример поток продвижения пакета: вы можете создать свой собственный, если хотите.

Вы правильно указали: продвижение пакета не требует каких-либо изменений в упаковке и ее содержимом. Это фактически означает, что даже если вы не переработали двоичные файлы внутри вашего пакета, вы не сможете переделать его в другой канал. Единственным исключением из этого правила является версия предварительной версии пакета, которую можно отрегулировать или удалить. Примечание: семантическая версия должна оставаться неизменной при продвижении!

Это основная особенность http://www.MyGet.org: вот документация для него http://docs.myget.org/docs/reference/package-sources (сценарий: нажатие пакета вверх по течению).

Приведенные выше принципы применяются в этой функции, и мы также заботимся о безопасности фидов/ключей api. Если вы не используете MyGet, вам нужно будет сделать это для себя. Логические шаги:

1. загрузить пакет от подачи исходного
2. при необходимости измените предварительную версию тега
3. толкают пакет на целевой корм

Многие проекты с открытым исходным кодом (вручную?) используют этот сценарий, используя канал CI на MyGet.org, а затем продвигаясь вверх по течению до NuGet.org. Исходным пакетом может быть любой другой канал NuGet (например, галерея Chocolatey.org, галерея плагинов Resharper, другой канал MyGet.org, ...).