.net - 版本控制 .NET 构建

Question

只是想知道 .NET 构建版本控制的最佳方法是什么？

我用:

用于版本控制的 TFS 2013

TFS 门禁签到

Wix 3.8 将代码打包成 MSI 文件

我想设置以下版本:

程序集(AssemblyInfo.cs，或所有项目中引用的共享程序集)

MSI 包(Wix 代码)

文档(例如在构建的最终输出中的 readme.txt 文件中)

等

理想的版本号将允许将安装的软件追溯到确切的源代码。
就像是:

<Major>.<Minor>.<TFS_changeset_number>

版本的前 2 部分我想存储在解决方案附近的版本控制中的一些简单文本\XML 文件中，因为我相信它们应该一起存在。开发人员将手动更新此文件(例如遵循语义版本控制方法)。每个构建都会读取这个版本文件，从调用 CI 工具中获取版本的 3d 部分，并使用该版本更新所有必要的文件。

实现这一点的最佳方法是什么？

我过去使用过一些方法:

1) NAnt\MsBuild 包装器执行此版本的工作，然后为解决方案调用 MsBuild。它可以从 CI 工具(Jenkins\TeamCity\等)调用。

问题 - 与 TFS 门控 checkin 的集成很难看，因为我构建了两次解决方案。

2)自定义TFS构建流程模板

问题 - 这不是那么简单，并且会导致一些 TFS 升级的合并工作。此外，门控 checkin 中尚不存在变更集编号，因此我们只能使用先前的变更集 ID。

3) 解决方案中单独的 MsBuild 项目，仅执行此版本控制任务，并配置为按 VS 解决方案的项目构建顺序首先运行。

问题 - 需要在所有其他项目(包括所有 future 项目)中引用这个元项目，这些项目感觉很难看

我知道可以简化更新的不同 MsBuild 和 TFS 扩展包。这个话题不是关于哪个是最好的。这个问题更多的是方法论而不是技术问题。

我还认为，如果 Microsoft 在其标准 TFS 构建模板中包含用于版本控制的内容，那将是理想的。其他 CI 工具已经具有此功能(AssemblyInfo patcher)。

更新 11/09/2014

我决定明确表达 版本控制原则 这将符合敏捷\持续交付的最佳实践:

1) 能够复制任何历史建筑

2) 作为 1) 的结果，根据 CD 原则，所有内容(源代码、测试、应用程序配置、环境配置、构建\包\部署脚本等)都存储在版本控制下，因此分配了一个版本

3) 版本号与其适用的源代码紧密存储在一起

4)人们可以根据他们的业务\营销逻辑更新版本

5) 版本只有1个主副本，用于自动化构建\打包过程的所有部分

6)您可以轻松说出目标系统上当前安装的软件版本

7) 安装软件的版本必须明确标识用于构建它的源代码

8) 比较版本来说明哪个较低哪个较高非常简单 - 控制允许哪些升级/降级场景以及它们的实现细节

更新 15/09/2014

看我自己的回答 below .
我很幸运找到了满足我所有要求的解决方案!

Answer 1

真悲哀，所有这些复杂的答案。

在 TFS 2013 中，这很简单。 Community TFS Build Extensions site提供了一个简单的 PowerShell 来从 TFS 分配的构建名称中提取构建编号。



您将内部版本号格式配置为“$(BuildDefinitionName)_6.0.0$(Rev:.r)”，这将导致类似于“6.0.0.1”的内容，其中每个版本的“1”都会递增。

然后，您将 PowerShell 版本控制脚本添加到您的构建中，它会自动抓取上面的版本号并将其应用于构建文件夹中的所有 AssemblyInfo.* 文件。您可以通过更新脚本来添加其他文件类型。