Как правильно использовать NuGet с развитием команды?

Поэтому я хотел бы использовать NuGet для управления различными проектами, которые я использую для конкретного проекта, моей командой, и я над этим работаю. До этого момента я поместил файлы библиотеки .js в каталог /Scripts моего веб-решения (ASP.NET MVC 2) и ссылался на них. Конечно, это было ручным и было неприятно управлять во время обновлений и т.д.

Теперь, когда я использую NuGet, я понимаю, что вся цель NuGet - сделать это довольно безболезненным. Кроме того, похоже, что мне не нужно проверять мои пакеты в моем репозитории (AKA мне больше не нужно управлять моими внешними библиотеками). Однако, когда я захватываю jQuery (например) из NuGet, он помещает свои конкретные файлы в каталог /Scripts моего проекта.

Где я запутался - что, если угодно, я должен проверить контроль источника в этот момент? Я все еще проверяю каталог /Scripts?

Кроме того, если кто-то другой работает над этим проектом и проверяет решение от источника управления, загружаются ли пакеты автоматически (при условии, что решение поставляется с допустимым пакетом .config)?

Я просто пытаюсь прояснить пару моментов, прежде чем мы начнем использовать NuGet полный рабочий день.

Ответы

Ответ 1

Существует два сценария для NuGet vs VCS: для регистрации или отсутствия регистрации, этот вопрос. Оба действительны, на мой взгляд, но при использовании TFS в качестве VCS я определенно поеду для политики no-checkin для пакетов NuGet.

При этом даже при использовании политики no-checkin для пакетов NuGet я все же проверил изменения контента, которые эти пакеты NuGet сделали для моих проектов. Папка \Scripts будет проверена полностью (не выборочно, не проигнорирована).

Политика без проверки для пакетов для меня означает: не проверять папку \Packages (скрывать ее, игнорировать ее), за исключением \Packages\repositories.config.

Таким образом, вы фактически не совершаете никаких пакетов NuGet и при использовании Enable-PackageRestore из NuGetPowerTools (это будет встроено в NuGet v1.6 за углом), любой компьютер, который проверяет код и builds, выберет все необходимые зависимости NuGet на этапе предварительной сборки. Это верно как для локальных машин разработки, так и для серверов сборки, если Enable-PackageRestore включен в вашем решении и указывает на правильные репозитории NuGet (локальные, внутренние, внешние).

Если вы думаете об этом, при установке пакета NuGet, который добавляет только ссылки на некоторые двоичные файлы, вы уже делаете это в сценарии без проверки: вы не будете вставлять подпапки \Packages в папку, но все же, вы должны зафиксировать изменения проекта (добавленная ссылка).

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

Ответ 2

NuGet, например Nexus, являются артефактами-хранилищами (артефакт - это любой тип доставки, в том числе потенциально большой двоичный файл).

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

  • не будет пользоваться функциями VCS (ветвление, слияние)
  • значительно увеличит размер хранилища VCS (без дельта или слабой дельта-памяти).
  • было бы довольно сложно удалить из репозитория VCS (предназначенного прежде всего для сохранения истории)

Но цель состоит в том, чтобы вы заявляли, что вам нужно (и пусть NuGet извлекает его для вас) вместо того, чтобы хранить его самостоятельно.
Таким образом, вы можете использовать версию /Scripts в качестве заполнителя, но вам больше не нужно обновлять содержимое своего содержимого, которое теперь автоматически загружается.