Комментарии 14
можно просто сделать шару и на неё класть пакеты — nuget это дело вполне понимает. Ну а права разрулить шарой уже не представляет труда)
Мы сначало то же так делали, но потом пришли к тому, что за каждым пакетом прикреплен свой мэинтэйнер, который за него отвечает и переехали на галерею. Теперь понятно кто и когда что менял и обновлял).
Проще надо быть, проще: сборка и выкладка пакета в репо может быть осуществлена только CI сервером, версии (соответственно) видны в исходниках, равно как и все изменения… В целом, я конечно, не говорю что делать сацтец с RSS и прочими это неправильно, но стоит подобную технику тоже незабывать…
Ну тут еще вопрос ведения истории встал) очень важно что бы пакеты случайно кто-то не перетер и не подменил. Поэтому у всех доступ закрыт нафиг. А публикацию делает не CI сервер, а AddIn для студии, где указывается api ключик. Если у вас билд номер увеличивается с каждым билдом — очень ыбстро надоест обновлять пакеты))
Добрый вечер. В общем-то мы так и сделали — кладет пакеты в ленты только build-машина.
Что касательно папок или сайтов — все по потребностям. Для полноценной поддержки процесса нам понадобилось три ленты, и самое главное — symbol-server. Он был необходим как воздух.
Дело в том, что количество кода, который не можно, а нужно положить в ленту у нас действительно большое. Вот и требования к инфраструктуре соответствующие.
Что касательно папок или сайтов — все по потребностям. Для полноценной поддержки процесса нам понадобилось три ленты, и самое главное — symbol-server. Он был необходим как воздух.
Дело в том, что количество кода, который не можно, а нужно положить в ленту у нас действительно большое. Вот и требования к инфраструктуре соответствующие.
А не смотрели как в последних версиях сделан переключатель Stable Only/Include Prerelease?
Да, смотрели.
Вообще это было одной из тем для второй статьи.
Если идти по стандарту semantic versioning по которому мы как раз и пошли, и по которому идет nuget, то получается что весьма вероятная ситуация, когда мы внесли изменение, не повлекшее изменения API, поэтому меняем в версии формата Major.Minor.Patch только Patch.
При этом, получается, что пакет, допустим, версии 1.2 был релизный, и тут вдруг опять появляется его beta.
То есть prerelease это фича хорошая, но использовать ее в day-to-day разработке нам показалось не очень логично.
Мы решили оставить эту штуку на другие случаи.
Например, когда обстоятельства вынуждают нас сделать быстрый релиз чего-либо нового и не протестированного и это явный сигнал всем, что команде не стоит обновляться до этой версии, если эта версия не конкретно для нее.
Вообще это было одной из тем для второй статьи.
Если идти по стандарту 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 не будет изменена. Плюс как я уже писал выше — за каждым пакетом закреплен свой мэинтэйнер, и только он может обновлять его. Ну и огребать соответственно).
Отличная статья, сам планировал подобную.
Насчет сборки решения и публикации пакетов — мы поступили несколько иначе — подняли два билд-сервера.
На первом continious build для решения, на втором — сборка и публикация пакетов в корпоративную галерею.
Плюс у разработчиков есть скрипт для локальной сборки пакетов для тестирования без публикации.
Для того, чтобы не заморачиваться с формированием файла спецификаций, основную информацию мы собираем из атрибутов сборки (AssemblyCompany, AssemblyProduct, AssemblyVersion и т.д.), а зависимости — из packages.config и файла проекта (ProjectReferences).
Версия пакета формируется с использованием Major и Minor версии, в качестве Build используется номер чейнджсета в локальном хранилище кода. Если пакет собирается для отладки, то добавляется Revision, равный номеру дня в месяце + количество секунд от полуночи поделенное на 4. Таким образом пакет в релизе имеет версию, например 1.5.2608, в отладке 1.5.2608.2721276, причем после завершения отладки и чекина, релизный пакет имеет версию, например 1.5.2609. Это упрощает отладку пакета в прикладном решении, так как не нужно руками откатывать версию пакета — после чекина достаточно просто сделать update.
Перед публикацией мы запрашиваем список пакетов из галереи и отсекаем существующие дабы не тормозить на попытках опубликовать пакет, который уже присутствует на сервере. Это помогает нам не публиковать отладочные пакеты в общую галерею и, вместе с тем, позволяет нормально отлаживать пакеты в прикладном решении.
На текущий момент для сборки и публикации пакетов достаточно вызвать билд из веб-интерфейса билд-сервера, что сильно экономит время.
Насчет сборки решения и публикации пакетов — мы поступили несколько иначе — подняли два билд-сервера.
На первом 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 — из того и собирается. А всякие тестовые проекты и те, работа над которыми еще только-только началась и до релиза им еще далеко просто проходят этап билда и прогона тестов.
В ближайшее время мы выпустим вторую часть статьи, там расскажем в деталях как это все сделано у нас.
По поводу файлов спецификации — мы добавили шаблоны *.nuspec с replacement tokens прямо в проекты и собираем пакеты на их основе. Это позволяет добиться еще одного приятного момента — не приходится управлять тем, из каких проектов собирать пакеты, а из каких нет. У кого есть nuspec — из того и собирается. А всякие тестовые проекты и те, работа над которыми еще только-только началась и до релиза им еще далеко просто проходят этап билда и прогона тестов.
В ближайшее время мы выпустим вторую часть статьи, там расскажем в деталях как это все сделано у нас.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработчики в борьбе за эффективность программиста, команды, команд