Управление версиями сборки с помощью TeamCity

Question

Я работаю над проектом C # / VB.Net, который использует SVN и сервер сборки TeamCity.В процессе сборки создается около дюжины сборок.Я хочу контролировать версии сборки так, чтобы все они совпадали, а также соответствовали ярлыку сборки TeamCity.

Я настроил TeamCity на использование метки сборки из

Основной.Второстепенный.{Сборка}.{Доработка}

Где Major и Minor - это константы, которые я устанавливаю вручную, {Revision} определяется версией репозитория SVN при оформлении заказа, а {Build} - это автоматически увеличивающийся счетчик сборки TeamCity.Таким образом, примером метки сборки может быть

2.5.437.4423

Какие методы вы бы предложили, чтобы гарантировать, что все версии сборки соответствуют ярлыку сборки TeamCity?

Answer 1

Мы используем CruiseControl.net и SVN.Мы едем на нем в другую сторону.Мы используем Задачи MSBuildCommunityTasks Задача версии в скрипте MSBuild увеличить номер версии для сборок CI и использовать этот номер версии для пометки исходного кода.

Редактировать: Запросил более подробную информацию о целях MSBuild...
Мы используем отдельный скрипт, предназначенный для сборки CI и не используемый для сборок разработчика.Мы пытались использовать разные целевые объекты в файлах MSBuild, которые studio использует в качестве файлов проекта, но это стало головной болью и потребовало ручного редактирования файлов, которые создавала studio.
Структура файла MSBuild довольно проста:

1. Импортируйте дополнительные части

   <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<!-- contains some variables that set project names, paths etc. -->
<Import Project="Properties.msbuild"/>

2. Перед постройкой:установите новый номер версии и перепишите файл AssemblyInfo заново

   <Version VersionFile="$(VersionFile)" BuildType="None" RevisionType="Increment">
<Output TaskParameter="Major" PropertyName="Major" />
<Output TaskParameter="Minor" PropertyName="Minor" />
<Output TaskParameter="Build" PropertyName="Build" />
<Output TaskParameter="Revision" PropertyName="Revision" />
</Version>

   <!--Modify Assembly Info-->
<AssemblyInfo CodeLanguage="CS"
OutputFile="Properties\AssemblyInfo.cs"
AssemblyTitle="$(TargetAssembly)"
AssemblyDescription="$(AssemblyDescription) svn:@(SanitizedSvnUrl) revision:$(SvnRevision)"
AssemblyCompany="Your company name"
AssemblyProduct="Name of product"
AssemblyCopyright="Copyright © your company 2009"
ComVisible="false" Guid="$(WindowGuid)"
AssemblyVersion="$(Major).$(Minor).$(Build).$(Revision)"
AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)"
Condition="$(Revision) != '0' " />

3. Строить:создайте фактический файл проекта MSBuild script в режиме выпуска

4. Последующая сборка:мы запускаем наши проекты модульного тестирования (в качестве защиты от создания тегов для неработающих сборок на следующих шагах), используем задачи SvnInfo и некоторые задачи RegexReplace, чтобы задать некоторым переменным пути и имена тегов, и используем задачу SvnCopy для создания тега.

<SvnCopy UserName="username"
Password="password"
SourcePath="@(SvnTrunkPath)"
DestinationPath="@(SvnTagsPath)/BUILD-$(TargetAssembly)-$(Major).$(Minor).$(Build).$(Revision)" Message="Tagging successful build" />

Answer 2

Я бы предложил использовать функцию сборки AssemblyInfo patcher от TeamCity:

http://confluence.jetbrains.net/display/TCD65/AssemblyInfo+Patcher

Просто создайте свои проекты в VisualStudio, настройте функцию сборки на странице BuildSteps (см. http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features), и пока вы сохраняете файл AssemblyInfo.cs по умолчанию, он будет работать.

Этот подход отлично работает для меня.

Преимущества:

• Разработчики могут создать решение на своих машинах.
• Вам не нужно прикасаться к файлам .sln или .csproj.Это просто работает.
• Используя переменные TeamCity, вы можете легко сопоставить номер версии с версией какого-нибудь другого проекта и т.д.

Недостатки:

• Вы не можете легко переключиться на другой сервер CI из TeamCity, потому что у вас нет сценария сборки (но переключение серверов CI похоже на переключение ORM или базы данных:это очень маловероятно и в любом случае потребует много работы).

Answer 3

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

Я поддерживаю 2 отдельные конфигурации сборки в TeamCity, одна из которых - сборка CI, а другая - сборка, которая выполняется еженедельно при внесении каких-либо изменений (или вручную) и является нашей официальной релизной сборкой.Я выбрал подход с двумя сборками, потому что сквозная сборка занимает, возможно, 40 минут, и я хотел, чтобы разработчики получали быструю обратную связь по любым проблемам сборки при внесении изменений.Таким образом, сборка CI является подмножеством полной сборки выпуска, но она создает весь код.Управление версиями также отличается между двумя сборками:

• Сборка CI имеет номера версий {Major.minor.BuildCounter.SvnRevision}
  • BuildCounter начинается с 0
  • не помечает репозиторий svn
• Еженедельная сборка / Release имеет аналогичную систему управления версиями, но
  • счетчик сборки начинается с (Major * 1000), поэтому, если Major равен "8", счетчик сборки начинается с 8000.
  • Создает тег с именем 'Build_{Version}' в репозитории svn

Причина этого несколько произвольного выбора заключается в том, чтобы позволить нам четко и просто проводить различие между сборками CI и сборками Release.

У нас есть файл для всего решения под названием AssemblyVersionInfo, который включен (программно связан) в каждый проект решения.Файл содержит (по сути) следующее:

using System.Reflection;
// Revision and Build both set to 9999 indicates a private build on a developer's private workstation.
[assembly: AssemblyFileVersion("6.0.9999.9999")]        // Win32 File Version (not used by .NET)

Таким образом, все сборки разработчика используют один и тот же статический и легко идентифицируемый номер версии, который выше, чем любой другой, созданный сервером сборки, так что в конфликте версий выигрывает файл разработчика.

На сервере сборки мы используем задачи сообщества MSBuild для создания нового файла AssemblyVersionInfo, который перезаписывает содержимое по умолчанию.Мы используем строку сборки TeamCity в качестве новой версии.Таким образом, мы можем легко различить следующие 3 ситуации:

• Частная сборка, выполняемая на рабочей станции разработчика
• Сборка CI, выполняемая на сервере сборки, но которая не должна быть выпущена
• Официально санкционированная сборка релиза, которая помечена в репозитории Svn

С другой стороны, обратите внимание, что я устанавливаю AssemblyFileVersion, не AssemblyVersion.Мы заставляем наши версии сборки представлять собой статическую, фиксированную строку версии 'Major.Minor.0.0'.Мы делаем это для того, чтобы иметь возможность выпускать версии для исправления ошибок, не беспокоясь о проблемах с управлением версиями.AssemblyFileVersion позволяет нам выяснить, какую сборку установил пользователь, не являясь частью идентификатора сборки.

Answer 4

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

Для крупных проектов может потребоваться обновление большого количества файлов информации о сборке, и при постоянном повторном разложении всегда существует риск того, что сценарий сборки не знает о новых файлах, которые необходимо обновить.

По этой причине мы создали простой файл кода, который определяет константу для фактической версии, а затем все проекты наследуют эту константу и us в файле assembly info.Тогда скрипту сборки потребуется обновить только один файл.

Другим преимуществом здесь является то, что это также несколько ускоряет процесс сборки, поскольку для этого не нужно просматривать множество файлов и вносить изменения.