争分夺秒地发布：自动化应用程序推进

　　BEA WebLogic Platform应用程序通常作为复杂生产系统的一部分进行部署。当交付以WebLogic Platform为基础的应用程序时，对应用程序进行正式测试需要恰当控制的测试条件，而提供这些条件本身就是一项复杂的任务。如果没有准备好恰当的环境并成功地进行应用程序部署，就无法执行正式测试，从而影响交付，而交付时间安排上一点点的松懈都将导致整个项目的推迟。

　　构建测试环境流程的自动化将有助于防止这种延误的发生。在本文中，我将展示对一个测试环境进行自动部署的工作如何重用于其他测试环境。

　　“发布我吧”

　　“发布我吧，让我去，

　　我的 bug已经不再是最重要的了……”

　　这些话不是我写的，而是在Web上看到的，但它特别切合我们的主题。您可以在Web上查看完整版本，更多内容请参见 Filks站点。

　　那么，您的开发团队已经构建了应用程序套件，成功将它部署在WebLogic域中，并通过自动测试脚本对应用程序进行了彻底的测试。开发人员可能已经阅读并实现了Michael Meiner在 使用WLST和BEA Workshop在集群环境中开发Web应用程序（Dev2Dev，2006） 一文中的建议，在集群中测试了套件（使用Web服务作为集群的前端），见到它在集群中运行，并证明了故障转移能正常工作。

　　团队准备好了发行说明和所有的归档文件。那么现在已经万事具备，只等用户验收测试了，祈祷用户会喜欢它吧，您就可以为这次成功交付举杯庆祝了。

　　醒醒吧！现实是生产套件的万里长征才刚刚迈出了第一步。成功的交付需要跨越无数的障碍，需要开发人员的多次尝试。于是测试开始了，将使用各种测试器或测试工具，将涉及套件和开发人员无权访问的机器，这些测试将找到错误，至少有几个错误是需要修复的，整个过程需要重复进行多次。

　　获得推进

　　测试通常在一组明确指定的环境中进行。现在讨论这些受控环境包括哪些，以及将一个应用程序从一个测试环境推进到下一个测试环境需要哪些条件。

　　受控环境

　　我使用术语“受控环境”表示访问受到某个策略限制的环境。生产环境是一个受控环境，分段测试环境也是一个受控环境。这两个环境的访问控制测试类似，但分段测试环境的限制性访问策略的可能更少一些。简单地说，“受控测试环境”是一个用来测试应用程序（套件）的、受控制的（即访问受策略限制）环境。

　　在受控环境下进行测试的目的是获得可重复的测试结果：在相同的环境下对相同的软件进行测试，应该获得相同的结果。“相同的条件”要求准备的测试环境是一致的并且是可重复的。自动环境构建应该确保环境最初位于可重复的环境中，但还需要更多的条件以确保测试发生在可重复环境下。应该进行访问控制，以限制环境构建后能够更改该环境的人以及所允许的更改。如果在测试前应用了运行时更改，那么应该在测试日志中记录这些更改（这一点很重要），这样才能重新创建完全一样的测试环境，即重复构建时也要重新应用运行时更改。

　　可以正式或非正式（或者两者结合）的形式应用访问控制。如果您的项目使用正式访问控制，则通常通过可以保护策略规则的软件或硬件设备实现。如果您的项目不需要太过正式，那么可能会非正式的（即根据公认的实践经验）应用部分或全部访问控制。很明显，非正式控制很容易遭到破坏，有时甚至无意中就破坏了，这种环境需要安装审计软件，用于根据期望的设置检查环境配置，并在出现不可接受的变化时发出警告。

　　受控测试环境的例子有：性能测试环境、压力测试环境、用户验收测试环境等。在受控测试环境中，开发人员通常可以查看测试结果、调查问题或错误，但是不允许管理或修改环境配置或者参与测试执行过程。

　　受控环境涉及的问题不仅仅是硬件：它是相应的硬件、基础架构和软件的结合。例如，性能测试环境和压力测试环境可以使用同一个硬件，但软件配置可能不同，性能测试可能使用JVM启用诊断工具，以分析性能瓶颈，而压力测试则不需要JVM。

　　促进推进

　　在管理得比较好的项目中，您将通过大量受控环境迁移应用程序套件，需要逐个测试应用程序。图1提供了一个示例。

　　

　　

　　图1：通过多个可控测试环境迁移应用程序

　　在项目测试计划中应该确定各种测试环境及其使用方式。通过各种测试环境迁移套件并最终实现实际生产的过程称为应用程序推进。

　　作为项目测试计划的一部分，您的项目要定义入口标准（entry criteria），并且在应用程序套件从一个环境推进到另一个环境时必须实现该标准。在受控环境中部署和测试需要大量成本（将在下文中讨论），如果应用程序的质量不合格以至于进行测试没有任何意义，可以应用入口标准避免这些不必要的成本开销。

　　在使用迭代或敏捷开发环境的项目中，可能会在一个或多个受控环境中提交好几个版本的应用程序进行测试。对于后续测试的每一个版本，测试的成功标准通常将逐渐严格或逐渐宽松。如果不采用恰当的方法，准备测试环境和部署套件的成本将成倍增长，有时候甚至导致这些方法的价值受到质疑。幸运的是，我们有一些工具和技术可以有效并可靠地进行推进，本文中我们将回顾其中一些。

　　重新部署和重复测试

　　我们可以将与部署相关的推进任务划分为两个主要阶段：

　　环境供应

　　部署应用程序套件

　　术语供应（provisioning）可以宽泛地定义为“提供应用程序所需的资源，以便它能根据规范执行任务”。资源可以是BEA WebLogic Server容器本身的任何内容，从数据库连接到Web services和后端系统连通性。在Andy Lin一篇关于自动化的文章中详细讨论了供应问题：自动化WebLogic Platform应用程序供应：案例分析(Dev2Dev，2005)。

　　为了彻底测试您的应用程序，您应该在每一个测试环境中多次部署和测试每一个应用程序。您可以从以下两种方法中选择：

　　对于每一个测试，同时执行环境供应和应用程序部署

　　只供应环境一次，然后对每次后续测试部署、测试并重新部署应用程序

　　第一种方法为每个测试重新构建环境，开销很大，但它的优点是无需为供应和部署设置不同的脚本，就好像它们是一个任务的两个部分一样。另一方面，如果您的测试计划需要复杂的测试环境，涉及到许多服务器和/或多个域，那么每次测试运行的供应开销可能过高以至于难以接受，这时可以采用后一种方法。

　　推进测试不要失败

　　推进应用程序套件不仅仅是构建一个现有环境的更大版本并在其中部署套件。各种受控测试环境将有特定的测试目标，这些目标通过不同的供应需求表现。

　　表1说明了这一点，它使用一个虚构但并非不切实际的大纲测试环境规范测试一个应用程序套件，只是在环境上有一些增加内容。

　　

　　功能测试 库和驱动程序的“调试”版

　　安装的诊断组件，例如，单元测试框架[Cactus]

　　数据库是低配置的，例如，不带RAC的Oracle，并且没有为DBMS优化架构（schema）

　　平台和应用程序共享数据库表空间并使用“一般”架构

　　集群中最小的服务器成员

　　许多伪后端服务

　　系统测试 驱动程序和库的生产版本

　　数据库是完整的企业配置，例如，带RAC的Oracle，但没有为DBMS完全优化架构

　　WebLogic Platform表格和应用程序表格各自的表空间

　　安装的少量服务器

　　后端服务可能测试实现

　　性能测试 驱动程序和库的生产版本

　　装备了JVM

　　设置在JVM上的调整的参数值，其他配置项，如连接池大小和自定义执行队列

　　安装的性能数据收集代理

　　数据库是完整的企业配置，例如，带RAC的Oracle

　　WebLogic Platform表格和应用程序表格各自的表空间，为DBMS优化架构

　　大量服务器，足够处理最大的指定负载

　　配置的负载生成器服务器

　　后端服务可能测试实现

　　用户验收测试 驱动程序和库的生产版本

　　数据库是企业版但不一定是完整配置，例如，不带RAC的Oracle

　　WebLogic Platform表格和应用程序表格各自的表空间

　　安装的少量服务器

　　完整配置的后端服务

　　表1：说明测试环境规范

　　这些不同可能会给供应增加大量负担。通常，供应错误是通过部署错误表现的，因此在构建好环境并第一次部署应用程序套件之前您无法看到这些错误。

　　第一次使用受控环境时，解决部署问题通常很棘手。开发人员和供应团队都没有复杂环境中分析部署异常的经验。开发人员总是认为能在其自己的测试机器或集成环境中部署成功意味着同样能在其他环境中部署成功。从另一方面看，测试人员和操作人员总是认为开发人员在软件交付过程中已经解决了部署问题，因此经常失败，而这时开发人员解释说他们从来没有在如此复杂的受控环境中运行应用程序。

　　至少应该知道千万不要低估推进应用程序的难度，否则您会后悔莫及。

　　老实说，我并没有改动什么！

　　我们已经定义了受控环境，现在开始讨论建立一个这样的环境需要哪些条件。自动供应是其中一项技术。

　　自动供应

　　如果您总是使用配置向导构建环境，您可能会认为这个过程不能自动完成，因为用向导构建时需要如此多的人工参与。如果可能的话，您需要学习WebLogic Scripting Tool (WLST)，它可以使用一个脚本语言控制配置向导的所有功能。WLST可以导入向导使用的模版，并通过脚本执行向导图形接口提供的自定义。在下文我们将更详细地讨论WLST中的脚本问题。现在您只需要知道或者相信可以通过脚本构建环境。

　　表1指出了测试环境间可能存在的不同之处。但是，尽管您的项目中可能存在部分或所有这些不同，供应的核心仍然是从一个环境转变为另一个环境。毕竟，在每个环境中，相同的应用程序套件被部署在相同的平台上。通过确定环境需求的不同，您可以找出使用脚本自动进行成功部署的共同特征。因此，一个环境的供应形成所有其他测试应用程序套件所需环境的基础。编写供应自动脚本时，您应该预见所有后续测试环境的供应需求。要做到这一点，您必须清楚当前测试环境和未来测试环境可能存在的不同。您应该根据项目测试计划，做一个类似表1的草表。

　　使用脚本控制自动环境构建有助于促进统一性。它还允许供应处于配置变更管理之下。这是一个很重要的优点，对环境配置进行的未经严格测试的更改对应用程序有不利影响，甚至可能导致应用程序崩溃。通过在变更控制下进行的脚本维护，脚本可以还原到之前的版本，对脚本的更改在生效前必须经过验证过程。配置管理系统也提供了一些方法来记录更改的原因，这样能够提供如何到达当前设置的历史路线图；通常，它们能够提醒某些功能无法正常工作，因为以前尝试该功能时失败了。

　　脚本供应中一个经常被忽视的优点是，脚本可以捕获供应和部署的模式。通常，使用跨多个机器的多个服务器供应多个环境的复杂性要求更多的时间来完成，它所面临的挑战超出想象。如果在编写供应脚本时比较细致，例如，插入注释解释不够明显的细节，那么在将来的项目中，可以参考这些脚本列举该项目中遇到的供应挑战，并且可以在以后类似的项目中作为模型。在Orbism，我们有一个用户供应和部署任务的参考解决方案库，并根据我们咨询人员的现场经验不断更新，这为这些领域的共同挑战提供一个可访问的模型解决方案集合。

　　自动部署

　　有人会怀疑说，部署操作如此繁琐，几乎不可能自动化。但是，除非您的应用程序本身很繁琐，不然的话只要您在开发脚本中投入了多少精力，您就能获得多少回报。

　　脚本部署帮助确保后续测试中测试条件的统一性。如果使用手工部署，很难验证是否按相同的顺序采取了相同的步骤。如果流程是自动的，那么采取的步骤都会反映在脚本内容中。此外，与供应脚本一样，部署脚本本身可以使用配置管理和变更管理进行控制。

　　数据不仅仅是将一组新的部署文件提交到部署工具那么简单。在部署文件中，有一个设置明确定义了应用程序组件所需的资源需求。它们的校正值与环境有关，在能够被正确部署之前需要对部署文件进行修改。当向WebLogic Platform 9.x环境部署应用程序时，应用这些值的方法建议采用部署计划。此页面中的WebLogic Platform 9.2在线文档讨论了向不同目标环境部署相同应用程序时如何使用部署计划。对于WebLogic Platform 8.1，部署自定义要复杂的多，涉及到解包归档文件，解析并编辑里面的内容，然后重新打包归档文件。复杂性是实行自动化的一个好理由。PO Sample中可以找到说明解析和修改部署描述符的示例代码和脚本。

　　经常向WebLogic域部署和重部署可能会生成不可预料的异常。BEA Support Patterns站点有一部分关于 troubleshooting deployment failure的内容，讨论了许多部署和重部署应用程序时发生的常见异常。大多数情况下，建议在部署和重部署前进行额外的补救步骤，这些步骤必须被包含在应用程序部署脚本中。

　　访问控制的影响

　　受控环境的一个关键特征是，对环境的访问受到策略的控制。一般来说，一个环境越接近生产，它的策略就越严格。为了说明这一点，表2展示了表1的环境，但列出了一些可能存在的访问限制：

　　

　　功能测试 开发人员运行供应脚本。

　　开发人员拆除环境。

　　操作人员和开发人员都可以执行运行时管理和监控工具。

　　开发人员修改供应和部署脚本。

　　开发人员运行部署脚本部署新的应用程序版本。

　　开发人员开始和/或中止测试。

　　系统测试 部署团队运行供应脚本。

　　部署团队拆除环境。

　　操作人员可以执行运行时管理工具。

　　操作人员和开发人员可以执行运行时监控工具。

　　部署团队可以修改供应和部署脚本。

　　部署团队运行脚本部署新的应用程序版本。

　　测试团队开始和/或终止测试。

　　性能测试 部署团队运行供应脚本。

　　部署团队拆除环境。

　　操作人员可以执行运行时管理工具。

　　操作人员和开发人员可以执行运行时监控工具。

　　部署团队可以修改供应和部署脚本。

　　部署团队运行脚本部署新的应用程序版本。

　　测试团队开始和/或终止测试。

　　用户验收测试 部署团队运行供应脚本。

　　部署团队拆除环境。

　　操作人员可以执行运行时管理工具和监控工具。

　　部署团队修改供应和部署脚本。

　　部署团队运行脚本部署新的应用程序版本。

　　用户代表开始测试。

　　表2：说明测试环境策略

　　当然，该表的内容非常简单。一个成功的项目能使各个团队在多个方面通力合作。例如，在性能测试环境中可以使用管理工具调试系统。尽管该职责分配给了操作人员，但在实际操作中，该工作应该与系统架构师、应用程序设计师以及平台专家一起完成。尽管使用合作方法可以讨论更改并对其达成一致，但实际操作中任何特定任务都必须根据策略执行。

　　自动推进脚本

　　我们已经讨论了使用脚本代替向导供应环境，以及脚本如何实现自动化。现在开始讨论BEA WebLogic Platform自动供应的参与者。同时我将提供一些脚本示例供那些以前没有研究过脚本环境构建的人员参考。

　　用于BEA WebLogic Platform的脚本语言和工具

　　正如本文所述，自动化使用脚本工具配置环境。另一种方法是使用虚拟供应，但这种方法不常用。虚拟可以作为脚本的替代方法，能够提供高速供应，将来的文章中我们将讨论这个主题。

　　供应的鸟瞰图不仅要包括WebLogic域配置，而且要包括许多其他系统组件的配置，例如：

　　网络基础架构

　　防火墙

　　操作系统补丁

　　硬件负载平衡器

　　内容切换

　　数据库管理

　　内容管理系统

　　安全服务集成

　　后端系统连通性

　　我们没有足够的篇幅讨论所有以上组件的端对端安装和配置，因此我故意限制了WebLogic Platform的翻译，将一小部分扩展转入Web服务器和数据库服务器。这些扩展用于说明如何使用类似的技术以及共享相同的供应数据（可用时）来供应其他相关的系统组件。相关组件之间的共享供应数据可以减少许多可能出现的供应错误。

　　许多脚本工具都可用于自动化，本文不打算比较这些工具。既然我们一直在讨论WebLogic Platform的供应，我假定使用WLST作为主要的脚本工具。WLST是一个命令行工具，使用Jython脚本语言，Jython本身是Python脚本语言的Java绑定。

　　在WebLogic Platform 8.1中，WLST有两个版本。离线版（就叫WLST）用于构建WebLogic域内容，而另一个在线版（称为WLSTOnline）用于监控和更改运行域的配置。在WebLogic Platform 9中，单个WLST工具（叫做WLST）能够以离线和在线模式运行。为了更清楚的说明，我们将讨论用这两者模式使用WLS。如果您使用的是WebLogic Platform 8.1，则意味着您要使用WLST（离线模式）和WLSTOnline （在线模式）。

　　在离线模式中，WLST提供与域配置向导等效的脚本。与向导一样，它基于域模版构建一个域，然后使用脚本自定义域。BEA提供许多WLST可以使用的通用模版。WLST可以使用自定义模版构建新域，这些新域类似构建模版的域。在离线模式下，WLST构建并向文件库写入一个域目录结构。供应受控环境时，由于防火墙和其他访问控制的原因，可能无法直接向域服务器所在的机器写入域目录。下文中我们将讨论如何调整访问控制。

　　在线模式的WLST类似于WebLogic域控制台Web应用程序的等效脚本形式。除了可以监控其运行状态外，它还能检查和修改活动域的配置。运行在线模式时，WLST不依赖模版，因为它总是对现有的活动域进行操作。在线WLST使用JMX与管理服务器（以及受管服务器，但通常不能是在供应期间）进行通信。这与离线模式有明显的区别，WLST在离线模式只编写目录层次。JMX的访问控制可能限制了JMX接口访问管理服务器的方式，供应脚本必须针对这种约束做出调整。

　　编写适应性强的脚本

　　自动供应最关键的优点在于：您可以使用一个环境的供应脚本作用原型用于其他环境。要实现这一点，编写供应脚本时应该注意使脚本的行为与特定的环境需求相适应。要真正实现适应性强的脚本，您需要一个完善的脚本语言。幸运的是，Jython和Python非常适合这种情况。

　　如果您使用 WLST，应该使用Jython语言编写供应脚本。当您启动WLST并执行其脚本时，您实际上运行的是WLST工具中嵌入的Jython解释器。您也可以启动Jython解释器并将WLST加载到其中，以在Jython脚本中执行WLST命令。使用任何一种方法都可以发挥Jython语言的全部能力。

　　下面是一个摘自环境供应脚本（WLST离线脚本）的片段：

　　weblogic_listen_port = int(profile[ 'managed.server.listen.port' ])

　　hostnames = profile[ 'managed.server.hosts' ]

　　managed_server_count = len( hostnames )

　　for idx in range( managed_server_count ) :

　　listen_address = hostnames[idx]

　　interface_address = listen_address

　　managedServer = create( managedServerName, 'Server')

　　managedServer.setInterfaceAddress( interface_address )

　　managedServer.setListenAddress( interface_address )

　　managedServer.setListenPort( weblogic_listen_port )

　　

　　我没有展示它是如何创建的，但对象profile属于Python语言，它包含定义每个要供应的特定环境变量的键值对。这些值可以从一个或多个外部属性文件加载，也可以使用开始导入的Jython脚本设置。下面是一个Jython导入文件的等效示例：

　　def getProfile () :

　　env = {}

　　env['managed.server.listen.port'] = 7001

　　env['managed.server.hosts'] = \

　　[ "hostname_1", "hostname_2", "hostname_3" ]

　　return env

　　

　　如果这在名为environment.py的Jython文件中，那么可以使用以下两行初始化profile对象：

　　import environment

　　profile = environment.getProfile()

　　

　　注意如何使用Jython功能减少所需条目的数量。没有必要明确定义环境中受管服务器的数量：这可以从managed.server.hosts元素的内容中获得。

　　我展示的只是一个非常简单的示例，但它说明了一些重要的适应性技术：

　　供应脚本中导入了供应的变化方面。在本例中，它们从属性文件加载，但也可以通过单独的Jython脚本导入。

　　脚本可以扩缩，不需要更改即可用于配置一个或多个受管服务器。

　　脚本采用必需的模式，这些模式对于所有环境相同的。在本例中，模式是所有受管服务器使用的接口地址都与侦听接口相同，并且它们都使用相同的侦听端口。此外，受管服务器的唯一服务器名称的形式为，其中是所有服务器的共同点。示例中，是使用键值managedServerNameRoot从 dictionary元素中获得的，索引的值从1开始。这种配置模式在大型环境中很常见。

　　现在，假设上述受管服务器始终是群集的一部分。配置群集时，您需要设置群集地址。群集地址可以设置为DNS名称，也可以是以逗号分隔的服务器IP地址和端口号所组成的列表。经验告诉我们，只有后期阶段的测试环境才配置DNS服务器。让我们向代码片段中加入一些次要的内容（并添加Jython导入）：

　　import environment

　　profile = environment.getProfile()

　　weblogic_listen_port = int(profile[ 'managed.server.listen.port' ])

　　hostnames = profile[ 'managed.server.hosts' ]

　　managed_server_count = len( hostnames )

　　cluster_list = ''

　　for idx in range( managed_server_count ) :

　　listen_address = hostnames[idx]

　　interface_address = listen_address

　　managedServer = create( managedServerName, 'Server' )

　　managedServer.setInterfaceAddress( interface_address )

　　managedServer.setListenAddress( interface_address )

　　managedServer.setListenPort( weblogic_listen_port )

　　cluster_list = \

　　cluster_list + listen_address + ":" + str(weblogic_listen_port)

　　if 'cluster.dns.name' in profile :

　　cluster.setClusterAddress( profile['cluster.dns.name'] )

　　else :

　　cluster.setClusterAddress( cluster_list )

　　

　　在这个修改过的代码片段中，您积累了一个以逗号分隔的服务侦听地址和端口所组成的列表。如果在配置文件中提供了DNS名称（本例没有），则可以使用其作为群集地址，但默认情况下使用积累的地址和端口列表。

　　端对端供应：共享配置数据

　　在大部分测试环境中，供应的不仅仅是WebLogic域。例如，Apache Web服务器可以用于群集中受管服务器的静态HTTP目录或者平衡其HTTP请求的负载。供应脚本中也可以实现其他此类环境组件的配置。下面是一个environment.py的扩展版，包括了一个用于Apache Web服务器的配置值：

　　def getProfile () :

　　env = {}

　　env['managed.server.listen.port'] = 7001

　　env['managed.server.hosts'] = \

　　[ "hostname_1", "hostname_2", "hostname_3" ]

　　env['apache.listen.port'] = 8080

　　return env

　　

　　要实现这一点，您需要向供应脚本添加几行代码（新增行添加到片段的最后面）：

　　import environment

　　profile = environment.getProfile()

　　weblogic_listen_port = int(profile[ 'managed.server.listen.port' ])

　　hostnames = profile[ 'managed.server.hosts' ]

　　managed_server_count = len( hostnames )

　　cluster_list = ''

　　for idx in range( managed_server_count ) :

　　listen_address = hostnames[idx]

　　interface_address = listen_address

　　managedServer = create( managedServerName, 'Server' )

　　managedServer.setInterfaceAddress( interface_address )

　　managedServer.setListenAddress( interface_address )

　　cluster_list = \

　　cluster_list + listen_address + ":" + str(weblogic_listen_port)

　　if 'cluster.dns.name' in profile :

　　cluster.setClusterAddress( profile['cluster.dns.name'] )

　　else :

　　cluster.setClusterAddress( cluster_list )

　　f = open('weblogic.conf', 'w')

　　f.write('\n')

　　f.write(' WebLogicCluster ')

　　f.write(cluster_list)

　　f.write('\n')

　　f.write(' MatchExpression *.jsp\n')

　　f.write('\n')

　　f.close()

　　f = None

　　f = open('httpd.conf', 'w')

　　f.write('Listen = ')

　　f.write( str( profile[ 'apache.listen.port' ] ) )

　　f.write('\n')

　　f.write('LoadModule weblogic_module modules/mod_wl_20.so\n')

　　f.write('\n')

　　f.write(' Include conf/weblogic.conf\n')

　　f.write('\n')

　　f.close()

　　

　　最后面的行创建两个文件：httpd.conf和weblogic.conf，分别用于配置Apache Web服务器和WebLogic插件。下面是httpd.conf形式的输出内容：

　　Listen = 8080

　　LoadModule weblogic_module = modules/mod_wl_20.so

　　Include conf/weblogic.conf

　　

　　下面是从environment.py生成的weblogic.conf：

　　

　　WebLogicCluster hostname_1:7001,hostname_2:7001,hostname_3:7001

　　MatchExpression *.jsp

　　

　　httpd.conf的配置使用键值 apache.listen.port，该键值从我们的environment.py文件中获得。但是要注意，插件的配置使用配置 WebLogic群集本身产生的副产品所累积的数据。WebLogic域配置数据曾经用于配置另一个相关的组件。这种配置数据的共享可以避免互相依赖的组件配置之间的不一致性。

　　注意，这是使用的技术（即直接使用Jython编写配置）并不是很恰当，只有在配置文件很小的时候才适合这样做。实际操作中，包括Apache Web服务器文件在内的许多配置文件都很大，不能简单的这样处理。在这种情况下，最好使用Jython输出带有配置值的属性文件，然后使用 Ant导入该属性文件，并根据配置文件模式执行标记替换。从WLST脚本中使用Ant很简单：安装了 WebLogic Platform 8.1和9.x的情况下，BEA包含一个运行Ant的Jython脚本。

　　不要使用过多的参数

　　编写适应性强的脚本的价值在于可以用于多个环境。但是，您不应该使用过多的参数。不要为不会随环境改变的属性和值创建参数，即使您的脚本会设置默认值。不必要的参数会使脚本更加复杂，使其变得更加难以理解。记住，您正试图创建的是可重用的脚本，可以在您进行其他项目之后仍然能被他人使用。每一个不必要的参数都会给您的继承者带来潜在的问题：“为什么所有环境采用相同值时要设置这个变量呢？我是不是哪里搞错了？”记住，您的继承者很可能有您的电子邮件地址和电话号码，会追问您可能早已不记得的事情！

结束语

　　BEA WebLogic Platform安装带来了三个功能强大的脚本工具：WLST、Jython和Ant。这些脚本工具可以用来构建强大的、适应性强的、可维护的供应和部署脚本，这些脚本可用于所有项目需要的环境来确保您的应用程序能够满足其需求。脚本不仅可以增强环境构建间的统一性，而且可以减少工作量，真是一举两得。