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

第 3 部分：将 Oracle ADF 应用程序迁移到测试环境并进行修复

作者：Chris Muir

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

• 应用程序向测试环境的第一次迁移

• 导致合并回开发环境的测试和更改

首次迁移到测试环境

有时，Beanz\trunk 中的开发代码库被认为已经准备好可以移至测试环境。通常，发生这种情况是因为开发人员认为他们已经满足更改请求的要求，或者是因为已有足够的功能可以让测试人员开始测试子系统。

假定此时所有开发人员均已停止编码，并且所有更改已提交至 Beanz\trunk（即 HEAD 修订版）。在此阶段，有一点非常重要，即开发人员应了解所有要求必须都已得到满足，并且不能再向代码中塞入任何新的更改。因此，可能需要在心理层面上对团队的开发实施开发“冻结”。

开发主管基于 Beanz\trunk 开发树直接针对信息库创建“更改请求”标记（如 CR001），不会影响任何开发人员的工作副本。该标记将在 Oracle JDeveloper 内应用于应用程序级。为此，主要开发人员右键单击 Versioning Navigator 下的 trunk 分支，并选择 Branch/Tag 选项。这将打开 Branch/Tag 对话框：

在此，可以看到从何处复制代码（根据最新的 HEAD 修订版）。接着，在 To 域中，可以定义将完整代码库复制到最新创建的信息库目录 tags/CR001 中。结果显示在 Versioning Navigator 中：

至此，我们已经通过标记机制得到完整的快照，为准备用于测试的代码提供了永久记录。现以可以通过创建分支来将应用程序迁移到测试环境。作为策略，请始终使用标记作为分支创建的来源。开发主管使用与 Versioning Navigator 中相同的 Branch/Tag 选项，通过 Oracle JDeveloper 的 Versioning Navigator 窗口在 Beanz\tags\CR001 处创建一个到 Beanz\branches\test 的 SVN 分支。

以下是 Versioning Navigator 中的结果视图：

然后，开发主管更新更改请求文档，说明要部署到测试环境的代码已标记为 CR001，该代码位于 Beanz\branches\test SVN 目录下，且已将 CR 重新分配给变更控制团队。

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

变更控制主管将通过 Oracle JDeveloper 签出完整的 Beanz\branches\test 代码作为工作副本，并使用测试部署描述文件创建 EAR 文件。

EAR 文件将作为要部署到测试 Oracle WebLogic Server 的文件的副本附加到更改请求，EAR 文件的一个副本将发送给测试 Oracle WebLogic Server 管理员。然后会将该 CR 分配给测试 Oracle WebLogic Server 管理员。变更控制系统现在如下所示：

测试 Oracle WebLogic Server 管理员将 EAR 文件部署到测试 Oracle WebLogic Server 并相应配置服务器和应用程序（超出本文范围，将另行讨论）。

接着，测试 Oracle WebLogic Server 管理员将工作标记为完成，将 CR 重新分配给变更控制主管。然后变更控制主管将 CR 重新分配给测试人员，指示可以开始测试。变更控制系统现在如下所示：

导致合并回开发环境的测试和更改

此时，开发人员很可能继续在 Beanz\trunk 上开发，同时测试人员测试部署到测试 Oracle WebLogic Server 的应用程序。

有时会在测试应用程序时发现错误，或者测试人员要求进行更改。此时，需要将 CR 重新分配给开发人员以进行相应的更改。变更控制系统现在如下所示：

为了重现在测试环境中看到的问题，开发人员可以签出 CR001 标记代码的工作副本，或签出 branches\test 代码的工作副本。在本示例中，采用这两种操作中的任何一种结果都是一样的，因为如果遵循了上述过程，CR001 标记和 branches\test 代码将是同一代码库。对于以下讨论，我们假设开发人员从 Test 分支签出工作副本。

理想情况下，开发人员应识别问题和出问题的代码，更改源代码以创建修复程序或更改，并将更改重新提交到 Test 分支，然后测试人员可以使用新应用的修复程序继续测试。

提交更改之后，开发人员将通知变更控制主管需要从 Test 分支构建另一个 EAR 文件，并将此文件提供给测试 Oracle WebLogic Server 管理员进行部署和配置（如上一部分所述）。当开发人员将控制回传给变更控制主管时，您的变更控制系统最初如下所示。

然后变更控制主管将签出 CR001，创建另一 EAR 文件，将其上传至 CR，并将 CR 重新分配给测试 Oracle WebLogic Server 管理员使其部署到测试 Oracle WebLogic Server。变更控制系统现在如下所示：

接着，测试 Oracle WebLogic Server 管理员将工作标记为完成，将控制重新分配给变更控制主管。然后变更控制主管将 CR 重新分配给测试人员以进行测试。变更控制系统现在如下所示：

值得注意的是，尽管更改发生在 Test 分支，但更改还可能随其他开发的继续而在 trunk 中继续发生。

 

[单击此处可查看大图]

在这个阶段，需要将对 Test 分支创建的修复重新应用到 trunk 和 CR001 标记。需要将修复应用到 trunk，以便将来的所有开发都包括这些修复。此外，因为 CR001 标记代表这个特定版本，因此它也需要这些修复的副本。稍后，随着其他标记被迁移到 Test 分支，只需对应用于 Test 分支的当前标记应用对 Test 分支的任何修复，不必对 CR001 等早期标记应用。

对 trunk 和 CR001 标记应用 Test 分支的操作即为分支合并。分支合并是通过签出较少分支（即缺少所需更改的 trunk 或 CR001 标记）的工作副本，然后并入较大的分支来实现的。

在以下示例中，trunk 的工作副本与 Test 分支的内容合并。包含 trunk 工作副本的开发人员的 Application Navigator 如下所示：

在此假设开发人员已从信息库获取 trunk 的最新工作副本。如果没有，则开发人员必须使用 Applications 菜单的下拉选择列表 → Versioning → Update Working Copy 选项更新工作副本：

更新工作副本将生成以下 SVN 日志项：

有了 trunk 工作副本，然后尝试使用 Applications 菜单的 → Versioning → Merge Working Copy 下拉选择列表选项进行分支合并。这将调用 Subversion Merge Wizard，在该向导中，选择重新集成分支和当前 trunk 工作副本：

步骤 2 定义将从哪个分支合并以及将要合并到的工作副本：

步骤 3 允许在合并完成前对合并进行测试。在本示例中，我们看到的是发生了无法解决的合并（即存在冲突，Subversion 无法为我们自动进行合并）：

Merge Wizard 完成后，在日志窗口中将看到同样的输出：

Application Navigator 使用冲突图标标记 SearchBeanz.jspx 文件中存在冲突：

同样，在 Pending Changes 窗口中也标记了该冲突：

右键单击此文件并选择 Resolve Conflicts，将显示 Oracle JDeveloper 的三窗格合并工具：

在此，开发人员必须手动解决此冲突。这个特定代码示例只是用于本文目的的简单示例。

解决合并之后，日志窗口将显示解决过程：

Pending Changes 窗口将更新后的文件标记为已合并更改，现在可以提交到信息库了：

提交工作副本之后，可以在 Application Navigator 中看到冲突解决后生成的新修订版本：

在 Subversion 信息库中也反映了相同的修订版本：

Version Tree 工具（通过右键单击现有文件，然后选择 Versioning，再选择 Version Tree 打开）可帮助我们了解刚才完成的操作。从进行修复的 test 分支修订版 12 我们可以看到，该版本已经重新合并到主 trunk 分支生成了修订版 13。

最后，必须对 tags\CR001 重复同一过程，签出 CR001 标记的工作副本，然后将其与 test 分支合并。

总结

在本部分中，我们研究了第一次将应用程序迁移到测试环境以及对应用程序程序进行测试并将所有修复程序重新迁移到 Subversion 开发主干的变更控制方案。在下一部分，我们将研究应用程序生产环境的第一次迁移，然后考虑贯穿整个开发、测试和生产环境的其他 CR。

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