Я оставляю ответ Хэмиша как принятый ответ, но для полноты я подумал, что стоило бы документировать подход, который мы наконец приняли.
Я поддерживаю 2 отдельные конфигурации сборки в 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, который включается (мягко связан) в каждый проект решения. Файл содержит (по сути) это:
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 позволяет нам выяснить, какую сборку установил пользователь, не являясь частью идентификации сборки.