内容


使用 Rational Application Developer 与 Hudson 构建服务器来改进持续集成

创建一个持续集成环境以构建更好的程序

Comments

引言

集成正确的工具来完成工作,是许多软件开发员长久以来的梦想。当您在一个集合了优化工作参数的环境下工作时,您可以在一系列功能强大的单元之间作出权衡,以得到帮助顺利地完成工作。让环境高效地整合到一起是非常关键的;在您开始执行本文所概括的步骤之前,首先您必须满足一些关键的前提条件,概括了所需的知识与工具。

需要的知识与工具

如果您想顺利完成本文的学习,那么您需要拥有一些和 IBM® Rational® 程序开发员打交道的经验,以及使用它来创建 Apache Ant(另一种 Neat 工具)构建文件的知识。

您还需要以下的几款工具:

  • Rational Application Developer 构建工具 7.5.5
  • Ant-Contrib 0.6
  • Hudson 1.312 及其 Rational Application Developer Builder 插件 1.1.2(这部分内容将会在本文的 第二部分 中进行论述)。

查看 参考资料 部分以得到这篇文章。

创建一个构建文件以和 Rational Application Developer 构建工具一起使用

Rational Application Developer for WebSphere® 软件构建工具,从现在开始简称为构建工具,是 Rational Application Developer 以一种无显示器的的方式为构建 J2EE 程序提供的一种附加构件。所谓的“无显示器的”方式指的是构建工具可以在没有显示器的电脑上使用,这样的机器一般关注于持续性集成环境的使用来构建程序。所以,构建工具是一种完美的工具,在持续性集成的环境下可以帮助您自动化程序的构建。

构建工具是命令行驱动的,并使用 Ant 构建文件来描述执行的操作。伴随而来的还有完整系列的 Ant 任务来构建 Rational Application Developer 程序,比如将项目导入到一个工作区内,构建一个工作区,将程序作为 WAR 或者 EAR 文件导出等等。查看一下 Rational Application Developer 信息中心中 相应的章节 来得到构建工具特性的完整概观。

因为构建工具使用 Ant 作为它的基础,所以它还可以从所有标准的 Ant 任务中获利。而且,通过添加新系列的 Ant 任务来扩展其特性会非常容易。在本文中,我们将会使用 Ant-Contrib(查看 参考资料)来利用像如果/然后结构、循环等等之类的新行为。

我们在本文中将会使用到以演示的程序是 EJB 3.0 Online Library,您可以从 Rational Application Developer 产品信息中心处获得它。通过切换至 Help > Help Contents > Samples > Application samples > EJB 3.0 Online Library > EJB 3.0 Online Library complete implementation 并点击 Import sample 项目,您可以从 Rational 程序开发员工具中得到它。这将会在您当前正在使用的 Rational 程序开发员工作区中创建三个项目:

  • EJB3Library 是一个包含了程序所用 EJBs 的 EJB 项目。
  • EJB3LibraryWeb 是使用以前提到过的 EJBs 的 Web 程序,并通过一个 Web UI 向用户公开。
  • EJB3LibraryEAR 是用于在单个企业程序中包装 EJBs 与 Web 模块的 EAR 项目。

本文并不涉及到构建工具的安装过程。如果您想要了解帮助您去安装的完整步骤,那么请参考 Rational Application Developer 开发员的信息中心中相应部分 。在接下来的步骤中,我们将会假设我们是在 Microsoft® Windows® 上构建我们的持续性集成方案,我们在它上面运行构建工具 7.5.5,而且它是在 C:\CIEnv\BuildUtility 上安装的。

同样没有被本文讨论的,还包括 Ant-Contrib(我们将会使用到 Ant-Contrib 0.6)的安装。您可以参考 Ant-Contrib 的文献资料(见于 参考资料)以得到这方面的信息。我们将会假设它安装在 C:\CIEnv\ant-contrib-0.6-bin 位置处。

注意我们将会在本文 第二部分 中看到的构建工具与 Hudson,既可以在 Microsoft Windows 上也能在 Linux® 上运行,所以您可以尽情地选择您喜欢的平台。

您要编写以构建该程序的构建文件相对来说是比较简单,而且在组成了以下的操作:

  1. 首先,它创建了所要使用的 Rational Application Developer 工作区。
  2. 接下来,它将构建的项目导入到了新的工作区内。
  3. 然后,它构建了工作区。
  4. 最后,它将构建程序作为单个的 EAR 文件导出。

在接下来的步骤中,我们将会试着让构建文件变得尽可能的通用,这样它就可以更容易为其他项目重复使用。所以,我们将会尽可能地使用 Ant 属性,例如外化将会为构建文件使用到的 Rational Application Developer 项目的名字。

开始构建文件

开始时编写构建文件是非常容易的。我们只需要创建一个名为 build.xml 的新文件,以定义根项目并使用 Ant 的 taskdef 指导,这样构建工具就知道 Ant-Contrib 的 jar 文件位于什么位置了:

清单 1. 初始的 build.xml 文件
<project name="rad-builder" default="build-all" basedir=".">

  <!-- Ant-Contrib (if, foreach, etc.) -->
  <taskdef resource="net/sf/antcontrib/antcontrib.properties">
    <classpath>
     <pathelement location="C:/CIEnv/ant-contrib-0.6-bin/lib/ant-contrib-0.6.jar"/>
    </classpath>
  </taskdef>

  <!-- All additional content will be added here -->

</project>

创建 Rational Application Developer 工作区

当您使用构建工具构建一个程序时,创建和建立一个工作区是第一步。它使程序使用预定义的和共享的标准来构建。例如,通过控制工作区创建步骤,可以确保开发员根据特定的 Java 版本来构建程序,或者适当地为源代码进行了编码等等。

因此这并不需要太长的时间,所以推荐您在每一个构建发生时,都创建并建立一个新的工作区。这样做,您就可以确保没有更改超出您的控制,并且可以标准地应用到其余的所有部分中。

创建工作区由两步组成:

  1. 首先,在文件系统上创建一个新的文件夹。
  2. 然后,您必须设置 workspace 环境变量,这样它会在运行构建工具之前,指向新创建的文件夹。

这是在构建文件的外部完成的,可能使用了批处理文件,在 Windows 上如下所示:

清单 2. myRunAnt.bat
set workspace=C:\CIEnv\workspace
C:\CIEnv\BuildUtility\eclipse\bin\runAnt.bat

该批文件,您可以命名为 myRunAnt.bat,将会认为 build.xml 文件位于它所运行的文件夹中。如果您的构建文件的名字不是 build.xml 或者位于其他的地方,那么您需要使用 -buildfile 选项。

为了合适地处理 workspace 环境变量,我们将会向构建文件添加以下的代码:

清单 3. 工作区属性处理
<propery environment="env"/>
<property name="workspace" value="${env.workspace}"/>

在这里有很重要的一个事情是,Ant 属性是事例敏感型的:env.workspace 是与 env.WORKSPACE 不一样的范例。结果,您必须确保 workspace 环境变量只使用小写字母来设置,否则 env.workspace 将不会被设置而且运行构建文件将会失败。

创建工作区是用 workspacePreferenceFile 任务来完成的。该任务基于使用 preferenceFileName 属性指定的文件,来设置工作取得偏好。该文件可以使用两种不同的格式:

  • 第一种格式是标准的 Java 属性文件,由名字-值的对组成。这是一种使用起来最简单的格式,但是它支持控制一系列有限的环境:汇编器版本、一些额外的汇编设置与运行时环境。例如,它并不允许您去控制源代码的编码。您可以在 Rational 程序开发员信息中心的 一个文件的范例
  • 第二种格式是标准的 Eclipse 偏好文件(.epf 扩展名)。该文件允许您去控制每一个 Rational 程序开发员偏好。手动更新要更加困难,但是它完全可以从 Rational 程序开发员处获得。这就是我们在本文中所使用到的格式,大多数时候,只有运行时环境才有可能进行手动编辑,如果它们没有安装到那些要构建程序的电脑上相同的位置处的话。

为了使用这种格式,需要将 workspacePreferenceFile 任务的 useEclipsePrefs 属性设置为 true(对于产品有的比较老的版本,该属性并不存在,而您需要使用一个名为 useEclipsePrefs 的属性来模拟该特性 - 参考您相应的 Rational 程序开发员信息中心)。如果它被设置成了 false 或者没有设置,那么构建工具就会把格式自动设置为标准属性文件。在我们现在的范例中,我们不会直接将属性值设置为构建文件:它将会在外边设置,通过引入一个名为 rad.preferences.useeclipseprefs 的 Ant 属性,这样就不再需要编辑构建文件以从一个属性文件切换至 epf 文件。

清单 4. 创建工作区目标
<target name="setup-workspace"
  description="Sets the preferences for the current workspace">

  <!-- Some debug information -->
  <echo level="verbose" 
    message="rad.preferences.filename=${rad.preferences.filename}"/>

  <!-- Set the workspace preferences -->
  <workspacePreferenceFile
    PreferenceFileName="${rad.preferences.filename}"
    useEclipsePrefs="${rad.preferences.useeclipseprefs}"
    overwrite="true"/>
  <echo level="verbose" message="workspacePreferenceFile done"/>
</target>

这里您可以看到我们使用一个名为 rad.preferences.filename 的属性,来指定所使用的偏好文件。这是我们将会使用到的一个属性来让构建文件尽可能地通用。

为了生成 Eclipse 偏好文件,最简单的方式是使用 Rational Application Developer 创建一个新的工作区,在 Windows > Preferences 中定义设置然后通过

File > Export > General > Preferences 来将它们作为一个 epf 文件导出。对于本文具体的其他文件相反,本文的 Download 部分并没有提供一个作为范例的 epf 文件,因为它与用于生成文件的环境相关联。

注意构建工具还提供了其他的任务来创建工作区,例如使用 workspacePreferenceSet(以及 workspacePreferenceGet)来创建一个私人的属性。可以用它来为一些特定的项目更改特定的工作区偏好。

同样,您会注意到构建工具所使用到的工作区是一个标准的 Rational Application Developer;一旦构建工具创建了它,那么它可以同 Rational Application Developer 一起打开以进行故障排除,例如在出现汇编错误的情况下它们就不会出现在开发员工作站中了。当您编写构建文件时这一点非常有用,可以确保它能够发挥所有的作用。

将 Rational Application Developer 项目导入到工作区内

构建程序的第二步,当然是将 Rational Application Developer 项目导入到新创建的工作区内。与构建工具伴随而来的是一个主任务:projectImport。我们将会使用它来一个接一个地导入项目,而且我们将会使用 Ant Contrib 的 foreach 任务来在以逗号隔开列表中进行重复,这些列表描述了必须导入的所有项目。我们还可以使用 projectSetImport 任务,但是它还需要一个额外的文件来描述处理的项目。

清单 5. 导入-项目目标
<target name="import-projects"
  depends="setup-workspace"
  description="Imports a set of projects into the current workspace">

  <!-- Some debug information -->
  <echo level="verbose" message="basedir=${basedir}"/>
  <echo level="verbose" message="projects.name=${projects.name}"/>

  <!-- Import the projects -->
  <foreach
    list="${projects.name}"
    target="import-project"
    param="project.name"/>
</target>

<target name="import-project">
  <!-- Some debug information -->
  <echo level="verbose" message="project.name=${project.name}"/>
  <echo level="verbose" message="workspace=${workspace}"/>
  
  <projectImport
    projectName="${project.name}"
    projectLocation="${workspace}/${project.name}"/>
  <echo level="verbose" message="projectImport ${project.name} done"/>
</target>

这里您会注意到 Ant-Contrib 的 foreach 将其处理授权为导入-项目目标:foreach 任务创建以及为 projects.name 属性中每一个逗号隔开的值进行设置,一个新的名为 project.name 的属性,实际上是由 projectImport 任务所使用的。

您可能还会注意到我们使用依赖属性(depends="setup-workspace")来在这个新目标与 setup-workspace 之间定义了一种依赖关系:这就可以确保我们不会试着将项目导入到一个不合适的创建工作区内。我们会对每一个定义到的目标使用这种依赖机理,确保在下一个运行前前一个已经访问过了。

该代码中另外一个比较重要的地方在于 projectImport 任务 projectLocation 属性的值:它被定义为 ${workspace}/${project.name},这意味着它想要项目文件夹位于新创建的工作区内。这就是说,在导入实际上完成之前复制项目。我们这样做,这样其他剩余的就会保持位置不变(例如,更容易地分享)。为了执行该次复制操作,我们使用以下的目标,它需要一个新的 copy.from.path 属性来指示从哪里复制项目:

清单 6. 复制-项目目标
<target name="copy-projects"
  description="Copies the content of a folder to the current workspace">

  <!-- Some debug information -->
  <echo level="verbose" message="copy.from.path=${copy.from.path}"/>
  <echo level="verbose" message="workspace=${workspace}"/>

  <copy
    todir="${workspace}"
    includeEmptyDirs="true">
    <fileset dir="${copy.from.path}"/>
  </copy>
  <echo level="verbose" message="copy done"/>
</target>

当然,它意味着导入-项目目标对它有一个新的依赖关系,而且它的依赖属性必须进行相应的更新:

清单 7. 更新后的导入-项目目标
<target name="copy-projects"
<target name="import-projects"
  depends="setup-workspace,copy-projects"
...

汇编程序

构建程序接下来的一步实际上是汇编它。构建工具适合它,提供了两个主要的任务:

  • projectBuild 准备一次只汇编一个属性(使用 projectName 属性指定)。
  • workspaceBuild 准备汇编整个的工作区:这就是我们将会使用到的任务,正常条件下,只有需要的项目才会导入到工作区中,我们并不期望有一些有问题的项目会破坏构建过程。通过使用合并的 projectBuild 与 Ant-Contrib 的 foreach,能够节省很多的代码清单(越简单越好)。
清单 8. 构建-工作区目标
<target name="build-workspace"
  depends="import-projects"
  description="Builds the current workspace">

  <!-- Fully build the workspace -->
  <workspaceBuild
    BuildType="Full"/>
  <echo level="verbose" message="workspaceBuild done"/>
</target>

您不需要注意到 workspaceBuild 任务显示了工作区构建期间所发生错误相关的信息。您可能还会使用其他的任务,workspaceGetErrors,来在选择的位置处显示(例如在构建的末尾)为选择的信息(例如您可以选择只记录错误和警告信息,不包括其他的信息)。

将程序作为一个 EAR 文件导出

既然工作区已经进行了汇编,那么最后的一步就是将其导出到需要的格式了。与构建工具伴随而来的是如下的任务,根据您的需要您可以在其中挑一个或者多个:

  • appClientExport 将一个程序客户端项目作为一个 JAR 文件导出。
  • earExport 将会导出一个 EAR 文件。它将会自动构建需要的 WAR(对于 Web 程序)与 JAR 文件(对于 EJBs 或者工具项目)。
  • warExport 将会简单地导出一个 Web 程序。如果该 Web 程序依赖于一些工具项目,这些项目将会得到有目的的导出。

因为我们所使用的范例程序组成了一个企业程序,所以我们将会使用 earExport 任务来从以前汇编的项目中创建 EAR 文件:

清单 9. export-ear 目标
<target name="export-ear"
  depends="build-workspace"
  description="Exports the EAR defined by the ear.project.name/ear.filename properties">

  <!-- Some debug information -->
  <echo level="verbose" message="ear.filename=${ear.filename}"/>
  <echo level="verbose" message="ear.project.name=${ear.project.name}"/>

  <!-- Export the EAR project as an EAR file -->
  <earExport
    EARProjectName="${ear.project.name}"
    EARExportFile="${ear.filename}"
    ExportSource="true"
    IncludeProjectMetaFiles="true"
    Overwrite="true"/>
  <echo level="verbose" message="earExport ${ear.filename} done"/>
</target>

您可以在这里看到我们引入了两个新的属性。第一个是 ear.project.name,用于指示项目的名字,该项目将会作为一个 EAR 文件导出。第二个是 ear.filename,它用于指定该 EAR 文件的名字。

另外一点比较重要需要指出的是 Overwrite 属性被设置为真:结果,如果一个生成的 EAR 文件已经存在的话,那么它将会被覆盖掉。对于获取或者追踪为目的的操作来说,这可能会出现一些问题,但是我们将会在构建文件的外边来处理它。

现在构建文件是完整的了,我们只需要添加一个附加的 build-all 目标,正如您所观察到的那样,在构建文件的第一部分中被设置成了默认的。该目标将会简单地访问结果产生的 export-ear,通过目标依赖的机理到以上提到过的所有定义目标的连续访问:

清单 10. 构建一切的目标
<target name="build-all"
  description="Builds an application from scratch">
  <antcall target="export-ear"/>
</target>

构建文件现在已经完成了。我们可以运行它来确保所有的部分运转正常。这意味着我们必须设置所有以前提到过的属性。所以,我们将会使用构建工具的 -D 选项,它可以支持将属性作为一个名字/值对来处理。然后将会使用批文件来运行构建工具,如下面的代码清单 11 所示。

清单 11. 更新后的 myRunAnt.bat
set workspace=C:\CIEnv\workspace
C:\CIEnv\BuildUtility\eclipse\bin\runAnt.bat
  -Drad.preferences.filename=C:\CIEnv\workspace.epf
  -Drad.preferences.useeclipseprefs=true
  -Dprojects.name=EJB3Library,EJB3LibraryWeb,EJB3LibraryEAR
  -Dcopy.from.path=C:\CIEnv\EJB3Library
  -Dear.filename=EJB3Library.ear
  -Dear.project.name=EJB3LibraryEAR
  -verbose

在这里,我们假设:

  • 我们所需要的所有文件都位于 C:\CIEnv folder;
  • 构建文件名为 build.xml;
  • 使用的工作区名为 workspace;
  • 工作区偏好文件被命名为 workspace.epf(它是一个 epf 文件,这样我们还需要将 rad.preferences.useeclipseprefs 属性设置为 true);
  • 范例程序源代码位于 EJB3Library 文件夹中。

如果发生什么错误的话,我们还会定义 -verbose 选项来得到额外的日志。

当您运行批处理文件,或者 Linux 上的内核脚本文件时,您将会得到一个数百行的日志(主要是由于 -verbose 选项)。就算日志在结尾说 构建已成功,您仍然需要查看它以完全理解发生了什么。您将能够看到访问了什么目标,以什么顺序,构建工具执行了什么内部操作等等。您还能够查看汇编期间出现的警告以及错误,这样在需要时您就可以操作工作区偏好了。

构建文件现在完成了并且处于全功能状态。现在是时间去从 Hudson 内部去使用它了。

使用 Hudson 来构建您的程序

Hudson(查看 参考资料)是一种开放源的持续性集成服务器。它运行并监视组成构建步骤的任务。这些构建步骤是使用许多不同的技术来定义的,例如 Ant、Windows 批处理命令、内核脚本等等。

Hudson 有许多有意思的特性,例如运行分布式构建(在一些电脑上同时进行)的能力,广泛使用 RSS(例如通知)的能力等等。您可以查看一下 Hudson 维基(见于 参考资料)以得到关于 Hudson 特性的深入描述。

Hudson 是一种 Java 5.0 的 Web 程序。它由一个非常活跃的开放源社团进行持续性的改进,几乎每周都可以得到它的一个新版本。该社团对 Hudson 的核心作出了巨大的贡献,不论是代码还是文献,还是通过公布插件来交付他们所做的工作:插件是扩展 Hudson 的一种方式,他们都有不俗的成绩。它们中的大多数都已经可以在网上获得,包括许多不同的话题:有一些支持像构建步骤(在本文中,我们将会使用的一些插件,会提供对构建工具的支持功能,您可以查看 参考资料)这样的新技术,另外一些支持用户从 Rational ClearCase 这样的配置管理工具处获得他们的数据,还有其他的一些允许处理虚拟机,一些运行扭曲 Web UI 等等。您可以查看一下可用插件的列表(查看 参考资料)以得到其巨大功能的一个概念:它们海量的数据与种类一定会给您留下深刻的影响。

在本部分中,我们将会执行以下的操作来使用 Hudson 中的构建工具:

  • 首先,我们将会看看怎样快速地启动 Hudson。
  • 接着,为难将会安装并创建插件,这些插件将会为构建工具提供支持。
  • 然后,我们将会创建一个任务,该任务将会使用到我们在本文 第一部分 中所创建的构建文件。
  • 最后,我们将会运行它来确保所有的部分都能正常运转。

启动 Hudson

正如前面提到过的那样,Hudson 是一个 Java 5.0 Web 程序。您可以从 Hudson 的主页(见于 参考资料)以 WAR 文件的格式得到它。然后我们会在 servlet 容器的顶部安装它,例如 Apache Tomcat(见于 参考资料),但是我们将会使用到 Hudson 一个比较好用的特性:通过运行以下的命令来在一个 servlet 容器的外部运行的能力:java -jar hudson.war(您必须使用 JDK 5.0 或者 JDK 6)。

在运行的时候,该命令将会自动启动一个嵌入的 servlet 容器,使得 Hudson 已经为使用做好准备。然后,为了访问它的 Web UI,我们只需要将 Web 浏览器指向 http://localhost:8080/。

Hudson 的Web UI 是很简单的(见于图 1),但是却很有效:它的主要部分是位于界面左边的工具栏以及它周围的主窗格。这一部分比较重要的两点是工具栏中的 Manage Hudson 与 New Job 操作。第一个操作允许我们创建 Hudson,第二个操作允许我们创建我们的范例任务。

图 1. Hudson 的主界面
显示 Hudson 欢迎界面的屏幕截图
显示 Hudson 欢迎界面的屏幕截图

但是在继续之前,您可能会注意到,在运行 Java 命令之后显示的日志中,Hudson 使用了一个主目录。这是因为 Hudson 使用文件系统而不是数据库系统来存储它所处理(配置,任务执行结果等等)的文件。

默认条件下,该主目录被命名为 .hudson,并且位于运行 Java 命令用户的主文件夹中。当然,这样的位置在产品环境下可能不太方便。可以通过使用 HUDSON_HOME 变量来对其作出调整。例如,为了将 Hudson 的主文件夹设置成 C:\CIEnv\hudson,在运行 java -jar hudson.war 之前,您可以在 Windows 上运行以下的命令,set HUDSON_HOME=C:\CIEnv\hudson。Hudson 将会将其所有的文件都置于该目录下。

安装并创建 Rational Application Developer Builder 插件

既然 Hudson 已经在运行了,我们就可以安装插件了,它允许任务使用构建工具。该插件名为 Rational Application Developer Builder 插件(见于 参考资料)。我们将会使用从 Hudson 站点(见于 参考资料)处下载的 1.1.2 版本作为名为 rad-builder.hpi 的 HPI 文件。按照以下方式来安装它:

  • 从 Hudson 的 Web UI 中,切换至 Manage Hudson > Manage Plugins > Advanced
  • Upload Plugin 界面中,浏览到您刚刚下载的 rad-builder.hpi 文件。
  • 点击 Upload 按钮(该操作将会向 Hudson 主文件夹中的插件文件夹上传 rad-builder.hpi)。
  • 一旦要求这样做,就重启 Hudson 这样它就可以使用插件了。

在创建使用构建工具的任务之前,我们需要做一些额外的创建工作。如果您来到 Manage Hudson > Configure System,它是 Hudson 的主配置界面,那么您将会看到有一个 IBM Rational Application Developer 7.0/7.5 部分(见于图 2)。该部分由插件所配置并用于定义在什么地方安装构建工具,或者普通的 Rational Application Developer 安装(插件现在与 Rational Application Developer 的 7.0 版本与 7.5 版本兼容)。

事实上,指定普通的 Rational Application Developer 安装过程是可能的,因为就算构建工具是 Rational Application Developer 7.5 新交付的工具,Rational Application Developer 的早期版本,例如 7.0 版具有相同功能,但是它会直接嵌入到工具里面去。例如,如果您看一下 Rational Application Developer 7.0 的 bin 文件夹,您将会看到 runAnt.bat 与 runAnt.sh 命令都是可用的。

让我们回到我们的 IBM Rational Application Developer 7.0/7.5 部分中。它支持定义一些安装:当您使用 Rational Application Developer 7.0 而有些人使用构建工具时,这一点是十分有用的。在这种情况下,您可以定义两种安装情况。

为了添加一种安装,您可以点击 Add Rational Application Developer 按钮,设置一个名字(例如,BU 7.5)并指定构建工具的安装目录(例如 C:\CIEnv\BuildUtility)。然后,保存所做的更改。

图 2. 在 Hudson 中定义构建安装
显示 Hudson 中构建工具的图
显示 Hudson 中构建工具的图

创建并成建立一个新任务

既然在 Hudson 中已经定义了构建工具安装,所以我们可以创建一个使用该安装的新任务。从 Hufson 的主页面中,点击一下 New Job。您需要输入一个任务名,例如 EJB3Library,然后选择一种认为类型:我们会使用 构建一个自由形式的软件项目 ,它由很大的可能性被您看到。点击 OK:任务配置界面将会显示出来。

任务配置是很简单的。在任务配置界面的顶端,用户可以定义通用性的选项,例如添加构建参数等等。在这里,您可能会注意到位于每一个区域中右边的蓝色问题符号。点击它们以得到关于该区域的直接帮助。

然后用户可以指定使用 源代码管理 部分中的软件配置管理(SCM)工具。可以在框以为得到 CVS 与 Subversion,但是可以通过使用插件来添加其他的许多人,例如 Rational ClearCase(查看 参考资料)。注意在本文中我们并没有使用 SCM 工具,但是这是需要的。协作性构建软件的团队通常会想要进行持续性的集成,这就需要使用 SCM 工具来处理更改、冲突/合并 等等。

接下来用户可以定义的一个部分是 Build Triggers。这就是用户定义什么时候运行任务的地方:任务的执行可以在另一项任务执行完成之后才开始,或者在一个时期的基础(可以使用它来激活构建),或者基于 SCM 工具的更改。当然,它还可以由用户手动激活。

接下来的部分是 Build。这就是我们定义构建工具从而从源代码中生成 EAR 文件的地方(见于图 3)。为了完成该项操作,您可以点击 添加构建创建 按钮并选择 IBM Rational Application Developer 7.0/7.5 项目。接着会出现一个新的相应的构建创建界面,其中 Rational Application Developer 安装区域已经正常地显示出来。接下来是一个可选的 Targets 区域,用户可以在这个区域内定义一个构建工具所访问的列表对象。如果您点击了 Advanced... 按钮,那么您可以得到额外的区域:

  • Build file 就是用户选择构建工具所使用的构建文件名字的地方。默认条件下,构建步骤将会搜索任务工作区内名为 build.xml 的文件。

任务的工作区与 Rational Application Developer 工作区是不同的:这是一个特定于每一个 Hudson 任务的文件夹,简单地命名为工作区,在任务第一次运行之前创建(注意在分布式环境下使用时该行为将会变更)。一旦您运行了任务,那么假设 Hudson 的主文件夹是 C:\CIEnv\hudson,工作区文件夹将会是 C:\CIEnv\hudson\jobs\EJB3Library\workspace。

所以,我们要把该区域设置为 ..\..\..\..\build.xml,它对应于任务工作区 C:\CIEnv\build.xml 的路径。

  • Rational Application Developer 工作区 是一种用户可以定义构建工具所使用is the field where the user can define the name of the Rational Application Developer 工作区名字的地方。该区域是可选的,其他所有的区域也是可选择的。对于本文,我们保持它们为空白状态不变。
  • 创建 PROJECT_WORKSPACE 变量 是一种很有意思的特性(但是我们并不会使用到它):正常条件下,Hudson 会自动创建一个 WORKSPACE 变量,任务可以使用该变量来在工作区上运行一些操作。但是,在这里,该变量实际上会引用 Rational Application Developer 工作区。然后该特性支持创建一个新的 PROJECT_WORKSPACE 变量,该变量会引用任务的工作区。
  • 删除 Rational Application Developer 工作区内容 是一个非常不错的特性:如果构建工具实际上被调用时,该区域被选中的状态下,Rational Application Developer 工作区就被删除掉了,如果它已经存在的话。正如前面提到过的那样,这就有助于确保构建工具使用一个清洁的 Rational Application Developer 工作区,避免一些常见陷阱的干扰。这里,我们将会选中它,因为我们的构建文件会在每一次运行时将项目复制到 Rational Application Developer 工作区中。这一次,还是可以从 SCM 工具中正常得到源代码。
  • 处于选中状态下时,在构建工具运行之前,只删除 Rational Application Developer 工作区元数据文件夹 区域将会简单地删除掉 Rational Application Developer 工作区中的 .medata 文件夹。位于 Rational Application Developer 工作区中的所有其他文件仍然会保持不变。
  • Properties 区域仍然很有意思:这就是我们定义构建文件所使用的所有属性的地方。结果,我们将会按照下述内容来设置该区域,这样在构建文件运行时在需要的情况下就可以得到所有的属性了。
清单 12. 构建步骤的属性
rad.preferences.filename=C:/CIEnv/workspace.epf
rad.preferences.useeclipseprefs=true
projects.name=EJB3Library,EJB3LibraryWeb,EJB3LibraryEAR
copy.from.path=C:/CIEnv/EJB3Library
ear.filename=EJB3Library.ear
ear.project.name=EJB3LibraryEAR

注意我们将路径分隔号从反斜杠变成了斜杠。

图 3. 为 Hudson 任务定义 Rational Application Developer 构建步骤
显示 Hudson 中构建步骤编辑器的图
显示 Hudson 中构建步骤编辑器的图

提示:如果您定义了一些构建步骤,那么您可以在需要的时候拖拉它们来给它们重新排序。

在我们定义构建步骤之后,查看一下 Post-build Actions 部分。它允许您去定义在构建步骤完成之后执行的操作。用户可以请求 Hudson 来激活其他任务的执行,或者发送通知电子邮件等等。另一个感兴趣的特性是 Archive the artifacts:在设置时,Hudson 将会自动记录用户定义的工件(例如,EAR 文件),该文件是在构建期间所生成的,这就是为什么我们不感兴趣的原因,在本文的 第一部分 中,其中谈到了在保存新 EAR 文件之前先保存旧 EAR 文件。

任务配置工作现在完成了。我们可以将其保存,这将会把我们带到任务的主界面中,然后我们可以点击 Build Now 操作来运行任务。在 Build History 窗格中将会简单地显示出一个空白的项目,代表任务现在正在执行中。一旦执行完成了,那么在显示一个蓝色的子弹的同时它会停止闪烁,这意味着任务已经顺利结束。

为了保证每一件事情正常发挥作用,我们可以做两件事:

  • 首先,我们可以确定 EAR 文件得到了适当的创建:因为 earExport 任务使用它的基础目录来生成 EAR 文件,这意味着 EJB3Library.ear 在 C:\CIEnv 中得到了创建。
  • 然后,回到 Build History 窗格中 Hudson 的 Web UI 中,我们可以点击与构建执行相应的行。它将会向我们提供一些新的操作,最重要的一个是 Console Output:如果您点击它的话,那么在任务执行期间您就可以得到产生的所有日志了(因此,构建工具日志)。

另一个重要的项目,当前没有激活的,就是 No changes 选项。如果我们正在使用的是 SCM 工具,那么我们可以得到构建发生之前在 SCM 工具中发生的所有更改的综合性列表。

注意当执行发生时,注意 Build History 窗格中的链接可以点击,允许以一种实时的方式来访问日志。

更深入地学习

本文只涉及到了使用一个持续性的集成服务器的构建程序过程。这只是一个开始,还需要一些其他的任务,例如向 SCM 工具添加持续性的集成服务器,运行单元测试,在运行时环境中部署程序,以及执行递归测试

,来使用一个完全功能的持续性集成环境。

结论

在本文中,我们将会看到可以怎样使用 Rational Application Developer 构建工具来构建 Rational 程序开发员设计的构建程序。为了完成此项任务,我们将会从一系列的 Rational 程序开发员项目中创建一个简单的通用构建文件,生成一个 EAR 文件。然后我们将会安装并创建 Hudson 持续性集成服务器,并创建一个 Hudson 任务,该任务会使用构建工具来最终生成 EAR 文件。现在您可以构建无显示器的程序并在一个持续性集成环境中权衡使用它们。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=630535
ArticleTitle=使用 Rational Application Developer 与 Hudson 构建服务器来改进持续集成
publish-date=07142010