系列文章：使 Oracle Application Development Framework 和 Subversion 适应企业需求

第 4 部分：将 Oracle ADF 应用程序迁移到生产环境并编写紧急修复代码

作者：Chris Muir

这是由五部分组成的系列文章“使 Oracle ADF 开发和 Subversion 适应企业需求”的第 4 部分。内容涵盖：

• 应用程序首次迁移到生产环境

• 接着将 CR 从开发环境移至测试环境再移至生产环境

首次迁移到生产环境

有时，Test 分支将被认为已准备好可以移至生产环境，通常是当测试已经完成，质量保证团队对软件解决方案感到满意时。

与首次迁移到测试环境类似，如果有任何开发人员在使用 Test 分支，这些开发人员将签入其所有更改然后冻结 Test 分支上的开发。很可能，最初迁移到测试环境的程序上面可能没有进行开发（因为该程序已经很完善），因此无需开发人员冻结。测试人员通过 CR 通知变更控制主管，表示 Test 分支已经可以移至生产环境：

变更控制系统现在如下所示：

接着，变更控制主管（不是开发主管，那是从开发环境移至测试环境时的情况）使用 Oracle JDeveloper 的 Versioning Navigator 窗口在 Beanz\branches\test 处创建一个到 Beanz\branches\production 的 SVN 分支。

结果在 Version Navigator 中表示如下：

（或者，根据对 Test 的任何更改应已与 CR001 同步的假设，变更控制主管也可以使用 Beanz\tags\CR001 创建 Beanz\branches\production。）

变更控制主管使用 Oracle JDeveloper 签出 Beanz\branches\production 完整代码作为工作副本，然后使用 Production 部署描述文件创建 EAR 文件。（之所以需要重新创建 EAR 文件，是因为假定 Production 分支可能在测试期间由于错误和所需修复而有所修改，如上一部分所述。）

与首次迁移到测试环境类似，变更控制主管将 EAR 文件的副本上载到 CR 以供生产 Oracle WebLogic Server 管理员随后对其进行部署和配置。变更控制系统现在如下所示：

变更控制主管还将更新更改请求 CR001 文档，指示要部署到生产环境的代码现在位于 Beanz\branches\production SVN 目录下。

完成向生产环境的迁移之后，Oracle WebLogic Server 管理员将 CR 重新分配给变更控制主管：

收到迁移已成功的通知之后，变更控制主管将相关 CR 标记为完成/在生产环境中。

接着将 CR 从开发环境移至测试环境再移至生产环境

当对应用程序提出进一步的更改请求时，这些请求通常按顺序一个接着一个，每个请求都创建为标记，然后使用上文中针对初始迁移所描述的方法完成向 Test 和 Production 分支的迁移。例如，如果应用程序已到达 CR004，可期待在 tags 树下看到以下内容：

例如，在下面的 Versioning Navigator 图中，CR003 已到达 Test，而 CR001 已到达 Production：

注意这里为何不必保留所有已到达 branches\test 或 branches\production 的 CR 的副本。这是因为 tags 结构已为我们保留了完整记录。这确实引出了一个问题“既然 CR 已经包含在 tags 目录中，为什么还要费力在 branches\test 或 branches\production 中保留 CR 的副本？”总体来说，是为了清楚地标明哪个版本已达到哪个环境，是测试环境还是生产环境。

CR 迁移到 branches\test 或 branches\production 后，只需使用右键单击选项即可删除先前的 CR：

生产环境中发现了错误：紧急修复

当系统运行于生产环境中时，有可能发现需要紧急修复（即热修复）的错误。预计将提出包括热修复的解决方案的更改请求，比如说 CR068。

与“导致合并回开发环境的测试和更改”部分中所描述的内容类似，可以预期被分配修复错误的开发人员将签出 Production 分支代码的工作副本。理想情况下，开发人员应识别问题和出问题的代码并更改源代码以创建修复程序。在此阶段，必须决定在哪里应用补丁以及如何应用。

将热修复直接应用到 Production 分支并不适合，因为需要先进行测试。所有补丁必须至少经过一个测试周期。

或者（但这并非理想情况），可以将修复程序应用于经历了开发-测试-生产周期的即将推出的版本中捕获的最新 Development 分支。修复程序不是十分重要且用户可以等待的情况下，可以这样做。但如果修复程序是紧急修复，这样做就不合适了，因为可能有许多在 trunk 上继续的其他 CR 需要首先进行测试。

这种情况的解决办法是由开发人员将工作副本作为标记 CR068 添加到信息库中。然后变更控制主管创建一个 EAR 文件并将其提供给测试 Oracle WebLogic Server 管理员进行部署和配置。在此之后，该版本（标记 CR068）将经过测试并随后与“首次迁移到生产环境”方案完全相同的进行处理。

对于紧急测试，在本示例中，可能最好是针对单独的测试 Oracle WebLogic Server 实例应用 EAR 文件，因为覆盖当前测试 Oracle WebLogic Server 实例应用程序可能会破坏当前测试和整个工作流。

最后，开发人员还必须将 CR068 更改合并回开发 trunk，并且可能还必须合并回现有 Test 分支及相关的 CR 标记；否则，修复程序将在稍后将 CR 迁移到生产环境时丢失，可能再次出现同样的紧急情况。

总结

在这个由五部分组成的系列文章的第 4 部分中，我们研究了最终变更控制方案：将代码从测试迁移到生产，并进一步考虑了跨越整个开发、测试和生产工作流的 CR。在下一部分中，我们将开始考虑 Subversion 方案，并另外考虑 ADF 应用程序架构的有关领域，包括 ADF 库，以及这些库如何适应整个变更控制过程。

转到第 5 部分 | 返回系列目录