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

Ответ 1

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

РЕДАКТИРОВАТЬ: Заданы более подробные сведения о целях MSBuild...
Мы используем отдельный script, который предназначен для сборки CI и не используется для сборки разработчика. Мы пытались использовать разные цели в файлах MSBuild, которые студия использует в качестве файлов проекта, но это стало головной болью и потребовало ручного редактирования файлов, которые создавала студия.
Структура файла MSBuild довольно проста:

• Импортируйте дополнительные фрагменты

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

• 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' " />

• Сборка: сборка фактического файла проекта MSBuild script в режиме выпуска

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

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

Ответ 2

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

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, потому что у вас нет сборки script (но переключение CI-серверов подобно переключению ORM или базы данных: это очень маловероятно и потребует много работы в любом случае).

Ответ 3

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

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

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

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

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

using System.Reflection;
// Revision and Build both set to 9999 indicates a private build on a developer 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 позволяет нам выяснить, какую сборку пользователь установил, не входя в идентификатор сборки.

Ответ 4

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

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

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

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