本系列文章介绍了两种集成IBM（R）Rational Team Concert（TM）和IBM（R）UrbanCode Deploy来创建连续交付过程的机制。 第1部分向您展示了易于设置的打包即用型实现。 第2部分和第3 部分中介绍的第二种方法使用对Ant build.xml文件的扩展。
从构建过程开始部署
阶段5.开始部署
UrbanCode部署的启动可能需要提供大量有关要使用的部署过程，要接收部署的环境以及所部署组件的版本的数据。 结果， udclient命令行功能接收到一个JSON格式的文件，其中包含执行部署所需的信息。
要查看所需的JSON数据格式，请使用–t选项运行部署请求命令行，如清单1所示。
清单1.部署请求命令-t
udclient -weburl https://rational-srv-02:8443 -authtoken <my-auth-token> requestApplicationProcess –t
运行命令后显示的结果是要提供的JSON数据的格式。
物产
清单2显示了其他必需的属性。 将这些属性添加到build.xml文件的顶部。 为应用程序，环境和环境的流程设置特定的值。
清单2.支持部署操作的新属性
<property name="Deploy_DeploymentJSONFile" value="Deploy_application_deploy.JSON" />
<property name="Deploy_ApplicationName" value="Deploy Sample Application" />
<property name="Deploy_ApplicationProcess" value="Deploy to Tomcat" />
<property name="Deploy_Environment" value="Development" />
<property name="DeployDeploymentLog" value="${workingDir}/DeployDeploymentLog.log" />
<property name="DeployRequestIDFile" value="${workingDir}/DeployRequestIDFile.txt"/>
<property name="DeploymentRequestJSONTitle" value="requestId"/>
部署请求：步骤1
使用清单3中所示的StartBuildActivity构建命令作为创建部署请求的第一步。
清单3. StartBuildActivity构建命令
<startBuildActivity activityIdProperty="Deploy" label="Deploy objects with Deploy"
autoComplete="true" buildResultUUID="${buildResultUUID}"
repositoryAddress="${repositoryAddress}"
userId="${userId}" passwordFile="${passwordFile}" />
部署请求：步骤2
使用echo命令将所需内容写入JSON文件。
注意： 如果使用多个组件，则还应使用清单4所示的JSON内容部分中的versions元素的重复块在此处添加其名称和版本标识符。
清单4. JSON文件创建过程
<echo file="${workingDir}/${Deploy_DeploymentJSONFile}" append="false">{
"application": ${Deploy_ApplicationName},
"applicationProcess": ${Deploy_ApplicationProcess},
"environment": ${Deploy_Environment},
"versions": [
{
"version": ${buildLabel},
"component": "${Deploy_Component}",
}
],
}
</echo>
部署请求：步骤3
第三步， udclient命令运行部署。 该命令的第一个参数与login命令相同。 清单5中显示了其他参数。这些参数包括requestApplicationProcess命令和JSON文件的标识符。
清单5.部署请求构建命令
<exec executable="cmd" dir="${workingDir}" output="${DeployDeploymentLog}">
<arg value="/c"/>
<arg value="udclient"/>
<arg value="-authtoken"/>
<arg value="${Deploy_AuthToken}"/>
<arg value="-weburl"/>
<arg value="${Deploy_WebURL}"/>
<arg value="requestApplicationProcess"/>
<arg value="${Deploy_DeploymentJSONFile}"/>
</exec>
如清单6所示，部署请求的ID在执行部署产生的输出文件中。
清单6. UrbanCode的部署请求响应
{
"requestId": "6e0d5a7d-d371-4665-8cc5-f99cb4b11856"
}
获取部署请求ID
您可以像以前提取组件版本ID一样，从requestApplicationProcess命令的JSON格式输出结果中提取部署请求ID（如清单6所示）。 在构建脚本中调用了文章2的第3阶段中使用的Java应用程序，以处理requestApplicationProcess命令的输出并提取ID。
清单7显示了使用所需属性运行Java应用程序所需的xml部分。
清单7.调用Java应用程序以从JSON文件获取属性
<java jar="${getJSONPropertyValue}" output="${getJSONPropertyValue-Log}" fork="true">
<classpath refid="getJSONPropertyValuePaths" />
<arg value="inputFile=${DeployDeploymentLog}" />
<arg value="Title=${DeploymentRequestJSONTitle}" />
<arg value="outputFile=${DeployRequestIDFile}" />
</java>
执行清单7中所示的命令后，将创建包含清单8中所示的部署请求标识符的输出文件。
清单8.部署请求标识符
6e0d5a7d-d371-4665-8cc5-f99cb4b11856
清单9包含：
将文件加载到属性中的命令 回显命令以在构建日志文件中显示ID
清单9. Build命令读取部署请求文件的内容
<loadfile property="DeployRequestID"
srcFile="${DeployRequestIDFile}"/>
<echo message="ID of Deployment request = ${DeployRequestID}" />
在构建记录中发布指向部署请求的链接
您可以在Rational Team Concert中使用链接发布器命令来发布一个URL，该URL是由在build.xml文件顶部定义为属性的标头URL构建的，以及由清单7中的命令从该文件中提取的ID，并显示为清单8中的示例。使用清单10中的代码将标头URL属性添加到build.xml文件。
清单10.添加到build.xml的用于部署过程请求ID的属性
<property name="DeployRequestDeploymentLinkHeader"
value="${Deploy_WebURL}/#applicationProcessRequest/"/>
清单11是发布链接的命令。
清单11. Build.xml命令来发布指向部署记录的链接
<linkPublisher label="UrbanCode Deploy Application Deployment '${Deploy_ApplicationName}'"
url="${DeployRequestDeploymentLinkHeader}${DeployRequestID}"
componentName="Application Deployment" buildResultUUID="${buildResultUUID}"
repositoryAddress="${repositoryAddress}" userId="${userId}"
passwordFile="${passwordFile}" failOnError="false" />
阶段5.总结
在第5阶段中，您完成了使连续交付过程启动将新组件版本部署到UrbanCode Deploy中定义的特定环境的步骤。 您还在构建记录上创建了指向UrbanCode Deploy中的部署记录的链接。
对阶段1-5所做的更改包含在名为build_phase_all.zip的可下载zip文件中。
阶段6.跟踪部署的结束
阶段5中提供的解决方案在通过Rational Team Concert构建过程跟踪部署过程方面存在一个小问题。 清单12显示了Ant build.xml格式的部署请求命令。
清单12.调用部署的Build.xml命令
<exec executable="cmd" dir="${workingDir}" output="${DeployDeploymentLog}">
<arg value="/c"/>
<arg value="udclient"/>
<arg value="-authtoken"/>
<arg value="${Deploy_AuthToken}"/>
<arg value="-weburl"/>
<arg value="${Deploy_WebURL}"/>
<arg value="requestApplicationProcess"/>
<arg value="${Deploy_DeploymentJSONFile}"/>
</exec>
清单12转换为命令的命令行执行。
清单13.与清单12中的命令等效的命令行
udclient –weburl https://<web-server > -authtoken <my auth token>
requestApplicationProcess <JSON file name>
UrbanCode命令行客户端处理启动部署的请求并完成清单13中所示的命令，并在UrbanCode Deploy接受请求后立即将用户返回到命令提示符。 这并不意味着部署已经结束，并且此命令无法跟踪部署的进度。
结果是，由Rational Team Concert构建调用的部署过程似乎只需要三秒钟即可运行。 这由构建记录的活动跟踪报告显示在图1中。
图1.构建活动记录
如图2所示，UrbanCode Deploy的实际部署花费了22秒。
图2.构建活动的UrbanCode Deploy记录
构建和部署操作的未链接时序如图3所示。
图3.构建和部署操作在不同时间结束
理想情况下，Rational Team Concert的构建过程应等待部署完成，然后再继续执行下一个任务或完成构建。 如果部署过程失败的成功也将被用作构建过程失败成功的指标，则还需要等待部署结束。
您可以在此过程中使用多种暂停检查行为机制。 此处采用的方法是使Ant构建过程定期轮询是否存在特定的标记文件 。 UrbanCode Deploy将标记文件写入部署过程的最后一步，如图4所示。显示了部署过程完成（和创建标记文件）与Rational Team Concert内部运行的Ant构建脚本之间的时间差异。在图4中。差异是在UrbanCode Deploy中完成（和创建标记文件）的部署过程与Rational Team Concert内部正在运行的Ant构建脚本（轮询并发现标记文件已创建）之间。 这将由下一部分中显示的Ant任务的轮询时间段（设置为checkevery="5000". ）给出的最大时间段checkevery="5000". 这表明Ant进程将每5秒查找一次文件。 在此示例中，最大差异可能是5秒，但是checkevery参数的值可以设置为适合您的环境的任何值。
图4.构建和部署操作在不同时间结束
建立流程步骤
要在部署结束时执行轮询，您需要在构建中添加步骤。 清单14是第一步。 它是startBuildActivity命令，在部署的此部分很重要。 它使您可以跟踪UrbanCode Deploy中的部署。 您也可以单击链接到正在运行的部署，并观察运行的步骤。 有时部署可能要花费几分钟，因此务必使用户保持了解状态。
清单14.跟踪部署
<startBuildActivity activityIdProperty="Deploy" label="Polling for Depoy to end"
autoComplete="true" buildResultUUID="${buildResultUUID}"
repositoryAddress="${repositoryAddress}"
userId="${userId}" passwordFile="${passwordFile}" />
标记文件需要一个新的属性定义，如清单15所示。它必须与UrbanCode Deploy在部署结束时创建的文件名和位置匹配。
清单15.标识标记文件的build.xml属性
<property name="DeploymentEndMarkerFile" value="c:\\WorkingDir\\${buildLabel}.txt" />
Ant中的waitfor函数允许系统定期轮询$ {DeploymentEndMarkerFile}指示的特定文件的存在。 在清单16中，将waitfor命令配置为最多等待30分钟。 每5秒钟检查一次标记文件的存在。 更频繁的检查可能会对系统性能产生负面影响。
清单16.使Ant等待文件存在的命令。
<waitfor maxwait="30" maxwaitunit="minute" checkevery="5000">
<available file="${DeploymentEndMarkerFile}"/>
</waitfor>
使用清单17所示的logPublisher来发布部署日志文件。
清单17. logPublisher
<logPublisher filePath="${DeployDeploymentLog}" label="Deploy Deployment Log"
buildResultUUID="${buildResultUUID}" repositoryAddress="${repositoryAddress}"
userId="${userId}" passwordFile="${passwordFile}" verbose="true" />
标记部署过程结束
图5中显示了在部署过程结束时调用的UrbanCode Deploy过程，以指示部署已完成。部署过程步骤为：
检查用于保存标记文件的目录是否存在 如果标记目录不存在（如开关所示），则创建标记目录。 使用“创建文件”处理步骤来创建标记文件。
图5. UrbanCode Deploy部署过程结束
一个名为SampleComponent.zip的可下载zip文件中包含一个包含图5中所示过程的示例组件。
为了使此过程按要求运行并向Rational Team Concert指示部署已完成，部署必须达到此过程，因此应相应地构建应用程序过程。
结算步骤
最后一步是注销UrbanCode Deploy会话，并删除由UrbanCode Deploy创建的标记文件，如图5所示。清单18包含添加到build.xml文件的指令。
清单18.注销UrbanCode并删除临时标记文件
<exec executable="cmd" dir="${workingDir}">
<arg value="/c"/>
<arg value="udclient"/>
<arg value="logout" />
<arg value="-weburl"/>
<arg value="${Deploy_WebURL}"/>
</exec>
<exec executable="cmd" dir="${workingDir}">
<arg value="/c"/>
<arg value="del"/>
<arg value="${DeploymentEndMarkerFile}" />
</exec>
阶段6.总结
对1-6阶段所做的更改包含在名为build_phase_all.zip的可下载zip文件中。
连续交付过程现已完成。 部署过程由构建过程监视。 部署完成后，构建结束。
摘要
本系列文章介绍了将Rational Team Concert Build流程与UrbanCode Deploy集成以进行自动部署的两种不同机制。 任何DevOps解决方案的中心都是开发和运营团队的密切合作。 这种紧密的关系依赖于构建和部署解决方案之间持续的交付过程。 第一个解决方案，即第1部分。现成的实现，在许多情况下都可以正常工作。 建议用户尽可能使用此解决方案。 但是，当团队具有复杂的构建过程并生成要包含在多个UrbanCode组件中的内容时，请使用第2部分和第3部分中介绍的第二个解决方案。标题和链接。
翻译自: https://www.ibm.com/developerworks/library/d-continuous-delivery-rational-team-concert-urbancode-deploy-3/index.html
相关资源：ant build.xml 配置文件
