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

第 1 部分：企业开发和 Oracle ADF 开发冲突的挑战

作者：Chris Muir

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

• 企业开发的挑战
• Oracle ADF 开发的挑战
• 有关采用本文建议的免责声明
• 本文所做的假定

企业软件开发有着自身的挑战。企业为了应对这些挑战，引入和定制了变更控制系统以满足他们的独特需求，从而以受控方式针对开发、测试和生产系统以及专门维护和管理所有这一切的员工维护多个环境。所有这些“影子”系统和员工在后台为企业 IT 部门提供基本服务，但用户自身很少看到或意识到。

由于需要管理大量现有系统和竞争性技术，企业需要考虑的最后一件事情是诸如 Oracle JDeveloper 11g 和 Oracle ADF 之类的当代技术与维护系统变更的方式“背道而驰”。幸运的是，通过采用 SVN 作为主要文件版本控制系统 (FVCS)，Oracle JDeveloper 系统可以将极其灵活的系统集成到现有的变更控制系统中。

本文不仅介绍如何将 SVN 与 Oracle JDeveloper 结合使用以全面考虑如何使用 SVN 并使其适应企业开发过程，还概述了 SVN 在新的 Oracle JDeveloper/Oracle ADF 开发项目中的建议用法，特别强调了所发生的不同情景以在开发、测试和生产中推广系统代码。

本文旨在帮助开发团队、管理员和变更控制团队了解需要执行的已有过程、变更控制过程中的一组完整的角色和职责以及结果。本文的目的不仅是说明如何在组织中采用 SVN 和 Oracle JDeveloper，而且还要为员工提供足够的信息以管理 Oracle ADF 开发环境中所发生的更改的生命周期。

企业开发的挑战

企业开发在许多方面都与套装软件开发有着本质的不同。

通常，企业支持系统开发、测试和生产服务器环境（甚至更多），这可使企业清楚地区分系统生命周期的各个阶段。开发人员在开发环境中依照自己的意图构建新系统、扩展系统、修复现有系统以及进行粗略修补。质量控制团队在独立的测试环境中根据系统要求安装和测试开发人员的最终产品以确保系统适合使用。最后，提供其上迁移了经反复测试的系统的生产服务器，使最终用户可以使用该系统来解决手头的业务问题。

文件版本控制系统 (FVCS) 和企业的变更控制团队负责跟踪系统代码所在的位置，即代码到达哪个环境。理想情况下，全部任务是由一组明确的方案驱动的过程，这些方案指定需要采取哪些步骤将代码从开发演进到测试，最后演进到生产中。通过执行这些过程，企业员工可以了解系统状态以及开发代码、错误修复、热修复甚至是实验代码具体位于何处。

套装软件始终是少数几个核心产品的下一版本中的关注点，而企业始终需要跨大量系统、技术、过程和环境管理多个变更请求。对于具有大量复杂系统的企业而言，变更控制系统很少被看作 IT 的“吸引人”部分，但这些系统对于日常 IT 业务至关重要，因为它们控制着工作的具体方式和时间。

变更控制有时也称为变更管理或配置管理，可确保以受控和协调的方式同时实现软件系统和硬件系统的更改。此外，变更控制还能够识别将来要完成的工作内容以及过去已完成的工作内容。就其本性而言，变更控制系统非常庞大、繁琐，通常是老旧系统，除了处理微小调整之外很少进行更改，因为任何更改都意味着保持企业的业务运行的核心系统的维护和扩展将会中断。

典型的变更控制系统将跟踪具有关联 ID 的变更请求 (CR)。CR 由于以下三个原因之一而产生：

• 对现有系统进行错误修复

• 请求新系统开发

• 请求对现有系统进行扩展或增强

大多数 IT 部门在任何时候都面临处于不同解决程度的数十个（甚至数百或数千个）CR，并且这些变更请求分布于组织的所有系统。

Oracle JDeveloper 11g Application Development Framework 的挑战

Oracle JDeveloper 11g 为 Web 开发提供了一个最强大的 Java 框架：Oracle Application Development Framework (Oracle ADF)。11g 旗帜下的 Oracle ADF 引入了任务流的概念，它是用于将 Web 应用程序分为多个过程的唯一编码范例。每个任务流表示一组可以在整个应用程序中重用的屏幕，传入和传出参数并引导用户进行一组已定义的交互。由于 Oracle JDeveloper 能够在不同的主要 Oracle ADF 应用程序之间重用任务流，因此极大地增强了任务流的功能，重用的频率之高在以前 Web 开发框架中从未见过。

但是，此功能也对企业提出了挑战：应用程序过去常常被视为可以作为一个核心系统跟踪的单个实体，但任务流小型应用程序引入了更精细的系统管理粒度，并且由于进行重用，跟踪主要应用程序和小型任务流之间的版本相关性是一件令人头疼的事情。

由于企业开发和 Oracle ADF 开发存在着独特的挑战，因此本文将考虑一种使用 SVN 的方法，当 Oracle ADF 系统的生命周期及其所有任务流组件在开发、测试和生产环境中迁移时，SVN 对它们进行跟踪。

免责声明

本文要求按指定的方式使用 SVN。读者根据自己的需求评估本文时，应认识到以下几个重点：

• 一旦在组织中采用这些过程，组织就不能改变所述步骤，这一点很重要；否则，全部过程将中断。在许多情况下，每个步骤都依赖于上一步的成功执行。

• SVN 作为 FVCS 的一个主要属性是其灵活性。可以修改 SVN 以符合各种要求。一个组织采用和使用 SVN 的方式可以完全不同于另一个组织使用 SVN 的方式。阅读本文时，您需要评估本文中指定的方法是否符合自己的要求。只有您可以进行这种判断，因此必须完全了解所述内容，然后才能对本文指定内容做出任何结论。

假定

在继续之前，必须了解本文围绕以下概念做出的多个假定：

• Oracle JDeveloper 版本

• Oracle ADF 应用程序、工作区和项目

• 服务器环境

• 您所具备的 Subversion 知识

• Subversion 设置

• Subversion 信息库布局

JDeveloper 版本

本文档假定您使用的是 Oracle JDeveloper 11g R1，具体为 Studio 版本 11.1.1.2.0 build 5536。

Oracle ADF 应用程序、工作区和项目

为使本文更加有用，在尝试保持本文具有可读性（通过以逻辑方式引入简单概念）与呈现实际开发团队遇到的问题之间进行了权衡。

为使本文简明易懂，最初假定只有一个通过 Oracle JDeveloper 工作区实现的主要应用程序。Oracle ADF 应用程序（在 11g 术语中称为融合应用程序）将应用程序分为两个普通的默认项目，即 Model 和 ViewController。该应用程序不使用 Oracle ADF 库。

为了反映实际 Oracle ADF 开发，在本文的后续部分中，主要应用程序将“重用”一个单独的有界任务流 (BTF)，此任务流本身被视为应用程序并通过 Oracle ADF 库特性被加载到主要应用程序中。这为本文中所述的 SVN 过程增加了必要的额外复杂性。

服务器环境

本文假定您的企业维护三个环境：开发、测试和生产，如下所示：

• 开发 Oracle WebLogic Server 以及开发 RDBMS

• 测试 Oracle WebLogic Server 以及测试 RDBMS

• 生产 Oracle WebLogic Server 以及生产 RDBMS

这种分层设置在许多企业中都很常见。通常，企业中存在变更控制过程和工作流以支持此设置。只需扩展本文中介绍的方案以包括其他层，便可随意将此环境模型扩展为更多层。

您所具备的 Subversion 知识

本文档假定您了解 SVN 主干（或干线或主线）、分支、标记、信息库、修订、添加、更新、提交以及合并等概念。有关这些概念的更多信息，请参阅 O’Reilly 出版的《Version Control with Subversion》。

此外，本文档假定除了 SVN 作为文件版本控制系统之外，您还具有变更控制系统，此系统跟踪代码在环境之间的移动以及分配有代码的组件。

Subversion 设置

通常，开发人员共享中央服务器上的现有 Subversion 信息库。Subversion 支持通过多种不同机制访问此信息库，比如，在通往专用 SVN-HTTP 服务器的本地网络上直接连接到文件系统。Oracle JDeveloper 11g R1 支持连接到任一 1.6 SVN 服务器。对此类服务器和文件信息库的设置和配置的讨论超出了本文档的范围，但应该仔细考虑设置和配置，因为以最佳方式访问信息库对于由多个开发人员组成的团队而言至关重要。有关使用 Subversion 的更多信息，请参阅《Version Control with Subversion》一书。

Subversion 信息库布局

为了支持我们的新项目以及开发、测试和生产环境，建议使用以下 Subversion 信息库：

此处，<app> 是应用程序名称，例如，本文假设的应用程序名为 Beanz。在具有类似子目录结构的 <root> 下，多个应用程序存在于各自的目录中。对于本文档，我们将假定一个应用程序。

可以使用 Versioning Navigator 创建此结构，方法是右键单击指向信息库的 SvnConn 连接，并选择 New Remote Directory。这将打开 Create Remote Directory 对话框，可以在其中创建上面的结构：

以下是 Versioning Navigator 中的结果表示：

对于手头的应用程序，就像 SVN 信息库的标准一样，主干位置将是开发代码驻留的地方。在任何给定时刻，测试和生产分支作为单个参考点存在，其代码在测试和生产环境中运行。

通常，在测试和生产分支上不进行开发，而是在测试和生产分支上修复测试者发现的错误并进行生产系统所需的热修复。仅当由于人为错误（或类似情况）尚未执行本文档中所述的工作流时，才会从测试或生产环境中复制（获得）代码，并且必须信任签入 SVN 的代码。显然，并不建议这样做。

tags 目录最初没有子目录，但它最终将包含不同版本的子目录，这些子目录基本上包含在给定时间点用于应用程序的一组完整的文件。这可以是当前存在于测试或生产分支中的版本，也可以是历史版本以及由于版本控制和存档原因而保存的版本。

总结

在这第一部分（共五部分）中，我们了解了企业所面临的一些开发挑战（不仅仅是编写代码）。此外，为了本文需要，我们假定了一个基本 ADF 应用程序结构、用于开发、测试和生产的服务器环境，以及基本 Subversion 信息库。在下一部分中，我们将讨论变更控制过程中的团队角色，以及如何在 Subversion 中启动 ADF 开发。

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