Каковы преимущества использования автоматического восстановления пакетов Nuget на предприятии?

Как указал Стивен в своем ответе, основная причина сохранения пакетов вне системы контроля версий заключается в уменьшении объема данных, которые необходимо для хранения и передачи с/на сервер управления исходным кодом. Очевидно, что в компании, где вы контролируете все оборудование, ни дисковое пространство, ни сетевая передача не должны быть проблемой, но зачем тратить дисковое пространство/время на работу с пакетами, если вам это не нужно. Обратите внимание, что размер каталога пакета может составлять довольно значительный процент от общего размера рабочей области. В моем случае каталог пакетов занимает от 80% до 95% всего рабочего пространства при использовании TFS (для моих рабочих пространств) и от 50% до 75% для моих личных рабочих пространств (которые основаны на git и поэтому имеют .git каталог, который занимает некоторое пространство). В целом можно сэкономить значительное количество места на сервере управления исходным кодом, если вы используете восстановление пакетов.

Один из способов решить проблему с доступом к Nuget.org — создать собственный локальный репозиторий пакетов. Этот локальный репозиторий пакетов может быть локальным nuget web service или просто общий каталог на сервере. Поскольку репозиторий находится внутри локальной сети вашей компании, для сервера сборки не должно быть большой проблемой добраться до локального репозитория nuget. Дополнительным преимуществом этого подхода является то, что ваш процесс сборки не зависит от Nuget.org (в очень редких случаях он выходит из строя) и, что более важно, вы точно знаете, какие пакеты будут включены в сборку (поскольку они будут утвержденными). пакеты в вашем локальном репозитории).

Для нас решение использовать локальный репозиторий nuget и вариант восстановления пакета зависело от нашего решения упаковать все наши внутренние библиотеки в пакеты nuget (я описал наш процесс разработки в ответ на другой вопрос nuget). Из-за этого нам понадобился локальный репозиторий пакетов для распространения этих внутренних пакетов. Это означало, что добавление сторонних пакетов в этот репозиторий было простым, и поэтому использование восстановления пакетов имело смысл. Если вы не упаковываете свои внутренние библиотеки в пакеты nuget, вы поместите их в систему управления версиями вместе с файлами решения и кода. В этом случае вы можете сделать то же самое для сторонних библиотек.

В конце концов, это все компромисс. Дисковое пространство или простота настройки инфраструктуры и т. д. и т. д. Выберите решение, которое лучше всего подходит для вашей среды.

от Nuget.org:

Первоначальный рабочий процесс NuGet заключался в фиксации папки Packages в системе управления версиями. Причина в том, что это соответствует тому, что обычно делают разработчики, когда у них нет NuGet: они создают папку Lib или ExternalDependencies, выгружают туда двоичные файлы и фиксируют их в системе управления версиями, чтобы позволить другим выполнять сборку.

Таким образом, идея состоит в том, что пакеты будут восстановлены на каждой машине, на которой будет создаваться проект, поэтому двоичные данные останутся вне контроля над исходным кодом. А в распределенных системах управления версиями, таких как Mercurial или Git, дисковое пространство и пропускная способность используются как на клиентских машинах, так и на сервере.

Но это создает проблему, когда ваша сборочная машина не может подключиться к Интернету на nuget.org (я предполагаю). Я думаю, вы нашли основные решения. Перенесите пакеты в систему управления версиями и избегайте восстановления пакетов, разрешите машине сборки подключаться к Интернету или настройте локальное зеркало.

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