自动补丁构建和.NET应用程序的部署

Question

问题的简短形式然后解释 我们想要创建补丁，并且只包含由于dotnet应用程序的一些错误修正而在构建中发生更改的文件。这些补丁应该在涉及SVN，Cruisecontrol.net和msbuild的持续集成过程中自动构建。

我们有一个场景： 我们希望维护一个使用持续集成在远程服务器上运行的.net应用程序。源代码位于SVN中，具有3个不同的DEV，QA和PROD存储库。 我们的开发人员几乎每天都会进行新的bug修复，并在初始测试和满意后将更改合并到dev存储库中。 解决某个问题或添加了某个功能后的代码然后合并到QA存储库中。 QA代码是在QA机器上手动构建和测试的。 在QA测试之后，我们将其合并到PROD中。有了它，QA还为必须手动更换或更改的文件创建新的补丁。然后，将修补程序部署在临时服务器上。在测试之前直到完美，然后将补丁部署在实际的远程服务器上。

为了寻求持续集成，我们现在尝试使用CruiseControl.net和msbuild的混合来完成这个过程。 这个过程很好，直到我们必须自动生成QA版本的补丁。在生成补丁之后，我们将它们放在ftp服务器上，然后从它们将它们下载到要测试的登台服务器。 问题，即从新版本生成补丁有几个方面。应用程序的解决方案文件包含许多项目，并使用postbuild事件将dll复制到启动应用程序bin文件夹。所以我们在实际应用程序中有一个特定的目录结构，它本身就是6种解决方案的组合，它们或多或少地相互独立。

我们尝试创建补丁的方式是搜索svn的日志以查找哪些文件已更改。然后我们解析它找到项目名称。然后我们通过使用包含应用程序的所有文件的映射文件，将该项目的bin目录中的所有文件以特定的方式复制到补丁文件夹中。

如果我们有svn和cruisecontrol.net，那么任何人都可以建议一个更好或更简单的方法来制作补丁。或者任何其他开源工具。

希望问题清楚

Answer 1

总的来说，整个过程违背了既定的最佳实践。如果你有充分的理由，这不一定是坏事，但我不会在这里看到它们。

实质上，您没有使用QA和DEV环境来确保生产的稳定性。更糟糕的是，您使用不同的源树为它们构建代码。这为部署过程中引入了可能失败的新点。

接近这个的标准方法是使用单个SVN代码树 - 在将版本发布到QA时标记版本（使用已经构建的二进制文件！），可能在发布到PROD时再次标记它。不要重新构建二进制文件，使用您实际测试的二进制文件！

Answer 2

如果您的Msbuild任务正在执行构建而不是重建，那么未受影响的dll的日期/时间将不会更改其修改日期。

我建议这样做有以下原因：

• Msbuild将更新受更改影响的任何程序集的修改日期 - 即。界面改变了吗？
• 程序集是您要部署的部分，因此请检查此部分而不是源代码进行修改。否则你需要知道构建过程（不会改变） - 即。 Souce文件位置，参考文献等。

您的部署只包含修改日期＆gt; = BuildDate的构建目录中的dll。

Answer 3

我同意skolima关于推荐的构建＆amp;补丁过程。您应该从初始标签和修改创建补丁，然后创建一个必须在所有环境中部署的新版本。

在我的公司，我们正在使用这种方法：

1. 每个成功构建都由我们的CI服务器自动标记
2. 当特定版本需要补丁时，程序员会复制 ＆安培;签出标记版本并对其应用修复
3. 然后我们在CI服务器上有一个特定的“补丁”版本 与带有“Patch”标志的正常构建完全相同，并指向已修补的源

部署目标相同，构建过程相同，只有源更改。

优点是补丁在CI上有自己的构建历史记录，因为它们是单独构建的，但被视为普通构建。

无论如何，如果您想通过CI自动化两个存储库之间的修补过程，ihmo必须创建特定的MSBuild任务才能执行此操作。您可以尝试 合并 它们之间的更改，也可以查看SVN diff ＆amp; 补丁 命令。