Просто интересно, какой лучший подход к управлению версиями .NET сборки?
Я использую:
- TFS 2013 для контроля версий
- TFS gated check-ins
- Wix 3.8 для кода пакета для файлов MSI
Я хочу установить версию:
- сборки (AssemblyInfo.cs или общий, упомянутый во всех проектах)
- Пакеты MSI (в коде Wix)
- (например, внутри файла readme.txt в конечном результате сборки)
- и т.д.
Идеальный номер версии позволит отслеживать установленное программное обеспечение обратно в точный исходный код.
Что-то вроде:
<Major>.<Minor>.<TFS_changeset_number>
Первые две части версии, которые я хочу хранить в некотором простом текстовом файле \XML в управлении версиями рядом с решением, поскольку я считаю, что они должны жить вместе. Разработчики будут обновлять этот файл вручную (например, после подхода Semantic Versioning). Каждая сборка будет читать этот файл версии, получить 3d часть версии от вызывающего инструмента CI и обновить все необходимые файлы с помощью версии.
Какой лучший способ реализовать это?
В прошлом я использовал несколько подходов:
1) Обертка NAnt\MsBuild, которая работает с этой версией, затем вызывает MsBuild для решения. Его можно вызвать из инструмента CI (Jenkins\TeamCity\etc).
Проблема - интеграция с закрытой проверкой TFS является уродливой, поскольку я строю решение дважды.
2) настроить шаблон процесса сборки TFS
Проблема - это не так просто и вызывает некоторую работу слияния при обновлении TFS. Также номер набора изменений еще не существует в закрытых регистрационных записях, поэтому мы можем использовать только предыдущий идентификатор набора изменений.
3) Отдельный проект MsBuild в решении, который выполняет только эту задачу управления версиями, и сконфигурирован для запуска сначала в Project Build Order решения VS.
Проблема - нужно ссылаться на этот метапроект во всех других проектах (включая все будущие), которые кажутся уродливыми
Я знаю разные пакеты расширения MsBuild и TFS, которые могут упростить обновления. Эта тема не о том, какая из них лучшая. Вопрос более методологический, чем технический.
Я также думаю, что было бы идеально, если бы Microsoft включила что-то для управления версиями в свой стандартный шаблон сборки TFS. Другие инструменты CI уже имеют эту функциональность (AssemblyInfo patcher).
ОБНОВЛЕНИЕ 11/09/2014
Я решил четко выразить Принципы управления версиями, которые будут соответствовать лучшим практикам Agile\Continuous Delivery:
1) Возможность воспроизведения любой исторической сборки
2) В результате 1) и в соответствии с принципами CD все (исходный код, тесты, конфиги приложений, env configs, build\package\deploy scripts и т.д.) хранятся под контролем версий и поэтому имеют версию, назначенную это
3) Номер версии хранится плотно вместе с исходным кодом, который он применяет для
4) Люди могут обновлять версию в соответствии с их бизнес-логикой маркетинга
5) Существует только 1 основная копия версии, которая используется во всех частях процесса автоматической сборки\упаковки
6). Вы можете легко сказать, какая версия программного обеспечения в настоящее время установлена в целевой системе.
7) Версия установленного программного обеспечения должна однозначно идентифицировать исходный код, который использовался для его сборки
8) Очень просто сравнить версии, чтобы сказать, что ниже, а что выше - контролировать, какие сценарии upgrade\downgrade разрешены, и особенности их реализации
ОБНОВЛЕНИЕ 15/09/2014
Посмотрите мой собственный ответ ниже.
Мне посчастливилось найти решение, отвечающее всем моим требованиям!