【IT168技术文档】
灵活的开发工作区使得构建过程中的某种形式的连续集成很受欢迎，并且 CruiseControl 是实现这种连续构建过程的流行框架。尽管集成 CruiseControl 和常见 Java 应用程序已经得到充分的证明，但是还需要一些额外的步骤来使 CruiseControl 更有效地处理 BEA WebLogic Workshop 应用程序。
本文将展示如何使用 CruiseControl 有 效管理 WebLogic Workshop 应用程序，从而允许您将 Workshop 应用程序应用到您自己的连续集成构建过程中。该集成的关键部分是编写可以解释 Workshop 的编译器输出的代码。本文还包含用来实现这项操作的自定义 Ant 任务的下载。
使用 CruiseControl 实现连续集成
CruiseControl 是一种开源产品，由 ThoughtWorks 出版发行，并获得了一个活跃社区的支持 。其目的是提供一种连续构建和测试过程的框架。 CruiseControl 可以使用多种源控件系统，并且可以通过各种可以想像到的方式发布结果，结果中包括最终的 Lava Lamp 解决方案。 CruiseControl 以 Java 为基础，并使用 Ant 作为其构建机制。
在构建我的工作区中的最新 WebLogic 项目之前，开发团队没有使用过每晚构建（ nightly build ）技术。事实上，他们只在新版本即将到期之前构建他们的应用程序，在那时承受所有的痛苦和折磨。花费大量时间设法获取需要构建的代码的故事就没有必要一一赘述了，因为我相信大家都已耳熟能详。因此，除了全新的 Workshop 环境之外，开发团队还用 CVS 设立了一个正确的源控件系统，并且越来越接近每晚构建的天堂。直到我们阅读有关 CruiseControl 的读物才得知， CruiseControl 是一种没有采用 每晚构建技术，但确实能够进行连续构建和测试的产品。
CruiseControl 之后的基本概念是构建您自己的代码，并在每次将代码加入源控制系统中时进行单元测试。在每晚构建系统中使用 CruiseControl 有两大主要优势。第一个优势是向开发人员提供相关即时反馈和开发过程连续性。不需要等到明天或者下周才知道构建是否成功，开发人员在几分钟之内就可以得到反馈，而且他们对正在编写的代码仍记忆犹新，因此，非常易于修复错误代码。第二个优势是 CruiseControl 不但可以执行单元测试，而且可以报告这些测试是否成功。使用每晚构建技术来模拟这种行为非常困难。
集成CruiseControl和WebLogic Workshop
CruiseControl 可以很好地使用常见 Java 应用程序，但是还需要一些额外的步骤来使 CruiseControl 更有效地使用 WebLogic Workshop 应用程序。本文中使用的方法包含如下几种：
1.设置标准的 CruiseControl 安装；本文中未作详细描述。
2.创建一种 Ant 脚本来编译 Workshop 应用程序。
3.开发自定义 Ant 任务来解释 Workshop 的编译器输出，并将其转换为 XML 。
4.为 CruiseControl 创建一种主 Ant 脚本。
5.写一份小的 XSL 文档，将 XML 转换为有用的 HTML 报告。
本文的其余部分将说明如何执行这些步骤。
设置CruiseControl
CruiseControl 的 web 站点中包含有关设置连续构建环境的优秀文档。本文将在此作一些简要概述。
在下载和编译 CruiseControl 之后，需要创建一份基本配置文件，文件名为 config.xml 。该文件包含将构建的所有项目。我通常将一个项目和一个 CVS 模块视为相等，主要是因为这样做适合我们的环境。每一个 <project/> 元素都指向源控制系统中的 CruiseControl ，通知它多长时间进行一次投票，以及如果检测到变更，需要运行哪一份 Ant 文件。
在该例中，我将使用一个 Workshop 项目（称作 MikesProject ）。为了使事情更加简单，我将使用 CVS 中的模块名。
示例 CruiseControl 配置文件如下所示。与典型的 Java 项目不同，此处的重点是 <log/> 元素中的数据。它引用了一个日志文件， Workshop 构建过程必须创建该文件，并通知 CruiseControl 将这个文件与常见构建输出合并。
清单 1. CruiseControl 配置文件，合并自定义构建输出文件
<cruisecontrol>
<!-- MikesProject Project -->
<project name="MikesProject" buildafterfailed="false">
<bootstrappers>
<currentbuildstatusbootstrapper file="logs/MikesProject/currentbuildstatus.txt"/>
</bootstrappers>
<modificationset quietperiod="60">
<cvs localworkingcopy="checkout/MikesProject"/>
</modificationset>
<schedule interval="300">
<ant buildfile="masterbuild.xml" target="MikesProject">
</schedule>
<log dir="logs/MikesProject">
<merge file="checkout/MikesProject/build.log.xml" />
</log>
<publishers>
<currentbuildstatuspublisher file="logs/MikesProject/currentbuildstatus.txt"/>
<htmlemail mailhost="localhost"
skipusers="false"
returnaddress="cruisecontrol@your.domain.com"
defaultsuffix="@your.domain.com"
css="/opt/cruisecontrol-2.1.6/reporting/jsp/css/cruisecontrol.css"
xsldir="/opt/cruisecontrol-2.1.6/reporting/jsp/xsl"
logdir="logs/MikesProject">
<always address="mike"/>
</htmlemail>
</publishers>
</project>
</cruisecontrol>
有关设置标准的 CruiseControl 分布的详细说明，请遵照 web 站点 中的使用说明。
Workshop构建过程
设置构建过程（对每晚 / 每周 / 连续构建来说都是相似的 ） 的下一步是能够使用 Ant 在命令行中编译 Workshop 应用程序。 Workshop 提供了一种易于使用的 Ant 任务（称为 wlwBuild ）；此外， Workshop 将创建一种简单的 Ant 脚本，为您提供更高的起点。在 Workshop 中，在 Tool 菜单中选择 Application Property 。在弹出的对话框中，选择 Build 节点，然后点击右边的 Export to Ant file 按钮。 Workshop 将 Ant 文件保存在应用程序目录（称作 exported_build.xml ，通常重命名为 build.xml 。）中。由此产生的脚本将调用 wlwBuild Ant 任务，并在编译时引用（在本文的示例中）项目的 MikesProject.work 文件。
该脚本需要进行一些编辑，才能用在台式机以外的更多地方中。默认情况下，它将包含到达应用程序在工作站中所在位置的硬编码路径。 Workshop 将生成两种具有硬编码路径的属性标签，其名称分别为 app.local.directory 和 project.local.directory 。默认情况下， Ant 将项目目录（实际上是 build.xml 文件所在的目录）用作其工作目录，并相应的设置 ${basedir} 变量。因此，应该将这两种标签的路径更改为相对路径：
<property name="app.local.directory" value="${basedir}/../" />
<property name="project.local.directory" value="${basedir}" />
因为我们的工作站是基于 Windows 的，而我们的构建服务器运行的是 HP-UX ，所以我们已经在项目中添加了两份文件，即 Windows 2000.build.properties 和 HPUX.build.properties 。这两份文件包含两个属性名称 / 值对，分别与 BEA 安装路径和 WebLogic 安装路径有关。因此， Ant 脚本的第二行就如下所示：
<property file="${os.name}.build.properties"/>
Ant 将加载适当的文件和属性。在创建 Ant 文件时必须严格遵守纪律，以确保与 WebLogic 相关的路径的所有引用都使用属性文件中的属性。
一旦创建了 Ant 脚本，您就会想在工作站的命令行中测试该脚本。
此处需要注意的一点是：即使 Workshop 允许您通过 Workshop IDE 运行 Ant 脚本，也不要在测试时依赖这一点。运行在命令行环境中与在 Workshop 中编译有很大的区别；我花费了很长的时间，试图挑选出那些成功编译了无法在命令行中编译的应用程序的不可思议的 Workshop 。
一旦在工作站中编译好应用程序，就可以将它们加入源控制系统中。并在构建系统中检验整个应用程序，并设法在命令行中编译该应用程序。这看起来似乎是非常乏味的，但是它可以防止出现更多令人痛苦的事情。
