NuGet, как его правильно готовить?
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 04.06.17 20:16
Оценка: +1
Внедряем практику упаковки своих компонентов в NuGet-пакеты. Компонентов много, часть из них используется или разрабатывается другими командами, прямые ссылки на исходники в source control дают слишком много проблем, поэтому мигрируем на NuGet.
При использовании NuGet сразу всплывает ряд других проблем. Эти проблемы куда менее сложные, но, тем не менее, их тоже нужно как-то разгребать чтобы не тратить время разработчиков на чепуху.

1. Первая всплывшая проблема — отладочные символы. Пробовали тот NuGet feed, который встроен в TFS/VSTS. Пакеты-то заработали, но отладочных символов в них нет, пройти отладчиком внутрь пакета нельзя. Вместо этого сейчас взяли какой-то сторонний, слегка платный ($20/month), сервис MyGet. Отладочные символы там теперь есть, но у меня сейчас такое подозрение, что те же отладочные символы будут теперь и в release-билдах. Я там в деталях пока не копался, эту часть настраивал мой коллега, который работает только над Azure-based платформой и его отладочные символы в продакшне не смущают. А у меня есть ещё и клиенты с локальными инсталляциями, мне нельзя им отладочные символы выдавать.
Как это делать правильно? Через MyGet? Или лучше нагородить что-нибудь своё с сервером/папкой для отладочных символов?

2. Версии пакетов меняются довольно часто. Все компоненты системы находятся в активной разработке и даже то, что лежит в дереве исходников лет 20, всё равно время от времени меняется. Большая часть изменений не ломает обратную совместимость и хочется чтобы Visual Studio просто молча обновляла пакет, если у него изменился лишь младший номер версии. Т.е. хочется просто сказать, "используй последнюю релизную версию из ветки 2.х" или "2.3.х". Возможно ли это? Ну чтобы не обновлять все файлы vsproj и package.json по три раза в неделю. Может можно алиас какой-нибудь задать для имени пакета, который бы постоянно указывал на свежую релизную версию?

3. Локальная отладка пакета.
Вот поправил я там что-то в компоненте. Перед тем как отправлять его на код-ревью, мне б хотелось погонять сервисы, которые зависят от этого пакета, чтоб проверить что ничего не отвалилось. Но просто так погонять не выйдет — все сервисы настроены на использование nuget-пакета и, разумеется, даже не узнают об изменениях, пока я этот пакет не обновлю в nuget feed'е. Т.е. чтобы проверить, мне приходится вручную удалять этот пакет из тех проектов, добавлять ссылку на vsproj и тестировать. Куча лишних телодвижений.
Есть ли какой-нибудь способ избежать этих лишних действий? Пока мне на ум приходит создание локального репозитория в какой-нибудь папке, выкладывание пакета туда и обновление пакета в остальных проектах из этой папки. Так я могу потестировать перед отправкой на код-ревью, но как-то тоже много телодвижений получается. Есть ли какой-нибудь более простой путь?
С уважением, Artem Korneev.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.