Выполнение сборки с TeamCity

Question

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

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

MAJOR.MINOR. {Строить}. {} Revision

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

2.5.437.4423

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

Answer 1

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

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

1. Импортировать части

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

2. BeforeBuild: установить новый номер версии и перепишем 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 сценария в режиме выпуска

4. Af terBuild: мы запускаем наши тестовые проекты (как защитник от создания тегов для разбитых сборок в следующих шагах), используйте задачи 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 патчер сборки Teamcity в:

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

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

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

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

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

Недостатки:

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

Answer 3

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

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

• сборки CI имеет номер версии {Major.minor.BuildCounter.SvnRevision}
  • BuildCounter начинается с 0
  • не помечать в репозиторий SVN
• Параметр/сборки выпуска Еженедельно имеет подобную систему управления версиями, но
  • счетчик сборки начинается (Major * 1000), так что если майор является «8», бу ИСД счетчик начинается с 8000.
  • Создает тег под названием «Build_ {Version}» в репозитории SVN

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

У нас есть файл решения, называемый 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 Community Tasks создаем новый файл AssemblyVersionInfo, который перезаписывает содержимое по умолчанию. Мы используем строку сборки TeamCity как новую версию.Таким образом, можно легко различить следующие 3 ситуации:

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

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

Answer 4

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

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

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

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