http://www.ibm.com/developerworks/cn/architecture/ar-autotask/
级别: 中级
Ahmed Abbass ([email protected]), IT 架构师, IBM
2007 年 9 月 13 日
本文提供逐步的详细说明,以帮助使用 IBM® Rational® 软件交付平台(IBM Rational Software Delivery, SDP)的内置 Ant 支持实现构建过程自动化,从而提高效率和质量。您可以随后使用 IBM WebSphere® 应用服务器系列之一对其进行部署。
<!----><!----><!---->
对于多版本项目,要提供新版本来跟上新功能或缺陷报告增加的速度,并同时仍然保持可接受的质量水平,可能是一项不小的挑战。构建自动化可确保准确性和消除人为错误的可能性,从而部分地解决此问题。自动化还可让成员将精力集中在需要人类智慧的问题上,而不用分心进行自动化后通常能更快更有效地运行的任务,从而提高了团队效率。
在本文中,我们将了解如何实现构建过程的自动化,以获得较高的效率和质量。本文中的示例将利用 Rational 软件交付平台(IBM Rational Software Delivery, SDP)中的内置 Ant 支持(构建自动化过程作为 Ant 构建文件实现)以及运行时(如 WebSphere Application Server)中的支持。本文最后将给出一些可以用于进一步简化此流程的可选功能。
|
尽管在构造* 阶段之前并不会开始执行,但任务自动化应该在细化* 阶段就进行规划,以便在交付代码进行测试之后即能供实现团队使用。在进行了分析和设计后,组件的远景以及应该如何对其进行构建、测试和部署就应该清楚了。在此远景的启发下,应该以允许重复的方式开始完成任务自动化工作。
|
为了便于进行重复,可能需要在开始前进行一些任务准备工作(如准备测试数据),并在完成后进行清理。对软件配置管理(软件存储库)、设计或目标部署环境的更改也应该反映在任务自动化中。在工作预估和项目规划期间,应该考虑实现和维护此自动化的开销。可以进行测试,以观察任务自动化对具有多个迭代的项目的影响,确定何时每个迭代的构建、单元测试和部署的时间大幅度减少。
|
本文中的自动化过程适合于基于 Rational SDP 的工具,如:
对于部署平台,可以将其用于使用 WebSphere Application Server 作为基础的 WebSphere 应用服务器系列,如 WebSphere Application Server、WebSphere Application Server Network Deployment 和 WebSphere Process Server。
示例过程可以应用于其他 Rational 和 WebSphere 产品。为了简单起见,我们将所使用的工具称为集成开发环境(Integrated Development Environment,IDE)。
此过程可以在各种环境配置上运行。图 1 显示了一个示例环境。
此环境包含一个或多个开发工作站,供开发人员编写代码之用。更改保存到存储库中。此处我们假设使用 Rational ClearCase 存储库,为每个开发工作站提供了一个快照视图。
开发工作站应该安装了基于 Rational SDP 的工具。开发工作站应该具有配置为使用软件存储库的工作区。文章“使用 Rational Software Architect 和 ClearCase Remote Client”提供了关于如何使用 Rational ClearCase 进行此类配置的更多信息。还可以使用其他存储库;有关将 Ant 与并发版本系统 (Concurrent Versions System, CVS) 一起使用的更多信息,请参见参考资料。
任何开发工作站都可以作为构建工作站使用。最好将用于进行构建的工作站分离开,以避免开发人员间出现使用竞争。构建工作站应该与任何其他开发计算机具有相同的配置,而且能够访问以下服务器:
可以在 Windows® 或 Linux® 上实现典型的开发或构建工作站。对于目标部署服务器,WebSphere 产品提供了更为广泛的受支持平台。
所有自动化步骤都将包括在一个 Ant 构建文件中,以便进行维护。如果您尚不熟悉 Rational 工具,请按照以下所述进行操作:
ar-autotaskcode.zip
,并单击 Finish。
|
build.xml
作为文件名。单击 Finish。(这就是我们在此要涉及的所有步骤。) 列出 Ant 构建文件,如清单 1 中所示。
<!----> <project name="Automation Project" basedir="." default="init"></project> <!----> <property file="build.properties"></property> <!----> <target description="Initialize automation environment" name="init"></target> <!----> <tstamp></tstamp> <!----> <property environment="env"></property> <!----> <echo message="Workspace: ${env.WORKSPACE}"></echo> <!----> <delete></delete> <!----> <mkdir></mkdir> |
可以现在下载完整的 Ant 构建文件 ar-autotaskcode.zip。
在包含 Ant 构建项目的同一个目录中创建属性文件来存储其属性。ar-autotaskcode.zip 中也提供了完整的属性文件。
现在 Ant 构建文件已经准备好开始添加表示自动化过程的新 Ant 目标了。
|
图 2 显示了构建自动化程序的摘要。
此部分将对这个过程的每个步骤进行详细描述。
第一步是从 ClearCase 存储库获得最新的代码,如清单 2 中所示。
<target description="Update ClearCase snapshot view" name="updateview" depends="init"></target> <!----> <ccupdate overwrite="true" graphical="false" viewpath="${workspace.dir}"></ccupdate> currenttime="true" /> |
由于工作区配置为指向 ClearCase 视图,更新视图实际上将更新工作区内容。
可以实现代码检查自动化。尽管不能消除手动代码检查需求,但建议的最佳实践是,采用自动化检查来确定开发团队在代码质量标准方面所处的位置。Rational SDP 提供了内置的代码检查支持。(有关如何从 Ant 进行调用的更多信息,请参见 Code review headless mode reference。)
另外还可以使用多种工具来执行自动化代码检查,如 PMD 和 CheckStyle。清单 3 中的示例说明了如何将 PMD 作为 Ant 任务调用并生成 HTML 格式的结果。要运行此任务,需要将 pmd-3.8.jar、jakarta-oro-2.0.8.jar 和 jaxen-1.1-beta-10.jar 放置在 lib.dir 属性所指定的目录。
<target description="Review code using PMD" name="reviewcode"></target> <taskdef name="pmd" classpath="${lib.dir}/pmd-3.8.jar" classname="net.sourceforge.pmd.ant.PMDTask"></taskdef> <pmd shortfilenames="true"></pmd> <!----> <ruleset></ruleset>rulesets/favorites.xml <ruleset></ruleset>basic <!----> <formatter tofile="${report.dir}/pmd_automated_code_review_report.html" type="html"></formatter> <!----> <fileset></fileset> <!----> <include name="**/*.java"></include> <!----> <exclude name="**/generated/**/*.java"></exclude> |
执行了此步骤后,将在 report.dir 属性指定的目录下找到 HTML 格式的 pmd_automated_code_review_report.html。(有关自动化代码检查的更多信息,请参见参考资料部分。)
现在我们使用 IDE 中提供的内置功能来构建要包括在构建版本中的不同项目。
对于要在 IDE 中运行的 SDP 提供的 Ant 任务,Ant 构建文件需要在与工作区相同的 Java™ Runtime Environment (JRE) 中运行。否则,如果从命令行运行,runAnt 批处理文件将进行所需的初始化工作,以将这些任务的定义包括进来。这将在运行过程时的选项部分进行讨论。清单 4 中的代码使用 IDE 内置的“projectBuild”Ant 任务构建存在于工作区中的项目之一。
<target description="Build a project" name="buildproject"></target> <!----> <projectbuild debugcompilation="false" failonerror="false" buildtype="full" projectname="${project.name}"></projectbuild> <!----> <echo message="projectBuild: projectName=${project.name} project Error Count=${ProjectErrorCount} project Error Messages=${ProjectErrorMessages}"></echo> |
执行时可能出现的错误会输出到控制台,但构建不会终止。要更改此行为,可以将 failonerror
属性设置为 true
。
可以通过将 project.name
属性设置为要构建的项目的名称而为不同的项目使用相同的目标,如清单 5 中所示。
<target name="buildall"></target> <!----> <antcall target="buildproject"></antcall> <!----> <!----> <antcall target="buildproject"></antcall> <!----> |
有时候会忽略此步骤。为所发布的每个构建版本使用一个版本号的方法对跟踪缺陷和新添加的功能非常有用。Ant 提供了一个简单 buildnumber 任务,可实现此目的。清单 6 显示了根据需要记录更多有关版本信息的另一种方法。
<target description="Record build information" name="baseline"></target> <!----> <propertyfile file="${destination.dir}/build.info"></propertyfile> <!----> <entry default="0001" type="int" pattern="0000" operation="+" key="build.number"></entry> <!----> <entry default="now" type="date" pattern="yyyy.MM.dd-HH.mm" key="build.time"></entry> |
"baseline"
目标创建名为 build.info 的文件,其中包含版本号和构建时间。如果该文件已存在,则会使用新版本号和构建时间对其进行更新。您可能需要在此文件中添加更多信息,如运行构建操作的用户的名称或创建构建版本的计算机的名称。还可以按照提取 "init"
目标中 WORKSPACE
环境变量的相同方法从环境提取此信息,如 Ant 构建文件中所述。
此步骤调用 JUnit 测试用例,这些用例不需要运行时资源(如数据源等)。我们假定您已经获得了运行此步骤所需的此类测试用例。清单 7 说明了如何在工作区调用所有 JUnite 测试用例,并假设全部都以单词“Test”作为结尾。当然,如果命名约定不同,则可以对此进行相应的更改。
<target description="Invoke pre-deployment JUnit test cases" name="predeptests"></target> <!----> <junit haltonfailure="no" printsummary="yes"></junit> <classpath></classpath> <!----> <!----> <formatter type="xml"></formatter> <!----> <batchtest todir="${report.dir}" fork="yes"></batchtest> <fileset></fileset> <!----> <include name="**/*Test.java"></include> |
JUnit Ant 任务需要 junit.jar。可以将其放在 "init"
目标中提到的 Ant 构建项目的属性文件的 lib.dir 属性指定的目录下。可以使用 JUnitReport Ant 任务将 JUnit 任务生成的报告转换为其他格式。在我们的示例中,报告将在 report.dir 属性指定的目录中生成。
在此步骤中,我们要对可部署单元进行打包,以准备好在下一步中进行部署。清单 8 显示了如何导出企业应用程序。
<target description="Export an Enterprise Application" name="exportear"></target> <!----> <earexport earprojectname="${project.name}"></earexport> earexportfile="${destination.dir}/${project.name}.ear" exportsource="false" IncludeProjectMetaFiles="false" |
与步骤 3(构建代码)期间处理一组项目的方式类似,我们可以在导出企业应用程序时采用相同的方式。清单 9 中的代码说明了如何进行此工作。
<target name="exportall" depends="buildall"></target> description="Export a set of Enterprise Applications"> <!----> <antcall target="exportear"></antcall> <!----> <!----> <antcall target="exportear"></antcall> <!----> |
对于其他项目类型,可以使用 warExport
、ejbExport
和 jar
任务(分别用于导出 Web 模块、EnterpriseJavaBeans (EJB) 模块和 Java 库)。这些都是 SDP 提供的 Ant 任务。
在此步骤中,我们将部署上一步导出的单元。对于我们的自动化过程,我们将使用包装 wsadmin
的内置 Ant 任务。清单 10 显示了 wsListApps
、wsUninstallApp
和 wsInstallApp
Ant 任务,这些任务分别提供用于列出已安装应用程序、卸载企业应用程序和安装企业应用程序的管理功能。请记得在运行此步骤前启动目标应用服务器。
关于 wsadmin 和 Ant
WebSphere Application Server Ant 支持基于其命令行管理工具 wsadmin
。作为本文示例的替代方法,可以使用 Exec Ant 任务调用 wsadmin
并按照调用任何其他库执行文件的方式传递程序参数。WebSphere Application Server 还提供了包装 wsadmin
的 Ant 任务 WsAdmin。还有其他包装特定操作的 WsAdmin 任务的 Ant 任务,如应用程序安装方面的 InstallApplication 和 StartApplication。我们的示例中使用了后一个选项。
<target description="List installed Enterprise Applications" name="listapps"></target> <!----> <taskdef name="wsListApps" classname="com.ibm.websphere.ant.tasks.ListApplications"></taskdef> <!----> <classpath></classpath> <fileset includes="*.jar"></fileset> <!----> <wslistapps password="${was.userpassword}" user="${was.username}" port="${was.hostport}" host="${was.hostname}" conntype="SOAP" washome="${was.home}/" profilename="${was.profilename}"></wslistapps> <target name="uninstallapp" depends="listapps"></target> description="Uninstall an Enterprise Application"> <!----> <taskdef name="wsUninstallApp"></taskdef> classname="com.ibm.websphere.ant.tasks.UninstallApplication"> <!----> <classpath></classpath> <fileset includes="*.jar"></fileset> <!----> <wsuninstallapp host="${was.hostname}" conntype="SOAP" washome="${was.home}/" profilename="${was.profilename}" application="${project.name}"></wsuninstallapp> port="${was.hostport}" user="${was.username}" password="${was.userpassword}" |
根据需要部署的应用程序的数量不同,可以使用 project.name 参数的不同值多次调用 installapp
目标。installapp
目标将调用 uninstallapp
目标来确保企业应用程序已经卸载(如果已安装)。两个目标多次调用 listapps
,以在卸载和安装前后列出应用程序。清单 11 说明了如何进行此工作。
<target description="Install all Enterprise Applications" name="installallapps"></target> <!----> <antcall target="installapp"></antcall> <!----> <!----> |
此步骤与运行部署前单元测试类似,不过 JUnit 测试用例的本质不同。部署后测试用例预期使用已经部署在运行时上且正在正常工作的代码。这些测试用例可以利用服务器端的资源和测试组件,如 Cactus。就构建自动化过程而言,此步骤只是调用一组 JUnit 测试用例。
设置了所有构建版本后,自动化过程会将库部署单元和生成的报告上载到 FTP 服务器上。此步骤对于备份和保持整个构建版本的标识都非常有用。清单 12 中所示的目标说明了如何使用 FTP 来上载构建文件。
<target description="Upload build to an FTP server" name="uploadbuild"></target> <!----> <ftp password="${ftp.userpassword}" binary="yes" verbose="yes" separator="\" userid="${ftp.username}" remotedir="/" server="${ftp.hostname}"></ftp> <fileset></fileset> <include name="**/*.*"></include> |
最后,该过程将向测试人员发送电子邮件(如清单 13中所示),告知其开始测试。以下示例假定不会在 SMTP 服务器上进行身份验证。
<target description="Notify testing team of the new build" name="notifyteam"></target> <!----> <property file="${destination.dir}/build.info"></property> <!----> <mail mailport="${smtp.hostport}" mailhost="${smtp.hostname}"></mail> subject="Test build #${build.number}" from="${smtp.from}" tolist="${smtp.tolist}"> <message></message>The build #${build.number} is now available for testing. |
如果您的 SMTP 服务器要求进行身份验证,将需要下载 JavaMail .jar 文件。
|
本部分将简单描述运行构建过程时一些可用的选项。
上面所述的自动化过程并不施加任何控制任务流的条件。如果需要此类控制,可以使用允许某些任务中在出现错误时失败的属性。例如,wsInstallApp
任务具有用于此目的的 failonerror
属性。
使用条件是控制流的另一种方式。有关 Ant 中的条件的更多信息,请参见 Conditions task。Ant 还提供了依赖关系来在目标之间建立联系,以确保执行目标序列得以执行。
从 IDE 运行 Ant 构建文件非常简单。如图 3 中所示,可以从 Ant 视图中选择出现在树视图下的 Ant 目标之一上的 Run Ant 选项。
在 Modify attributes and launch 对话框中,从 JRE 选项卡选择 Run in the same JRE as the workspace,如图 4 中所示。单击 Apply 和 Run。
执行之后,输出将打印到 Console 视图,如图 5 中所示。
<ide directory="" installation=""></ide>\rwd\eclipse\plugins\com.ibm.etools.j2ee.ant_6.0.1.XXX 下提供了有关自定义 Ant 来使用 Rational SDP 资源从命令行运行的信息。该目录下提供了一个批处理文件 runAnt,可允许运行您的 Ant 构建文件。此批处理文件需要设置 WORKSPACE
环境变量。此变量指向包含自动化资源的工作区。可以从命令行设置此变量,或者添加代码行来指向 runAnt 批处理文件,如清单 14 中所示。
set WORKSPACE=C:\workspaces\MyWorkSpace runAnt.bat -buildfile \build.xml init |
可以不使用前一示例中的 init
目标,而以类似的方式调用 Ant 构建文件中的其他目标。
由于此构建过程已自动化,开发团队可能会决定每天都要执行此过程,具体取决于其需要提供构建版本进行测试的频率。此执行可以为部分执行(运行 Ant 目标的子集),也可以完全执行。在这两种情况下,可以对过程进行计划,以按所需的频率运行。有关如何在 Windows 平台上进行任务计划的更多信息,请参见“使用 WebSphere Studio 和 Ant 执行无人值守的日常构建——第 2 部分”。
|
学习本文后,希望您已经通过使用实现软件开发团队的重复构建任务的自动化的过程提高了效率和质量。所使用的构建自动化过程仅仅是 Rational and WebSphere 系列软件产品提供的自动化功能的一个子集。您将需要对此过程进行调整,以与工作环境、所使用的工具和运行时、团队的知识以及所开发的解决方案类型匹配。
作者要感谢 Nouran Abdel-Hamid、Rosaline Makar、Amr Ali 和 Ahmed Mamdouh:正是得益于您们的工作,才最终得到了这个自动化解决方案。
|
ar-autotaskcode.zip | 3KB | HTTP |
关于下载方法的信息 |
学习
获得产品和技术