管理构建版本的最佳构建流程解决方案

Question

我运行一个相当复杂的项目，有几个独立的应用程序。然而，它们使用了几个共享组件。所以我有一个源树，如下所示。

• 我的项目
  • 应用A
  • 共享1
  • 共享2
  • 应用B
  • 应用C

所有应用程序都有自己的 MSBuild 脚本，用于构建项目及其所需的所有共享资源。我还在 CruiseControl 控制的持续集成构建服务器上运行这些构建。

部署应用程序时，它们会部署在多台服务器上以分配负载。这意味着它是 极其 跟踪每个不同服务器上部署的构建/修订版本非常重要（我们需要在 DLL 版本中包含当前版本，例如“1.0.0.68”）。

同样重要的是能够重新创建一个修订/构建，如果某些事情没有按预期进行，则能够回滚（是的，这种情况发生了......）。今天，我们使用 SourceSafe 进行源代码控制，但如果我们能提出充分的理由，这种情况就有可能改变（SS 它实际上对我们来说工作正常 所以 远的）。

我们尝试遵循的另一个原则是，只有由我们进一步部署的集成服务器构建和测试的代码。

“CrusieControl 构建标签”解决方案

我们对解决上述问题有几个想法。第一个是让持续集成服务器构建并在本地部署项目并测试它（现在就是这样做的）。您可能知道 CruiseControl 中的成功构建会生成一个构建标签，我想我们可以以某种方式使用它来设置可执行文件的 DLL 版本（因此构建标签 35 将创建一个类似于“1.0.0.35”的 DLL）？这个想法也是使用这个构建标签来标记 完全的 源树。然后我们可能可以通过该标签进行检查并稍后重新创建构建。

标记完整树的原因是不仅包括实际的应用程序代码（位于源树中的一个位置），还包括所有共享项（位于树中的不同位置）。因此，“应用程序 A”的成功构建将使用标签“ApplicationA35”来标记整个树。

然而，在部署之前尝试重新创建此构建并设置 DLL 版本时可能会出现问题，因为我们将无法再访问 CruiseControl 生成的构建标签。如果所有 CrusieControl 构建标签对于所有项目都是唯一的，我们可以仅使用数字进行标签，但情况并非如此（应用程序 A 和 B 可以同时位于构建 35 上），因此我们必须在构建中包含应用程序名称标签。因此 SourceSafe 标签为“Application35”。 一旦我们构建了 build 35，我如何重新创建 build 34 并将 1.0.0.34 设置为 DLL 版本号？

“修订号”解决方案

有人告诉我，Subversion 在每次签入时都会为整个源代码树创建一个修订号 – 是这样吗？SourceSafe 有类似的东西吗？ 如果这是正确的，那么想法就是在获取最新版本时获取该修订号并在 CruiseControl 服务器上构建。然后可以使用修订号来设置 DLL 版本号（例如“1.0.0.5678”）。我想如果需要的话，我们可以得到 Subversion 的这个特定修订版，然后将包括该应用程序和所有共享项目，以便能够重新创建过去的特定版本。 这可行吗？也可以使用 SourceSafe 来实现吗？

总结

所以两个主要要求是：

1. 能够 跟踪构建和部署的 DLL 的构建/修订号。
2. 能够 重建过去的修订/版本，在该版本的可执行文件上设置旧的版本/修订号 （符合要求1）。

那么你会如何解决这个问题呢？ 您首选的方法是什么？ 如何 你会解决这个问题吗（或者你有完全不同的想法吗？）？**请给出详细的答案。**

奖金问题 修订号和内部版本号之间有什么区别？什么时候真正需要两者？

Answer 1

你的方案是合理的并且可以在VSS中实现（尽管我建议你考虑替代方案，VSS确实是一个过时的产品）。

对于您的“CI”构建 - 您需要查看版本控制 MSBuild 社区任务项目 其中有一个“版本”任务。通常，您的源代码树中会有一个“Version.txt”，MSBuild 任务将增加“Release”编号，而开发人员控制 Major.Minor.Release.Revision 编号（这就是我的客户想要的方式）。如果您愿意，可以使用修订版。

然后，您将有一个“FileUpdate”任务来编辑该版本的 AssemblyInfo.cs 文件，并且您的 EXE 和“DLL”将具有所需的版本。

最后，VSSLabel 任务将为您的所有文件添加适当的标签。

对于“重建”构建 - 您将修改“获取”以从该标签获取文件，显然不执行“版本”任务（因为您正在选择要构建的版本），然后 FileUpdate 任务将使用该版本号。

奖金问题：

这些都是“你想如何使用它们” - 我会使用内部版本号，以及内部版本号，这就是我要增加的内容。如果您使用 CI，您将拥有非常多的构建 - 绝大多数都无意部署到任何地方。

主要和次要是不言而喻的 - 但我一直将修订版用于“修补程序”指示器。我打算发布“1.3”版本 - 实际上这将是一个版本为 1.3.1234.0 的产品。在开发 1.4 时 - 我发现了一个错误 - 并且需要 1.3.2400.1 的热修复。然后当 1.4 准备就绪时 - 会说 1.4.3500.0

Answer 2

我需要更多的空间，而不是直接回复评论，因为评论允许......

谢谢！好答案！有什么区别，例如，使用颠覆来更好地解决这个问题？

VSS 的问题与此示例无关（尽管我认为“标签”功能的实现效率很低......）

下面是VSS的一些问题

1）基本上是不可能的2）通常不使用共享结帐（我知道有几个与之成功的人）3）性能很差 - 外部“ chatty” 4），除非您有一个很小的存储库 - 这是完全不可靠的，对于大多数商店而言，这是一个滴答时间炸弹。

对于 4 - 问题是 VSS 是通过在文件系统中表示为“平面文件”的整个存储库来实现的。当存储库超过一定大小（我相信 4GB，但我对这个数字没有信心）时，您就有机会“损坏”。随着规模的增加，腐败的可能性也会增加，直到几乎确定无疑。

因此，请查看您的存储库大小 - 如果您的存储库大小达到千兆字节 - 我强烈建议您开始计划替换 VSS。

无论如何 - 谷歌的“VSS Sucks”给出了 3 万次点击......我认为如果您确实开始使用替代方案 - 您会意识到这是非常值得的。

Answer 3

1. 让 CC.net 标记成功的构建
2. 将解决方案中的每个项目链接到一个公共的 SolutionInfo.cs 文件，该文件包含程序集和文件版本属性（从每个项目的 assemblyinfo.cs 中删除）
3. 在构建之前，让 Cruise Control 运行 msbuild 正则表达式替换（来自 msbuild 社区任务），以使用 cc.net 构建标签（作为参数传递给 msbuild 任务）更新版本信息
4. 构建解决方案、运行测试、FX 警察等
5. （可选）恢复解决方案信息文件

结果是 cc.net 发布的版本中的所有程序集都具有相同的版本号，符合源代码存储库中的标签

Answer 4

UppercuT 可以通过自定义打包任务来拆分应用程序来完成所有这些操作。要获取源代码的版本号，您可能会考虑 Subversion。

上手也非常容易。

http://code.google.com/p/uppercut/

这里有一些很好的解释： 上勾拳