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

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

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

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

Ответы

Ответ 1

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

Самая большая проблема imo - это управление версиями пакетов , поскольку 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, сделанная в 2012-09-14 в 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 pkgs отдельно от предварительных выпусков и выпусков, хотя технически ваш CI-пакет версируется как предварительный выпуск)
  • обновление от CI pkg до предварительного выпуска может быть проблемой, если тег перед выпуском сортируется по строкам выше, чем "CI" (например, "Alpha" ). В этом случае: удалить пакет "CI", а затем установить пакет "Alpha".

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