我用几个独立的应用程序运行一个相当复杂的项目 然而,这些使用了几个共享组件.所以我有一个类似于下面的源代码树.
我的项目
申请A.
Shared1
Shared2
申请B.
申请C.
所有应用程序都有自己的MSBuild脚本,用于构建项目及其所需的所有共享资源.我还在CruiseControl控制的持续集成构建服务器上运行这些构建.
部署应用程序后,它们将部署在多个服务器上以分配负载.这意味着跟踪每个不同服务器上部署的构建/修订是非常重要的(我们需要在DLL版本中使用当前版本,例如"1.0.0.68").
同样重要的是能够重新创建一个修订/构建,如果某些东西没有达到预期的效果,那么这些修订/构建能够回滚(是的,发生了......).今天我们使用SourceSafe进行源代码控制,但是如果我们能够提供充分的理由(SS 到目前为止它确实对我们有效),那么可能会改变.
我们尝试遵循的另一个原则是它只是由我们进一步部署的集成服务器构建和测试的代码.
我们有几个想法来解决上述问题.第一个是持续集成服务器构建和本地部署项目并测试它(它现在就这样做).您可能知道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
京公网安备 11010802040832号 | 京ICP备19059560号-6 