Build Process Design: Nuget vs Artifact Dependencies

У меня есть приложение A, которое зависит от внутренней общей библиотеки B. У каждого из них есть свои репозитории.Build Process Design: Nuget vs Artifact Dependencies

Я использую TeamCity 10 для создания этих двух проектов. Два способа, которые я рассматриваю:

Построить B и опубликовать dll как артефакты. Build A с зависимостью артефакта от B.
Постройте B и опубликуйте как пакет nuget. Построить с NuGet зависимость от В.

Мои вопросы:

Какой подход лучше?
- зависимости Артефакт показаться, что самый простой подход и может получить работу, но если мы идем маршрут NuGet, мы можем обобщить разрешения зависимостей и отвязать его от buildserver, чтобы сделать это. Еще одно преимущество, которое я вижу в nugets, заключается в том, что когда решение для проверки разработчиков для B, любые зависимости можно разрешить с помощью nuget. В то время как для зависимостей артефактов некоторый тип сценария предварительной сборки на локальной машине разработчика необходим для извлечения/копирования артефактов dll, имитируя то, что TeamCity делает с зависимостями артефакта на сервере builds (есть ли лучший подход для этого?).
Если мы реализуем зависимости nuget, зачем вообще нужны артефактные зависимости?

Заранее благодарим за любые отзывы.

источник

2016-11-17 shermoid

Лучший подход к этому основан на ваших проектах, которые развивают прогресс.

Если проект A и проект B все еще находятся в разработке, я предлагаю вам использовать зависимости артефакта. Поскольку вы очень часто меняете проекты при их разработке, в TeamCity вам просто нужно добавить зависимости артефакта к конфигурациям сборки. Независимо от того, как вы меняете код проекта, конфигурации сборки не должны меняться.

Если разработка проектов завершена, зависимости NuGet являются хорошим выбором. Поскольку, если вы используете зависимости NuGet при разработке проектов, когда какой-либо код изменился во время разработки, вам необходимо повторно упаковать пакеты и переустановить их в свой проект.

источник

2016-11-17 06:22:20

Спасибо за ваш ответ. Если использование зависимостей артефактов является наилучшим подходом во время активной разработки, есть ли у вас предложение о том, как разработчики должны разрешать свои зависимости во время локальной сборки (т. Е. Получать правильные артефакты для проекта B)? Использование сценария предварительной сборки для копирования артефактов из сервера-сборщика кажется мне очень неуклюжим. – shermoid

Если вы считаете, что использование сценария предварительной сборки для копирования артефактов из buildserver - очень неуклюжий подход, вы можете выбрать зависимости NuGet. Но этот способ также немного неуклюж, потому что вам нужно, чтобы вы повторно упаковывали пакет каждый раз, когда код менялся. Лучший способ основан на вас, который, по вашему мнению, является самым неуклюжим между пре-сборкой и пакетом ре-пакета. –

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

источник

2016-11-21 02:57:52

ответ

Смежные вопросы