Как стать автором
Обновить

Комментарии 14

можно просто сделать шару и на неё класть пакеты — nuget это дело вполне понимает. Ну а права разрулить шарой уже не представляет труда)
Мы сначало то же так делали, но потом пришли к тому, что за каждым пакетом прикреплен свой мэинтэйнер, который за него отвечает и переехали на галерею. Теперь понятно кто и когда что менял и обновлял).
Проще надо быть, проще: сборка и выкладка пакета в репо может быть осуществлена только CI сервером, версии (соответственно) видны в исходниках, равно как и все изменения… В целом, я конечно, не говорю что делать сацтец с RSS и прочими это неправильно, но стоит подобную технику тоже незабывать…
Ну тут еще вопрос ведения истории встал) очень важно что бы пакеты случайно кто-то не перетер и не подменил. Поэтому у всех доступ закрыт нафиг. А публикацию делает не CI сервер, а AddIn для студии, где указывается api ключик. Если у вас билд номер увеличивается с каждым билдом — очень ыбстро надоест обновлять пакеты))
Добрый вечер. В общем-то мы так и сделали — кладет пакеты в ленты только build-машина.
Что касательно папок или сайтов — все по потребностям. Для полноценной поддержки процесса нам понадобилось три ленты, и самое главное — symbol-server. Он был необходим как воздух.
Дело в том, что количество кода, который не можно, а нужно положить в ленту у нас действительно большое. Вот и требования к инфраструктуре соответствующие.
А не смотрели как в последних версиях сделан переключатель Stable Only/Include Prerelease?
Да, смотрели.
Вообще это было одной из тем для второй статьи.
Если идти по стандарту semantic versioning по которому мы как раз и пошли, и по которому идет nuget, то получается что весьма вероятная ситуация, когда мы внесли изменение, не повлекшее изменения API, поэтому меняем в версии формата Major.Minor.Patch только Patch.
При этом, получается, что пакет, допустим, версии 1.2 был релизный, и тут вдруг опять появляется его beta.
То есть prerelease это фича хорошая, но использовать ее в day-to-day разработке нам показалось не очень логично.
Мы решили оставить эту штуку на другие случаи.
Например, когда обстоятельства вынуждают нас сделать быстрый релиз чего-либо нового и не протестированного и это явный сигнал всем, что команде не стоит обновляться до этой версии, если эта версия не конкретно для нее.

А ок, мы используем… Всегда меняем номер версии при публикации, т.е не бывает ситуации, когда что-то поменялось, а версия осталась старая. Для каждой версии продукта есть четкий список зависимостей. Ну и свой AddIn написали для публикаций) Пока руки не доходят добить Stable\Prerelease. Так уже около года живем и все довольны, хотя поначалу тяжело было приучать народ не референсить бинарники в лоб и оформлять зависимости как пакеты).
Буду ждать вторую статью) Заранее спасибо.
А вы не могли бы поделиться, зачем именно AddIn и чем он лучше continuous build-а? Или одно дополняет другое?
Билды собираются постоянно, но каждый раз обновлять пакет — нецелесообразно, так как у нас меняется номер билда. Если каждый раз выкладывать — будет не очень красиво) Хабрапарсер скушал схему версионности. Так же есть компоненты, которые используются для интеграции, и у них своя нумерация. AddIn позволяет четко контролировать, что и когда выкладывается, добавлять релизноты в Description и тд. Допустим продукт имеет версию 2.3.4.5000, но его SDK имеет версию 1.2.3.4000, и при изменении версии продукта, если изменения в SDK не вносились — версия SDK не будет изменена. Плюс как я уже писал выше — за каждым пакетом закреплен свой мэинтэйнер, и только он может обновлять его. Ну и огребать соответственно).
Зачем билды собираются постоянно? Билды собираются, если на то есть причина — обычно это изменение в исходных кодах, что должно влечь за собой изменения версии. Если вы не меняли sdk, то и сборки её не будет.
Ну не раз в неделю чекиним. И версия то как раз меняется, но независимо.
Отличная статья, сам планировал подобную.

Насчет сборки решения и публикации пакетов — мы поступили несколько иначе — подняли два билд-сервера.
На первом continious build для решения, на втором — сборка и публикация пакетов в корпоративную галерею.
Плюс у разработчиков есть скрипт для локальной сборки пакетов для тестирования без публикации.
Для того, чтобы не заморачиваться с формированием файла спецификаций, основную информацию мы собираем из атрибутов сборки (AssemblyCompany, AssemblyProduct, AssemblyVersion и т.д.), а зависимости — из packages.config и файла проекта (ProjectReferences).
Версия пакета формируется с использованием Major и Minor версии, в качестве Build используется номер чейнджсета в локальном хранилище кода. Если пакет собирается для отладки, то добавляется Revision, равный номеру дня в месяце + количество секунд от полуночи поделенное на 4. Таким образом пакет в релизе имеет версию, например 1.5.2608, в отладке 1.5.2608.2721276, причем после завершения отладки и чекина, релизный пакет имеет версию, например 1.5.2609. Это упрощает отладку пакета в прикладном решении, так как не нужно руками откатывать версию пакета — после чекина достаточно просто сделать update.
Перед публикацией мы запрашиваем список пакетов из галереи и отсекаем существующие дабы не тормозить на попытках опубликовать пакет, который уже присутствует на сервере. Это помогает нам не публиковать отладочные пакеты в общую галерею и, вместе с тем, позволяет нормально отлаживать пакеты в прикладном решении.

На текущий момент для сборки и публикации пакетов достаточно вызвать билд из веб-интерфейса билд-сервера, что сильно экономит время.
Получается, во многом у нас вышли похожие решения по части версионирования.
По поводу файлов спецификации — мы добавили шаблоны *.nuspec с replacement tokens прямо в проекты и собираем пакеты на их основе. Это позволяет добиться еще одного приятного момента — не приходится управлять тем, из каких проектов собирать пакеты, а из каких нет. У кого есть nuspec — из того и собирается. А всякие тестовые проекты и те, работа над которыми еще только-только началась и до релиза им еще далеко просто проходят этап билда и прогона тестов.
В ближайшее время мы выпустим вторую часть статьи, там расскажем в деталях как это все сделано у нас.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий