管理构建版本的最佳构建流程解决方案
-
09-06-2019 - |
题
我运行一个相当复杂的项目,有几个独立的应用程序。然而,它们使用了几个共享组件。所以我有一个源树,如下所示。
- 我的项目
- 应用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 来实现吗?
总结
所以两个主要要求是:
- 能够 跟踪构建和部署的 DLL 的构建/修订号。
- 能够 重建过去的修订/版本,在该版本的可执行文件上设置旧的版本/修订号 (符合要求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
其他提示
我需要更多的空间,而不是直接回复评论,因为评论允许......
谢谢!好答案!有什么区别,例如,使用颠覆来更好地解决这个问题?
VSS 的问题与此示例无关(尽管我认为“标签”功能的实现效率很低......)
下面是VSS的一些问题
1)基本上是不可能的2)通常不使用共享结帐(我知道有几个与之成功的人)3)性能很差 - 外部“ chatty” 4),除非您有一个很小的存储库 - 这是完全不可靠的,对于大多数商店而言,这是一个滴答时间炸弹。
对于 4 - 问题是 VSS 是通过在文件系统中表示为“平面文件”的整个存储库来实现的。当存储库超过一定大小(我相信 4GB,但我对这个数字没有信心)时,您就有机会“损坏”。随着规模的增加,腐败的可能性也会增加,直到几乎确定无疑。
因此,请查看您的存储库大小 - 如果您的存储库大小达到千兆字节 - 我强烈建议您开始计划替换 VSS。
无论如何 - 谷歌的“VSS Sucks”给出了 3 万次点击......我认为如果您确实开始使用替代方案 - 您会意识到这是非常值得的。
- 让 CC.net 标记成功的构建
- 将解决方案中的每个项目链接到一个公共的 SolutionInfo.cs 文件,该文件包含程序集和文件版本属性(从每个项目的 assemblyinfo.cs 中删除)
- 在构建之前,让 Cruise Control 运行 msbuild 正则表达式替换(来自 msbuild 社区任务),以使用 cc.net 构建标签(作为参数传递给 msbuild 任务)更新版本信息
- 构建解决方案、运行测试、FX 警察等
- (可选)恢复解决方案信息文件
结果是 cc.net 发布的版本中的所有程序集都具有相同的版本号,符合源代码存储库中的标签
UppercuT 可以通过自定义打包任务来拆分应用程序来完成所有这些操作。要获取源代码的版本号,您可能会考虑 Subversion。
上手也非常容易。
http://code.google.com/p/uppercut/
这里有一些很好的解释: 上勾拳