Использование Nuget в среде разработки-лучшие практики / как
попытка найти лучший способ использовать Nuget в среде разработки для управления нашими собственными библиотеками.
мы хотим стандартизировать способ Nuget делать вещи для наших сторонних библиотек, но также хотели бы использовать Nuget для управления нашими внутренними служебными библиотеками, для разработчиков, потребляющих в домашних библиотеках, это здорово и все счастливы. Однако для разработчиков, активно работающих над утилитой lib, кажется более проблематичным, их предыдущий процесс сборки lib, build основное приложение, F5 и go теперь замедляется с публикацией, обновлением и потенциально большим количеством пакетов, не говоря уже о стонах о дополнительном процессе!
мы используем TDD на внутренних библиотеках, но все должны иметь возможность отлаживать и изменять библиотеки вместе с основным приложением, видели демо-версию Фила Хейкса на отладочных пакетах в 1.3 и читали блог Дэвида Эббоса, но это соответствует другому сценарию.
Итак, каков наилучший процесс для циклов разработки/отладки? если использовать Nuget, то нам нужно примите существующие ограничения, или есть гибридная практика, которую люди используют, и, возможно, 1.3 приближается к автоматизации всего этого, или мы просто избегаем Nuget для внутренних пакетов, которые были бы настоящим позором.
любящий Nuget, возможно, желая многого от маленького парня, обратная связь ценится.
спасибо
3 ответов
Я бы предложил вам использовать отдельные сетевые ресурсы или каналы (похоже на то, что myget.org поддержка в облаке)для различных сценариев. Вы можете себе представить создание ИЦ акций, долей ОК, а выпуски акций, ...
заставьте людей, работающих над ссылочной библиотекой, делать сборки CI, которые, например, удаляют пакеты CI в репозитории CI, и их забирают другие проекты (которым просто нужно сделать простое обновление, можно автоматизировать через PowerShell в pre-build: проверьте наличие новой версии, если да, обновите).
просто убедитесь, что когда продукты выпускают свои вехи, они также выпускают с выпущенными зависимостями (может быть так же просто, как переключение каналов, выпуски всегда будут иметь более высокий номер версии, чем сборки CI).
надеюсь, что это поможет! Овации, Ксавье!--7-->
Если вы работаете над исходным кодом для lib и основного приложения одновременно, я бы сказал, что NuGet, вероятно, не является хорошим решением. Я думаю, что это будет работать только в ситуациях, когда вы работаете со "стабильной" версией библиотеки, которая не нуждается в частых изменениях во время разработки вашего основного приложения.
тем не менее-возможно ли, что разработка вашей библиотеки может быть выполнена в изоляции? Вы уже упоминали, что делаете TDD на lib, так почему бы не сделать эту работу, затем построен, развернут, затем основная работа приложения выполнена?
Я согласен с тем, что Nuget не лучший подход, если вы используете несколько ветвей в вашем Source control respository.
Я сделал след на этом и не мог найти, как вы автоматически переключаете каналы и получаете последние пакеты Nuget для проекта без каких-либо накладных расходов.
У нас есть три ветви в TFS, которые следуют за гибким процессом.
Как я вижу, что это работает: Если разработчики развиваются в ветви dev и обновляют канал Nuget, мы затем слияние с ветвью INT во время выпуска. Существует автоматизированный процесс сборки, но они кодируют проекты, которые должны быть в состоянии сказать, что есть обновление пакетов, поэтому я реализовал обновление и установил шаг предварительной сборки в проектах. Теперь проблема в том, что проект всегда обновляется, и есть риск, что любая сборка, которая произойдет, всегда вытащит последний пакет nuget, даже если вы этого не хотите.
Я не могу понять, как вы программно выбираете, когда обновлять посылка или нет.