3

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

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

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

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

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

希望问题很清楚

4

3 回答 3

3

总的来说，这整个过程与既定的最佳实践背道而驰。如果您有充分的理由，这不一定是一件坏事，但我在这里看不到它们。

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

解决此问题的标准方法是使用单个 SVN 代码树 - 在发布给 QA 时标记一个版本（使用已经构建的二进制文件！），可能在发布给 PROD 时再次标记它。不要重新构建二进制文件，使用你实际测试过的那些！

于 2012-09-04T08:31:53.793 回答
1

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

我建议这样做的原因如下：

  • Msbuild 将更新任何受更改影响的程序集的修改日期 - 即接口更改？
  • 该程序集是您要部署的，因此请检查此而不是修改源。否则你需要知道构建过程（不会改变） - 即源文件位置、引用等。

您的部署将只包含来自修改日期 >= BuildDate 的构建目录中的 dll。

于 2012-09-04T05:51:41.240 回答
0

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

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

  1. 我们的 CI 服务器会自动标记每个成功的构建
  2. 当特定版本需要补丁时，程序员会复制并签出标记的版本并对其进行修复
  3. 然后我们在 CI 服务器上有一个特定的“补丁”构建，它与带有“补丁”标志的普通构建完全相同，并指向已修补的源

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

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

无论如何，如果您想通过 CI 在两个存储库之间自动执行修补过程，那么您必须创建特定的 MSBuild 任务来执行此操作。您可以尝试合并它们之间的更改或检查 SVN diff & patch命令。

于 2012-09-04T09:29:59.493 回答