Лучшее решение для процесса сборки для управления версиями сборки

Question

Я запускаю довольно сложный проект с несколькими независимыми приложениями.Однако они используют несколько общих компонентов.Итак, у меня есть дерево исходного кода, выглядящее примерно так, как показано ниже.

• Мой проект
  • Приложение А
  • Общий1
  • Общий2
  • Приложение Б
  • Приложение С

Все приложения имеют собственный сценарий MSBuild, который создает проект и все необходимые ему общие ресурсы.Я также запускаю эти сборки на сервере непрерывной интеграции, контролируемом CruiseControl.

При развертывании приложений они развертываются на нескольких серверах для распределения нагрузки.Это означает, что это очень сильно важно отслеживать, какая сборка/ревизия развернута на каждом из разных серверов (нам необходимо иметь текущую версию в версии DLL, например «1.0.0.68»).

Не менее важно иметь возможность воссоздать созданную ревизию/сборку, чтобы иметь возможность откатиться назад, если что-то пошло не так, как задумано (о да, такое случается...).Сегодня мы используем SourceSafe для контроля версий, но это можно изменить, если мы представим веские причины для этого (SS на самом деле у нас работает нормально). так далеко).

Еще один принцип, которому мы стараемся следовать, заключается в том, что дальше мы развертываем только код, созданный и протестированный сервером интеграции.

Решение «Метки сборки CrusieControl»

У нас было несколько идей по решению вышеизложенного.Первым было собрать сервер непрерывной интеграции, локально развернуть проект и протестировать его (сейчас это происходит).Как вы, наверное, знаете, при успешной сборке CruiseControl генерируется метка сборки, и я думаю, мы могли бы каким-то образом использовать ее для установки версии DLL наших исполняемых файлов (поэтому метка сборки 35 создаст DLL типа «1.0.0.35»)?Идея заключалась также в том, чтобы использовать эту метку сборки для обозначения полный исходное дерево.Тогда мы, вероятно, могли бы проверить эту метку и позже воссоздать сборку.

Целью маркировки полного дерева является включение не только фактического кода приложения (который находится в одном месте исходного дерева), но и всех общих элементов (которые находятся в разных местах дерева).Таким образом, успешная сборка «Приложения A» будет помечать все дерево, например, меткой «ApplicationA35».

Однако может возникнуть проблема при попытке воссоздать эту сборку и установке версии DLL перед развертыванием, поскольку в этом случае у нас больше не будет доступа к метке сборки, сгенерированной CruiseControl.Если бы все метки сборки CrusieControl были уникальными для всех проектов, мы могли бы использовать для маркировки только номер, но это не так (приложения A и B могут одновременно находиться в сборке 35), поэтому нам приходится включать имя приложения в этикетка.Отсюда и метка SourceSafe «Application35». Как мне затем воссоздать сборку 34 и установить 1.0.0.34 для номеров версий DLL после создания сборки 35?

Решение «Номер ревизии»

Кто-то сказал мне, что Subversion, например, создает номер версии для всего дерева исходного кода при каждой проверке — это так?Есть ли в SourceSafe что-то подобное? Если это правильно, идея состоит в том, чтобы получить этот номер версии при получении последней версии и построить ее на сервере CruiseControl.Номер версии затем можно использовать для установки номера версии DLL (например, «1.0.0.5678»).Я думаю, мы могли бы затем получить эту конкретную версию для Subversion, если это необходимо, и тогда она будет включать в себя это приложение и все общие элементы, чтобы иметь возможность воссоздать конкретную версию из прошлого. Будет ли это работать и можно ли этого добиться с помощью SourceSafe?

Подведем итог

Итак, два основных требования:

1. Быть способным отслеживать номер сборки/версии сборки и развернутой DLL.
2. Быть способным пересобрать предыдущую версию/сборку, установить старый номер сборки/версии в исполняемых файлах этой сборки (для выполнения требования 1).

Так как бы вы это решили? Какой подход вы бы предпочли и как вы бы решили ее (или у вас есть совершенно другая идея?)?**Пожалуйста, дайте подробные ответы.**

Бонусный вопрос В чем разница между номером версии и номером сборки и когда действительно могут понадобиться оба?

Answer 1

Ваша схема надежна и достижима в VSS (хотя я бы посоветовал вам рассмотреть альтернативу, VSS действительно устаревший продукт).

Для вашей сборки «CI» вы должны выполнить управление версиями и посмотреть Проект задач сообщества MSBuild у которого есть задачи «Версия».Обычно в вашем дереве исходного кода будет файл «Version.txt», и задача MSBuild будет увеличивать номер «Release», в то время как разработчики контролируют номера Major.Minor.Release.Revision (так хотел мой клиент).Если хотите, вы можете использовать ревизию.

Затем у вас будут задачи «FileUpdate» для редактирования файла AssemblyInfo.cs с этой версией, и ваши EXE-файлы и «DLL» будут иметь желаемую версию.

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

Для вашей сборки «Перестроить» - вы должны изменить свой «Получить», чтобы получить файлы с этой метки, очевидно, не выполняя задачу «Версия» (поскольку вы ВЫБИРАЕТЕ версию для сборки), а затем задачи FileUpdate будут использовать этот номер версии.

Бонусный вопрос:

Это все «как вы хотите их использовать» - я бы использовал номер сборки, ну, номер сборки, это то, что я бы увеличил.Если вы используете CI, у вас будет очень много сборок — подавляющее большинство из них не собираются когда-либо где-либо развертываться.

Основные и второстепенные значения очевидны, но я всегда использовал версию индикатора «Исправление».Я планирую выпустить версию «1.3», которая на самом деле будет продуктом, скажем, версии 1.3.1234.0.Пока работаю над 1.4 - обнаружил ошибку - и нужен хот фикс как 1.3.2400.1.Потом когда будет готова 1.4 - будет скажем 1.4.3500.0

Answer 2

Мне нужно больше места, чем позволяет ответ, поскольку комментарии напрямую позволяют...

Спасибо!Хороший ответ!В чем будет разница, что будет лучше решать это, например, подрыв? Ричард Халлгрен (15 часов назад)

Проблемы с VSS не имеют никакого отношения к этому примеру (хотя функция «Разметка», я считаю, реализована неэффективно...)

Вот несколько проблем с VSS

1) Ветвление в основном невозможно 2) Общая проверка, как правило, не используется (я знаю о нескольких человек, которые добились успеха с ним) 3) Производительность очень плохая - это экстерно «болтли» 4), если у вас нет очень маленького репозитория - Это совершенно ненадежно, вплоть до того, что для большинства магазинов это временная бомба.

Для 4 - проблема в том, что VSS реализован тем, что весь репозиторий представлен в файловой системе как "плоские файлы".Когда размер репозитория превышает определенный размер (я думаю, 4 ГБ, но я не уверен в этой цифре), у вас появляется шанс «повреждения».По мере увеличения размера вероятность коррупции растет, пока она не станет почти неизбежной.

Итак, взгляните на размер вашего репозитория — и если вы переходите к гигабайтам — я настоятельно рекомендую вам начать планировать замену VSS.

Несмотря ни на что - гугл "VSS Sucks" дает 30 тысяч просмотров...Я думаю, если вы начнете использовать альтернативу, вы поймете, что оно того стоит.

Answer 3

1. Попросите CC.net пометить успешные сборки.
2. каждый проект в решении должен ссылаться на общий файл Solutioninfo.cs, который содержит атрибуты сборки и версии файла (удалить из каждого проекта Assemblyinfo.cs)
3. Перед сборкой круиз-контроль запустите замену регулярного выражения msbuild (из задач сообщества msbuild), чтобы обновить информацию о версии с помощью метки сборки cc.net (передается в качестве параметра в задачу msbuild).
4. создайте решение, запустите тесты, FX COPS и т. д.
5. При необходимости верните файл информации о решении.

В результате все сборки в опубликованной сборке cc.net имеют одинаковые номера версий, соответствующие метке в репозитории исходного кода.

Answer 4

UppercuT может сделать все это с помощью специальной задачи упаковки для разделения приложений.А чтобы получить номер версии исходного кода, вы можете подумать о Subversion.

Начать также безумно легко.

http://code.google.com/p/uppercut/

Несколько хороших объяснений здесь: Апперкот