4

我运行一个包含多个独立应用程序的相当复杂的项目。然而，这些使用了几个共享组件。所以我有一个类似于下面的源代码树。

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

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

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

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

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

“CrusieControl 构建标签”解决方案

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

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

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

“修订号”解决方案

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

总结

所以两个主要要求是：

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

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

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

4

4 回答 4

8

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

对于您的“CI”构建 - 您将执行版本控制，查看具有“版本”任务的MSBuild 社区任务项目。通常，您的源代码树中有一个“Version.txt”，MSBuild 任务将增加“发布”编号，而开发人员控制 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

于 2008-09-12T00:47:55.197 回答
3

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

谢谢！好答案！有什么区别，例如使用 SubVersion 更好地解决这个问题？Richard Hallgren（15 小时前）

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

以下是 VSS 的一些问题

1) 分支基本上是不可能的 2) 通常不使用共享结帐（我知道有几个人已经成功了） 3) 性能很差 - 它非常“健谈” 4) 除非你有一个非常小的存储库- 这完全不可靠，对于大多数商店来说，这是一颗定时炸弹。

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

所以看看你的存储库大小——如果你进入千兆字节——我强烈建议你开始计划更换 VSS。

无论如何-“VSS Sucks”的谷歌提供了 30K 次点击...我认为如果您确实开始使用替代品-您会意识到这是非常值得的努力。

于 2008-09-12T21:36:13.607 回答
3
  1. 让 CC.net 标记成功的构建
  2. 将解决方案中的每个项目链接到一个通用的 solutioninfo.cs 文件，该文件包含程序集和文件版本属性（从每个项目的 assemblyinfo.cs 中删除）
  3. 在构建之前，巡航控制运行 msbuild 正则表达式替换（来自 msbuild 社区任务）以使用 cc.net 构建标签更新版本信息（作为参数传递给 msbuild 任务）
  4. 构建解决方案、运行测试、fx cop 等
  5. 可选择还原解决方案信息文件

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

于 2008-09-23T07:28:30.687 回答
0

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

它也非常容易上手。

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

这里有一些很好的解释：Uppercut

于 2009-05-16T18:17:27.670 回答