最佳的构建过程解决方案来管理构建版本
我用几个独立的应用程序运行一个相当复杂的项目。但是，它们使用了两个共享组件。所以我有一个看起来像下面的源代码树。
- 共享的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. 一旦构建了构建35，我该如何重新创建构建34并将DLL版本号设置为1.0.0.34？
"修订号"解决方案
有人告诉我，例如Subversion会在每次签入时为整个源代码树创建一个修订版号？ SourceSafe有类似的东西吗？如果正确的话，那就是在获取最新版本时获取该修订号，并在CruiseControl服务器上进行构建。然后可以使用修订号来设置DLL版本号(例如，设置为1.0.0.5678)。我想如果需要的话，我们可以为Subversion获取此特定的修订版，然后该版本将包括该应用程序和所有共享项，以便能够从过去重新创建特定的版本。这项工作是否可行，也可以使用SourceSafe来实现吗？
总结
因此，两个主要要求是：
- 能够跟踪内部版本号和已部署DLL的内部版本号/修订号。
- 能够重建以前的修订版本/构建版本，在该构建版本的可执行文件上设置旧的构建版本/修订版本号(以符合要求1)。
那么我们将如何解决呢？我们首选的方法是什么？如何解决(或者我们有完全不同的想法？)？ **请提供详细答案。 **
额外的问题修订号和内部版本号有什么区别？何时真正需要两者？
解决方案
回答
方案在VSS中是合理且可实现的(尽管我建议我们考虑使用替代方案，但VSS确实是过时的产品)。
对于" CI"构建，我们需要进行版本控制，以查看具有"版本"任务的MSBuild社区任务项目。通常，我们在源代码树中将有一个" Version.txt"，并且在开发人员控制Major.Minor.Release.Revision数字时，MSBuild任务将增加" Release"数字(这是我的客户想要的)。如果愿意，可以使用修订。
然后，我们将具有" FileUpdate"任务来编辑具有该版本的AssemblyInfo.cs文件，并且EXE和" DLL"将具有所需的版本。
最后，VSSLabel任务将适当地标记所有文件。
对于" Rebuild"构建，我们将修改" Get"以从该Label获取文件，显然不执行" Version"任务(因为我们正在选择要构建的版本)，然后FileUpdate任务将使用该版本号。
奖励问题：
这些都是"我们要如何使用它们"，我将使用内部版本号，以及内部版本号，这就是我要增加的内容。如果我们使用的是CI，那么我们将拥有大量的构建，而绝无意在任何地方进行部署。
主要和次要是不言而喻的，但是我一直将修订版本用作"修补程序"指示器。我打算发布一个" 1.3"版本，实际上是一个带有1.3.1234.0版本的产品。在1.4上工作时，我发现一个错误，需要1.3.2400.1的修补程序。然后当1.4准备好时，会说1.4.3500.0
回答
我需要比回应更多的空间，因为评论直接允许...
Thanks! Good answer! What would be the difference, what would be better solving this using SubVersion for example?Richard Hallgren (15 hours ago)
VSS的问题与该示例无关(尽管我认为"标签"功能的实施效率不高...)
这是VSS的一些问题
1)基本上不可能分支
2)通常不使用共享结帐(我知道有一些成功的人)
3)表现很差劲，简直是"聊天"
4)除非我们有一个很小的存储库，否则它是完全不可靠的，对于大多数商店来说，这是一个定时的炸弹。
对于4，问题在于VSS是通过将整个存储库在文件系统中表示为"平面文件"来实现的。当存储库超过一定大小(我相信是4GB，但我对该数字不确定)时，我们就有机会"腐败"。随着规模的增加，腐败的可能性会越来越大，直到它几乎可以确定为止。
因此，请查看存储库大小，如果我们要使用千兆字节，我强烈建议我们开始计划更换VSS。
不管Google的" VSS Sucks"如何获得3万次点击...我认为，如果我们确实开始使用替代品，我们将意识到这是非常值得的。
回答
- 拥有CC.net标签成功构建
- 使解决方案中的每个项目链接到一个公共的solutioninfo.cs文件，该文件包含程序集和文件版本属性(从每个项目中删除assemblyinfo.cs)
- 在构建具有巡航控制功能之前，运行ccbuild regex替换(来自msbuild社区任务)以使用cc.net生成标签更新版本信息(作为参数传递给msbuild任务)
- 建立解决方案，运行测试，FX cop等
- (可选)还原解决方案信息文件
结果是cc.net发布的内部版本中的所有程序集都具有与源代码存储库中的标签一致的相同版本号。
回答
UppercuT可以通过自定义打包任务来完成所有这些工作，以拆分应用程序。要获取源代码的版本号，我们可以考虑使用Subversion。
它也非常容易上手。
http://code.google.com/p/uppercut/
这里有一些很好的解释：UppercuT
