Использование Nuget в среде разработки - лучшие практики/как
Попытка выяснить, как использовать Nuget в среде разработки для управления нашими собственными библиотеками.
Мы хотим стандартизировать Nuget для того, чтобы делать что-то для наших сторонних библиотек, но также хотели бы использовать Nuget для управления нашими внутренними библиотеками утилиты, для разработчиков, потребляющих встроенные библиотеки, это здорово и все рады. Тем не менее, для разработчиков, активно работающих над утилитой lib, это кажется более проблематичным, их предыдущий процесс сборки lib, build main app, F5 и go теперь замедляется с публикацией и обновлением и потенциально большим количеством пакетов, не говоря уже о том, стонать о дополнительном процессе!
Мы используем TDD во внутренних libs, но каждый должен иметь возможность отлаживать и изменять библиотеки вместе с основным приложением, видел демо-версию Phil Haacks на отладочных пакетах в 1.3 и читал блог Дэвида Эббоса, но это соответствует разному сценарию.
Итак, каков наилучший процесс для циклов dev/debug? если использовать Nuget, тогда нам нужно принять существующие ограничения или использовать гибридную практику, которые люди используют, и, возможно, 1.3 приближается к автоматизации всего этого, или мы просто избегаем Nuget для внутренних пакетов, что было бы настоящим позором.
Любящего Нугета, возможно, желая многого от маленького парня, отзывы были оценены.
Спасибо
Ответы
Ответ 1
Я предлагаю вам использовать отдельные сетевые ресурсы или каналы (аналогично myget.org поддерживает в облако) для разных сценариев.
Вы могли бы представить себе создание доли CI, доли QA, доли релизов,...
Заставить людей, работающих в библиотеке ссылок, создавать CI-сборки, которые, например, отбрасывают пакеты CI в репозитории CI, а также получать их от других проектов (которые просто должны сделать простое обновление, могут быть автоматизированы с помощью PowerShell в pre- build: проверьте новую версию, если да, обновите).
Просто убедитесь, что когда продукты выпускают свои вехи, они также выпускаются с выпущенными зависимостями (может быть так же просто, как переключение каналов, выпуски всегда будут иметь более высокий номер версии, чем сборки CI).
Надеюсь, что это поможет!
Ура,
Xavier
Ответ 2
Если вы одновременно работаете над исходным кодом для lib и основного приложения, я бы сказал, что NuGet, вероятно, не очень хорошее решение. Я думаю, что это будет работать только в ситуациях, когда вы работаете со "стабильной" версией библиотеки, которую не нужно часто менять при разработке основного приложения.
Тем не менее - возможно ли, что разработка в вашей библиотеке может быть выполнена изолированно? Вы уже упоминаете, что вы делаете TDD в lib, поэтому почему эта работа не может быть выполнена, затем построена, развернута, а затем основная работа над проектом?
Ответ 3
Я согласен с тем, что Nuget не лучший подход, если вы используете несколько ветвей в вашем репозитории управления версиями.
Я сделал след в этом и не смог найти, как вы автоматически переключаете каналы и получаете последние пакеты Nuget для проекта без каких-либо накладных расходов.
У нас есть три ветки в TFS, которые следуют и гибкий процесс.
Как я вижу, что он работает:
Если разработчики разрабатывают ветку dev и обновляют фид Nuget, мы затем объединяемся с ветвью INT во время выпуска. Существует автоматизированный процесс сборки, но проекты с кодами должны быть в состоянии сказать, что есть обновление для пакетов, поэтому я внедрил обновление и установил шаг предварительной сборки в проектах. Теперь проблема заключается в том, что проект всегда обновляется, и существует риск того, что любая сборка, которая произойдет, всегда будет тянуть последний пакет nuget, даже если вы этого не хотите.
Я не могу понять, как вы программно выбираете, когда обновлять пакет или нет.
