本系列文章介绍了两种用于集成IBM Rational Team Concert™和IBM®UrbanCode Deploy来创建连续交付过程的机制。 本文包含的第一种方法( 第1部分 )是一种易于设置的打包即用型实现。 第二种方法,在第2部分和第3部分中介绍 ,使用对Ant build.xml文件的扩展。
注意事项 :
使用Ant构建过程并不仅限于构建Java应用程序。 Rational Team Concert用户使用了Ant构建过程,并在构建过程中使用了Rational Team Concert扩展来构建其他语言(例如C和ADA)的应用程序。
示例应用
本文中以Rational Team Concert随附的JKE Banking示例项目为例。 这样,您可以根据需要快速创建应用程序代码,然后应用本文中的更改来创建完整的解决方案。 或者,您可以扩展自己的build.xml文件,其中包含下载文件中的附加内容。
注意事项 :
不建议在生产Rational Team Concert环境中创建样本项目,因为该项目会创建大多数人不希望在其生产系统中使用的许多用户。 建议在测试Rational Team Concert服务器中创建样本项目。
构建定义
构建定义在JKE Banking示例项目(jke.dev)中。 本文中使用的构建定义名为jke.dev.build_and_deploy 。 在以下各节中突出显示了要对构建定义进行的更改。
注意事项 :
因为您要对此构建定义进行更改,所以最好复制一份并保留原始版本。
Build.xml
build.xml文件是一个文本文件,指示Ant构建过程执行哪些操作来执行构建过程。 与示例项目一起提供的,它包含了对Ant的说明:
- 建立一个jar文件
- 建立战争档案
- 将war文件压缩为zip文件。
然后将zip文件作为构建的工件存储在Rational Team Concert中的构建记录中。 Ant执行的操作的日志文件也存储为构建工件。 原始build.xml文件也作为build-Original.xml包含在zip文件中。
构建扩展以实现持续交付
阶段1.构建安全性
在对标准build.xml流程进行扩展的第一阶段中,对Ant流程用来连接到Rational Team Concert生成流程的密码的管理进行了更改。 还添加了许多其他属性来支持构建过程的后续阶段。
Rational Team Concert的样本JKE银行项目随附的标准build.xml文件包括构建用户标识和密码的详细信息。 这些作为属性显示,并在清单1中显示。
清单1.用户标识和密码
<property name="userId" value="build" />
<property name="password" value="build" />
构建和自动化系统的许多用户不希望密码在build.xml文件中可见。 对于那些人,您可以用对包含加密密码的文件的引用替换清单1中的代码,如清单2所示。
清单2.加密的密码
<property name="userId" value="build" /> <property name="passwordFile"
value="${basedir}/EncryptedBuildUserPassword.txt"/>
包含加密密码的文件与build.xml文件存储在同一目录中。 在build.xml文件中使用变量${basedir}
引用。 假设build.xml文件位于Rational Team Concert构建过程从中加载内容的两个目录下(如图1所示),那么存储一个标识已加载内容的“根”的变量可能会很有用。 : <property name="loadDir" value="${basedir}/../.." />
。
您可以将属性loadDir用作参考点,以引用由Rational Team Concert构建过程管理的已加载内容中的任何文件。
图1.项目目录结构中的build.xml文件
在[Rational Team Concert构建安装位置]> buildsystem> buildengine> eclipse目录中找到的jbe可执行程序将创建加密密码。 自述文件位于buildsystem目录中。 该文件详细说明了如何使用JBE程序创建密码文件。
为了完成安全性增强,所有对密码的引用都将替换为对密码文件的引用。 用password="${password}"
替换passwordFile="${passwordFile}".
要添加的第二部分在文件开头附近包含许多新的属性定义。 将属性添加到build.xml文件中,以为随后的许多命令标识工作目录。 待生成的目标战文件也由参数标识。
将清单3中所示的代码行添加到build.xml文件中,该属性位于定义其他目标目录的其他属性定义下面。
清单3.添加到build.xml文件的属性
<property name="destdir.war" value="${loadDir}/build/war" />
<property name="workingDir" value="${basedir}" />
<property name="target.war" value="jke.war" />
来自Rational Team Concert的Ant构建扩展任务
要使用Rational Team Concert随附的Ant任务,需要完成两项任务。 第一个任务是在Ant库路径上包括Jazz Build Toolkit任务的位置。 为此,请选中复选框,以将Jazz构建工具包任务包括在Ant库路径中,如图2所示。您将在Rational Team Concert构建定义的Ant选项卡上找到此选项。
图2.在构建定义中引用Jazz构建工具包
第二件事是将任务定义添加到Ant build.xml文件中。 清单4显示了开始构建活动任务的任务定义示例。
注意事项 :
所有必需的任务定义都已经在示例build.xml文件中,该文件用作该工作的起点。 仅当用户使用本文介绍的步骤扩展现有的build.xml文件时,才需要手动添加任务定义条目。 如果是这种情况,那么只需从本文底部的下载文件链接中提供的build.xml文件中复制任务定义块即可。
清单4.启动构建活动功能的示例任务定义。
<taskdef name="startBuildActivity"
classname="com.ibm.team.build.ant.task.StartBuildActivityTask" />
构建定义,构建结果和相关工件如图3所示。显示了三个构建,并使用日期和时间构建标签对其进行标识。
-
构建日志文件
-
构建期间生成的文本日志文件。
在本文档中创建的扩展名中,产生了许多新的日志文件以帮助调试。
快照
-
在构建时会获取Team Concert源代码管理工具中保留的源内容的快照。
内置神器
-
构建中生成的war文件存储在构建记录中。
注意:
如果您具有生成许多大对象的构建过程,则可能需要将文件复制到特定的网络共享,然后在构建结果中发布指向工件的链接。
包括最近交付并由构建结果引用的工作项列表。 这有助于显示软件开发生命周期不同元素之间的可追溯性,如图3所示。
图3.构建产生的内容的层次结构
扩展构建记录中可用的信息,图4显示了与任务关联的变更集的详细信息。 生成此链接数据的操作顺序为:
- 开发人员被分配了Rational Team Concert任务编号1239。
- 开发人员开始从事该活动,并修改(或创建)三个Java源代码文件和一个项目build.xml文件。
- 四个文件更改被分组为一个更改集 ,然后与开发人员的任务相关联。
- 然后,该任务将交付给开发人员正在使用的共享工作流。
- 计划的构建过程在交付后不久开始,并将新交付的变更集标识为自上次构建以来的新变更。 该任务将添加到构建记录中的工作项列表中。
图4.扩展的构建构件的层次结构– 1
图5进一步扩展了该图像,以显示从开发人员的任务到软件开发生命周期其他区域的可追溯性,包括:
- 任务源自的故事
- 讲故事的要求
- 与故事关联的测试用例。
图5还显示了执行被认为已失败并且已创建缺陷的测试的结果。 浅色线自动显示从缺陷到故事,需求和测试用例的链接。 最后,显示了一个与缺陷相关联的变更集,该变更集表明缺陷已得到修复并且指定的文件已被修改。 因此,缺陷还将显示在下一个构建记录中。
图5:扩展构建工件的层次结构-2
阶段1.摘要
在第一阶段中,对构建过程的安全性进行了简单的更改,并添加了许多属性。 第一阶段还探索了整个开发生命周期中的广泛可追溯性,这在Rational Team Concert和相关产品中可用。
阶段2.将WAR文件加载到UrbanCode Deploy CodeStation中
在build.xml扩展的此阶段,命令行客户端连接到UrbanCode Deploy,并将生成的WAR文件加载到UrbanCode Deploy产品(称为CodeStation)的版本存储区中。
注意事项 :
CodeStation不是单独的产品,它只是UrbanCode Deploy中提供的版本存储区域的名称。
每个UrbanCode Deploy组件可以存储要部署到目标的文件的多个版本。 您可以选择不同的版本以部署到不同的环境中,并通过一系列环境在生产过程中执行不同的测试和验证活动来扩展组件的版本。 图6显示了将WAR文件加载到UrbanCode Deploy中的结果。
图6.将构建的内容加载到UrbanCode Deploy
物产
将构建过程中使用的属性存储为build.xml文件顶部的一系列定义非常有用。 如果需要更改属性(如果您想在自己的环境中使用文件并使用它们,则可以将它们组合在一起)。 它将使更改更加容易。
清单5中显示的属性建立了与UrbanCode Deploy服务器的连接,并标识了要在其中创建新版本的组件。 认证令牌的使用避免了将纯文本密码存储在build.xml文件中的必要性。 UrbanCode部署的服务器名称和身份验证令牌都应特定于您的环境。
清单5.属性
<!-- UrbanCode Deploy Connection Properties -->
<property name="Deploy_WebURL" value="https://rational-srv-02:8443" />
<property name="Deploy_AuthToken" value="6b29ed7f-956b-46ed-97ac-f3cbd4e6e876" />
<property name="Deploy_Component" value="Sample Component" />
清单6中的属性使UrbanCode Deploy组件版本能够存储对Rational Team Concert构建记录的引用。
清单6.存储对构建记录的引用
<!-- RTC information for UrbanCode to use to create a link to the RTC build record -->
<property name="Deploy_Component_Version_Backlink" value = "Team Concert Build Record" />
<property name="CCM_URL" value="https://rational-srv-02:9443/ccm" />
<property name="BackLink_Base_URL"
value="${CCM_URL}/web/projects/…#action=com.ibm.team.build.viewResult&id=" />
负责部署活动的人员可以快速找到适当的构建记录,然后轻松地找到为该构建交付的工作项。 如果已经使用了Rational产品集的需求和测试管理功能,那么可以在需求和测试用例上跟随更多的可跟踪性链接。
注意:
清单6中缩短了最后一项的值。要找出您的站点的构建记录URL是什么,Rational Team Concert项目将构建记录加载到Web浏览器中,并将URL从项目名称复制到包括&id = 。 &id =后面的内部版本ID被添加为本文第4阶段中描述的URL构建过程的一部分。
注意:
&amp; 在清单6所示的URL中使用。
清单7是一个日志文件,用于收集有关组件版本创建过程的信息。 如果发生任何错误,则此文件是调试信息的有用来源。
清单7.收集信息的日志文件
<!-- Log files used by the connectivity to UrbanCode Deploy -->
<property name="DeployComponentVersionCreate"
value="${workingDir}/DeployComponentVersionCreate.log" />
部署构建目标
新的目标将添加到build.xml文件中,以包含与UrbanCode Deploy交互的任务。 这使您可以选择何时运行部署交互操作,并允许继续进行编译和单元测试活动的快速周转,而不必与UrbanCode Deploy进行交互。
清单8中的build.xml行包含要添加的目标。
清单8.添加一个目标
<target name="deploy" depends="compile">
</target>
新目标取决于编译过程,该过程要求先生成一个新的WAR文件,然后再尝试将其添加到UrbanCode Deploy中的新组件版本中。
为了在每次构建运行时执行部署操作,必须在主构建目标上包括Deploy目标,如清单9所示。
清单9.部署目标
<target name="all"
depends="compile, deploy" />
UrbanCode Deploy命令行界面
在完成下一步之前,必须先安装UrbanCode Deploy命令行界面。 这非常容易做到,可以从UrbanCode Deploy Web界面右侧的工具菜单中下载。 将zip文件解压缩到构建服务器上的某个位置,然后将该位置添加到构建服务器的路径中。 从新的命令窗口停止并重新启动正在运行的构建引擎。 如果不停止并重新启动,则构建引擎进程将无法访问UrbanCode命令行界面。
UrbanCode Deploy登录
部署目标的第一步是登录UrbanCode Deploy。 这是将udclient命令行界面与login参数以及用于身份验证令牌和要连接的url的子参数一起使用的第一个实例。 两者均取自先前定义的属性。 清单10显示了要登录的build.xml命令。
清单10.登录命令
<exec executable="cmd" dir="${workingDir}">
<arg value="/c"/>
<arg value="udclient"/>
<arg value="login" />
<arg value="-authtoken"/>
<arg value="${Deploy_AuthToken}"/>
<arg value="-weburl"/>
<arg value="${Deploy_WebURL}"/>
</exec>
使用StartBuildActivity报告构建进度
StartBuildActivity构建命令是本文许多操作的第一部分。 它向正在观看Eclipse或Web界面中的构建的用户报告正在执行的命令。 它还在构建记录中记录了构建的阶段。 构建记录位于Rational Team Concert数据库中。 图7显示了Eclipse用户界面的构建进度报告的示例。
图7.报告构建阶段进度
StartBuildActivity语句的label字段包含对文件开头属性部分中定义的组件名称的引用。
清单11. StartBuildActivity
<startBuildActivity activityIdProperty="CreateDeployComponentVersion"
label="Create new component version - ${Deploy_Component}"
buildResultUUID="${buildResultUUID}"
repositoryAddress="${repositoryAddress}"
userId="${userId}" passwordFile="${passwordFile}"
autoComplete="true" />
在UrbanCode Deploy中创建组件版本
登录完成后,下一步是在UrbanCode Deploy中创建组件的新版本。 创建新版本后,它最初没有存储的内容,因为此后必须将其作为单独的步骤添加。 该命令的第一个参数与login命令相同,然后给出其他选项,其中包括createVersion选项,组件标识符和要创建的新版本的名称。 由${buildLabel}
给出的版本名称由Rational Team Concert构建过程传递给ant执行。 默认情况下,构建标签是日期和时间。
清单12.参数选项
<exec executable="cmd" dir="${workingDir}"
output="${DeployComponentVersionCreate}" >
<arg value="/c"/>
<arg value="udclient"/>
<arg value="-authtoken"/>
<arg value="${Deploy_AuthToken}"/>
<arg value="-weburl"/>
<arg value="${Deploy_WebURL}"/>
<arg value="createVersion"/>
<arg value="-component"/>
<arg value=""${Deploy_Component}""/>
<arg value="-name"/>
<arg value="${buildLabel}"/>
</exec>
版本创建过程中的最后一个命令是存储清单12中所示的createVersion命令的执行所生成的日志文件的存储。输出参数引用先前在build.xml文件中定义的参数,该参数是目录中保存的文件构建机器的结构。 使用清单11中所示的命令将日志文件发布到Rational Team Concert构建记录中。日志文件的文本描述包含组件名称,因此对于具有许多组件的客户而言,在较大的构建中,将有可能确定哪个日志是与哪个组件相关联。
清单13.日志文件存储
<logPublisher filePath="${DeployComponentVersionCreate}"
label="Create new component version - ${Deploy_Component} / ${buildLabel}"
buildResultUUID="${buildResultUUID}" repositoryAddress="${repositoryAddress}"
userId="${userId}" passwordFile="${passwordFile}" verbose="true"/>
将内容添加到新的组件版本
在UrbanCode Deploy中创建组件版本之后,有必要将可部署的内容加载到版本参考中。 版本内容创建的第一部分是使用StartBuildActivity构建命令。
版本内容创建的第二部分是使用udclient命令将新内容加载到UrbanCode Deploy中的组件版本中。 该命令的第一个参数与login命令相同。 还包括addVersionFiles命令,组件的标识符以及要加载的文件的位置。
清单14.更新版本参考
<startBuildActivity activityIdProperty="AddDeployComponentVersion"
label="Add component version to CodeStation - ${Deploy_Component}"
buildResultUUID="${buildResultUUID}" repositoryAddress="${repositoryAddress}"
userId="${userId}" passwordFile="${passwordFile}" autoComplete="true" />
<exec executable="cmd" dir="${workingDir}" >
<arg value="/c"/>
<arg value="udclient"/>
<arg value="-authtoken"/>
<arg value="${Deploy_AuthToken}"/>
<arg value="-weburl"/>
<arg value="${Deploy_WebURL}"/>
<arg Value="addVersionFiles"/>
<arg Value="-component"/>
<arg Value=""${Deploy_Component}""/>
<arg Value="-version"/>
<arg Value="${buildLabel}"/>
<arg Value="-base"/>
<arg Value="${destdir.distro}"/>
<arg Value="-include"/>
<arg Value="${target.war}"/>
</exec>
第二阶段。总结
在第二阶段之后,持续的交付过程将Rational Team Concert构建中的内容作为包含新构建的war文件的新组件版本推送到UrbanCode Deploy中。
阶段3.在RTC构建记录上创建指向组件版本的链接
由于这项工作的目的是创建从开发团队到部署环境的无缝信息流,因此创建从Team Concert构建记录到新创建的组件版本的链接非常有用。 这使开发人员可以轻松查看可部署的内容,并从那里查看已将其部署到哪些环境中。
链接的格式为: https://<UrbanCode server name>:<UrbanCode secure port>/#version/<component version ID>
下一部分的目的是获取组件版本ID,构造URL并将其存储在Team Concert构建记录中。
获取组件版本号
可以从上面显示的createVersion命令的JSON格式输出结果中提取组件版本ID。 为此,从构建脚本中执行Java应用程序以处理createVersion命令的输出并提取ID。 该Java应用程序以源代码格式与文章的其他文件一起提供(文件getJSONPropertyValue.zip)。 它包括一个build.xml文件,使您可以构建它。 您可以通过在Rational Team Concert中创建构建定义来构建可执行文件。 构建完成后,将生成的jar文件添加到目录: JKEBuildScripts \ sample.jke.build \ Support \ get-JSON-property-value.jar
然后将其传递到流中。 进行更改后,按照与交付build.xml文件相同的步骤进行操作。
为了从build.xml文件中执行应用程序,许多附加属性被添加到build.xml文件顶部的现有属性部分。 清单15显示了要添加的属性。
清单15.其他属性
<!-- Properties for a JSON processing application that will extract the component version ID -->
<property name="getJSONPropertyValue"
value="${workingDir}/Support/get-JSON-property-value.jar"/>
<property name="getJSONPropertyValue-Log" value="${workingDir}/getJSONPropertyValuelog.txt"/>
<property name="DeployComponentVersionCreationIDFile"
value="${workingDir}/DeployComponentVersionCreationIDFile.txt"/>
<property name="VersionCreationJSONTitle" value="id"/>
在第2阶段添加的命令下,将路径部分添加到Deploy目标中。这使Java执行程序可以找到已编译的jar文件。
清单16.添加路径部分
<path id="getJSONPropertyValuePaths">
<pathelement path="."/>
<pathelement path="${getJSONPropertyValue}" />
</path>
然后执行java命令以处理来自createVersion命令的数据。 该命令的参数为:
- 输入文件 :从上面的createVersion命令生成的输出文件。
- Title :要为其提取值的JSON格式标题。
- 输出文件 :要创建的文件名。 该文件包含提取的数据。
输入文件的示例如下所示。 所需信息是id字段。
清单17.输入文件
{
"id": "1044c181-b77c-4468-b1e8-0fc72cc370e0",
"name": "I20140506-2120",
"type": "FULL",
"created": 1399407705637,
"active": true,
"archived": false
}
清单18显示了使用所需属性执行Java应用程序所需的xml部分。
清单18.具有必需属性的XML
<java jar="${getJSONPropertyValue}" output="${getJSONPropertyValue-Log}" fork="true">
<classpath refid="getJSONPropertyValuePaths" />
<arg value="inputFile=${DeployComponentVersionCreate}" />
<arg value="Title=${VersionCreationJSONTitle}" />
<arg value="outputFile=${DeployComponentVersionCreationIDFile}" />
</java>
命令运行后,将创建输出文件。 输出文件包含组件版本ID: 1044c181-b77c-4468-b1e8-0fc72cc370e0.
下一步是读取文件内容,并将ID转换为属性值,以便可以在以后的步骤中使用它。 清单19中显示了将文件加载到属性中的命令。它还包括echo命令,以便在构建日志文件中显示ID。
清单19.加载文件命令
<loadfile property="DeployComponentVersionCreationID"
srcFile="${DeployComponentVersionCreationIDFile}"/>
<echo message="ID of Component version =${DeployComponentVersionCreationID}" />
在构建记录中发布指向组件版本的链接
使用Rational Team Concert 链接发布器命令发布由标头URL构造的URL,该URL定义为文件顶部的属性,并具有在上述步骤中从文件中提取的ID。 将标头URL属性需要添加到build.xml文件,如清单20所示。
清单20.标头URL属性
<property name="DeployVersionLinkHeader" value="${Deploy_WebURL}/#version/"/>
清单21.发布链接
<!-- Publish Link to Deploy Component Version on RTC Build Result -->
<linkPublisher label="UrbanCode Deploy Component - ${Deploy_Component}"
url="${DeployVersionLinkHeader}${DeployComponentVersionCreationID}"
componentName="Component Versions" buildResultUUID="${buildResultUUID}"
repositoryAddress="${repositoryAddress}" userId="${userId}"
passwordFile="${passwordFile}" failOnError="false" />
阶段3.摘要
在第三阶段之后,持续的交付过程可以将Rational Team Concert构建中的内容推送到UrbanCode Deploy中。 从构建记录到组件版本的链接也被建立。
阶段4.在组件版本上创建指向构建记录的链接
除了在阶段3中创建的链接之外,创建从组件版本到Rational Team Concert中的构建记录的链接也很有用。 这使主要负责部署的人员可以轻松找到包含在用于创建他们正在使用的组件版本的构建中的Rational Team Concert工作项。 然后,您可以从工作项中跟随其他可追溯性链接到测试用例和需求,如图5所示。
物产
清单22中所示的exec命令上方添加了一个新属性,用于从先前在build.xml文件中定义的值生成构建反向链接URL。
清单22.添加一个新属性
<property name = "Build_Backlink" value = "${BackLink_Base_URL}${buildResultUUID}" />
清单23中显示了build.xml文件中用于创建和发布链接的命令。
清单23.创建和发布链接
<exec executable="cmd">
<arg value="/c"/>
<arg value="udclient"/>
<arg value="-authtoken"/>
<arg value="${Deploy_AuthToken}"/>
<arg value="-weburl"/>
<arg value="${Deploy_WebURL}"/>
<arg value="addVersionLink"/>
<arg value="-component"/>
<arg value=""${Deploy_Component}""/>
<arg value="-version"/>
<arg value="${buildLabel}"/>
<arg value="-linkName"/>
<arg value=""${Deploy_Component_Version_Backlink}""/>
<arg value="-link"/>
<arg value=""${Build_Backlink}""/>
</exec>
在阶段3中创建的链接的结果如图8所示。
图8. UrbanCode Deploy和Rational Team Concert之间的链接
阶段4.摘要
在阶段4中,您指示了持续交付过程,以将内容从Rational Team Concert构建推送到UrbanCode Deploy,并创建从组件版本到构建记录的链接。
摘要
本文介绍了连续交付过程的第一部分,如果您具有复杂的构建过程来生成要放入多个UrbanCode组件中的内容,则此过程是适当的。 本系列的最后一篇文章向您展示如何启动部署以完成连续交付过程。