Использование Nuget в среде разработки - лучшие практики / как

Question

Попытка выяснить, как лучше использовать Nuget в среде разработки для управления нашими собственными библиотеками.

Мы хотим стандартизировать способы работы Nuget для наших сторонних библиотек, но также хотели бы использовать Nuget для управления нашими внутренними библиотеками утилит, для разработчиков, использующих собственные библиотеки, это здорово, и все довольны. Однако, для разработчиков, активно работающих над Utility lib, это кажется более проблематичным, их предыдущий процесс сборки lib, сборки основного приложения, F5 и go теперь замедлен с публикацией, обновлением и потенциально большим количеством пакетов, не говоря уже о Стоны о дополнительном процессе!

Мы используем TDD для внутренних библиотек, но каждый должен иметь возможность отлаживать и изменять библиотеки вместе с основным приложением, видел демонстрацию Фила Хаака по пакетам отладки в 1.3 и читал блог Дэвида Эббоса, но это подходит для другого сценария.

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

Люблю Нюгет, возможно, очень хочу от маленького парня многого, отзыв приветствуется.

Спасибо

Answer 1

Я бы предложил вам использовать отдельные сетевые ресурсы или каналы (аналогично тому, что myget.org поддерживает в облаке) для различных сценариев . Вы можете представить себе создание ресурса CI, ресурса QA, ресурса Releases, ...

Заставьте людей, работающих над указанной библиотекой, делать сборки CI, которые, например, отбрасывают пакеты CI в репозиторий CI, и собирают их в других проектах (которым просто нужно сделать простое обновление), которые можно было предварительно автоматизировать с помощью PowerShell. build: проверить наличие новой версии, если есть, обновить).

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

Надеюсь, это поможет! Ура, Xavier

Answer 2

Если вы работаете над исходным кодом для lib и основного приложения одновременно, я бы сказал, что NuGet, вероятно, не является хорошим решением.Я думаю, что это будет работать только в ситуациях, когда вы работаете со «стабильной» версией библиотеки, которую не нужно часто менять во время разработки вашего основного приложения.

При этом возможно лиРазработка вашей библиотеки может быть выполнена в изоляции?Вы уже упоминали, что выполняете TDD в lib, так почему эта работа не может быть выполнена, затем построена, развернута, а затем выполнена основная работа приложения?