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

Question

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

• Мой проект
  • Приложение A
  • Shared1
  • Shared2
  • Заявка B
  • Приложение C

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

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

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

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

Решение "CrusieControl Build Labels"

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

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

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

Решение "Номер редакции"

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

Суммировать

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

1. Уметь отслеживать номер сборки / редакции сборки и развернутой DLL.
2. сможет перестроить прошлую ревизию/ build, установить старый номер сборки / ревизии для исполняемых файлов этой сборки (для соответствия требованию 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

1. Пусть CC.net пометит успешные сборки
2. иметь каждый проект в решении ссылку на общий файл solutioninfo.cs, который содержит атрибуты сборки и версии файла (удалить из каждого проекта assemblyinfo.cs)
3. Перед сборкой с круиз-контролем выполните команду msbuild regex replace (из задач сообщества msbuild), чтобы обновить информацию о версии с помощью метки сборки cc.net (переданной в качестве параметра в задачу msbuild)
4. построить решение, запустить тесты, fx cop и т. Д.
5. При желании можно восстановить файл информации о решении

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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

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

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