Подмодули Git против пакетов Nuget

Наша команда экспериментировала с подмодулями git для некоторых основных функций CRUD, общих для большинства наших продуктов. Мы также успешно использовали пакеты Nuget (теперь размещенные самостоятельно) для некоторых распространенных утилит.

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

Есть ли у кого-нибудь опыт и рекомендации относительно того, с какими еще проблемами я могу столкнуться, прежде чем внести это слегка навязчивое изменение в нашу архитектуру и процесс?


git nuget nuget-package git-submodules
person Jason Watts    schedule 13.09.2012    source источник
comment
SourceTree автоматически обнаружит, что подмодули содержат незафиксированные изменения, и предложит вам зафиксировать их каждый раз, когда вы фиксируете родительский проект.   -  person Carl G    schedule 02.09.2013
comment
Интересно, что у вас в итоге? Мы думаем о переходе от Nuget к подмодулям git. Мне не нравится, что наши пакеты nuget не содержат файлы pdb (для уменьшения размера). Отладка сложна. Как было бы неплохо иметь все проекты в решении, в которое можно заходить при отладке. Другой потенциальной проблемой является размер хранилища. Мы используем sonatype nexus и должны иметь почти неограниченную политику хранения для пакетов, поскольку некоторые пакеты могут потребоваться, если им 10 лет. Из-за этих перекрестных зависимостей пакетов архивы/пакеты nuget будут иметь повторяющиеся библиотеки DLL. Боюсь, что это потребует много места   -  person user1325696    schedule 25.04.2017

Ответы (2)


arrow_upward
6
arrow_downward

Как и во всем, это зависит. Рассматривали ли вы возможность использования отдельного репозитория пакетов CI, в котором каждая фиксация основного модуля создает пакет CI?

Самой большой проблемой является управление версиями пакетов, поскольку NuGet еще не поддерживает SemVer в полной мере (например, предварительные версии + номер сборки).

EDIT: nuget.org теперь поддерживает версии пакетов SemVer 2.0. См. эту спецификацию: https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29

Используйте SemVer правильно. Обычно вы заранее не знаете номер выпущенной версии, поэтому ваша версия пакета CI продолжается с последней стабильной версии. Пакеты CI как таковые следует рассматривать как предварительные выпуски.

Например: 2.2.0-CI201209140650 (это сборка CI, сделанная 14 сентября 2012 г. в 06:50 для предстоящего выпуска 2.2.0) ‹-- примечание: эта версия выпуска все еще может измениться, но всегда будет путь обновления.

Если вы используете SemVer v2.0.0, вы можете использовать даже следующий пример: 2.2.0-CI.2012.09.14.06.50.

Важное примечание. nuget.org (а также любой другой сервер/служба NuGet, например MyGet или VSTS) не поддерживает несколько версий пакетов, отличающихся только метаданными сборки!

Это сработало для меня, используя эти ограничения (и некоторые правильные конфигурации сборки TeamCity). Короче, вот такие неприятности:

  • правильное версионирование
  • напоминание о выборе правильного источника пакета (держите свои пакеты CI отдельно от предварительных выпусков и выпусков, хотя технически ваш пакет CI имеет предварительную версию)
  • Обновление пакета CI до предварительной версии может вызвать проблемы, если тег предварительной версии отсортирован по строкам выше, чем "CI" (например, "Alpha"). В этом случае: удалите пакет «CI», а затем установите пакет «Alpha».

Надеюсь это поможет!

person Xavier Decoster    schedule 14.09.2012
comment
Nuget по-прежнему не поддерживает правильный SemVer? - person diegohb; 24.01.2018
comment
nuget.org недавно поддерживает SemVer 2.0. Соответственно обновлю свой ответ. Подробнее о том, как nuget.org поддерживает semver 2.0, см. в этой спецификации: github.com/NuGet/Home/wiki/ - person Xavier Decoster; 25.01.2018

arrow_upward
3
arrow_downward

Я предпочитаю использовать подмодули вместо пакетов Nuget для часто меняющихся внутренних библиотек. Вот почему:

  • Объединение: если несколько разработчиков одновременно вносят изменения в одну и ту же библиотеку с помощью подмодулей, эти изменения можно объединить. Очевидно, что с пакетами Nuget нет понятия слияния.

  • Меньше ожидания: с подмодулями вы отправляете, а затем извлекаете любой репозиторий, в котором вам нужно использовать подмодуль. Обычно это занимает несколько секунд. С Nuget вы должны дождаться публикации пакета, как правило, после завершения процесса CI.

  • Конфликты версий. Опять же, если несколько разработчиков вносят одновременные изменения, они могут увеличить версию Nuget # до одной и той же версии, несмотря на то, что их изменения различаются. Насколько сложно это решить, зависит от вашего процесса CI.

  • Может вносить изменения в клиентские репозитории. Иногда проще уточнить детали изменений в библиотеке, работая над клиентским кодом, который будет использовать библиотеку. С подмодулями это возможно. Конечно, это не замена тестовому покрытию.

person Josh Noe    schedule 20.01.2021