想知道.NET构建版本控制的最佳方法是什么?
我使用:
- TFS 2013进行版本控制
- TFS门禁检查
- Wix 3.8将代码打包到MSI文件中
我想设置以下内容的版本号:
- 程序集(AssemblyInfo.cs,或在所有项目中引用的共享文件)
- MSI包(在Wix代码中)
- 文档(例如在构建的最终输出中的readme.txt文件内部)
- 等等
理想的版本号应该允许追溯安装的软件到确切的源代码。类似于:
<Major>.<Minor>.<TFS_changeset_number>
我希望将我想要存储的版本的前两个部分存储在简单的文本\ XML文件中,与解决方案一起放入版本控制中,因为我认为它们应该在一起。开发人员将手动更新此文件(例如遵循语义化版本控制方法)。每个构建都将读取此版本文件,从调用CI工具获取版本的第三部分,并使用该版本更新所有必要的文件。
最佳实现方式是什么?
我过去尝试了一些方法:
1)NAnt \ MsBuild包装器执行版本控制工作,然后调用MsBuild解决方案。它可以从CI工具(Jenkins \ TeamCity \等)调用。
问题 - 与TFS门控提交的集成不美观,因为我需要两次构建解决方案。
2)自定义TFS构建过程模板
问题 - 它不太简单,并会导致TFS升级时进行一些合并工作。此外,在门控提交中还不存在变更集编号,因此我们只能使用先前的变更集id。
3)解决方案中的单独的MsBuild项目,仅执行此版本控制任务,并配置为在VS解决方案的Project Build顺序中首先运行。
问题 - 必须在所有其他项目(包括所有未来的项目)中引用此元项目,感觉不美观
我知道各种MsBuild和TFS扩展包可以简化更新。这个主题不是关于哪一个扩展包最好。这个问题比较方法论而不是技术性的。我还认为,如果Microsoft在其标准TFS构建模板中包含一些版本控制功能,那将是理想的选择。其他CI工具已经具备了这个功能(AssemblyInfo patcher)。
11/09/2014更新
我决定明确表达符合敏捷\持续交付最佳实践的版本控制原则:
1)能够重现任何历史构建
2)根据CD原则,作为第1点的结果,每个东西(源代码、测试、应用程序配置、环境配置、构建\打包\部署脚本等)都存储在版本控制下,因此分配了一个版本号
3)版本号紧密地与其适用的源代码一起存储
4)人们能够根据他们的业务\营销逻辑更新版本
5)只有一个主要版本副本,用于自动化构建\打包过程的所有部分
6)您可以轻松地说出目标系统当前安装的软件的版本号
7)安装的软件版本必须明确地标识用于构建它的源代码
8)很容易比较版本号以确定哪个版本较低或较高-控制允许哪些升级\降级方案及其实现细节
15/09/2014更新
请参见我的答案以下。
我很幸运找到了符合所有要求的解决方案!