开箱即用_开箱即用的实现

最新推荐文章于 2024-04-07 09:42:57 发布

cusi77914

最新推荐文章于 2024-04-07 09:42:57 发布

阅读量2.1k

点赞数

文章标签：大数据数据库 python linux java

原文链接：https://www.ibm.com/developerworks/library/d-continuous-delivery-rational-team-concert-urbancode-deploy-1/index.html

版权

本系列文章介绍了两种集成IBM Rational Team Concert™和IBM®UrbanCode Deploy来创建连续交付过程的机制。本文第1部分中包含的第一种方法是易于设置的打包即用型实现。第2部分和第3 部分中介绍的第二种方法使用Ant Ant.xml文件的扩展名。

许多组织都受益于持续集成过程，该过程在用户将更新的源代码提交到源代码存储库后执行软件组件的完整构建和单元测试。立即建立完整的系统以及运行单元测试，可以很好地验证开发人员所做的更改是否令人满意，并且没有引起集成错误。但是，在此阶段可以执行的测试级别是有限的，不能用来确认应用程序正确地提供了所需的功能，也不能进行性能或安全性测试。进行此类操作的唯一方法是将应用程序部署到运行时环境中，并以类似生产的方式运行应用程序。将持续集成过程从构建和单元测试扩展到还将应用程序部署到运行时环境的过程的扩展称为连续交付过程。

这三篇文章中的第一篇文章首先回顾了提供持续集成功能的Rational Team Concert元素。如果您熟悉Rational Team Concert，则可能要跳到“ 持续交付”部分。

关键概念和术语

这些是使用Rational Team Concert进行协作开发的重要概念和术语。

学到更多。开发更多。连接更多。

新的developerWorks Premium会员计划可通过Safari图书在线访问强大的开发工具和资源，包括500项顶级技术标题（数十种专门针对Web开发人员），获得顶级开发人员活动的折扣，最近O'Reilly的视频重播，会议等。立即注册。

流

流充当更改的收集点。它们包含所有开发工作的累积结果。用户“交付”对流的更改，并且为了使工作区保持最新状态，他们“接受”来自其他用户的流中的更改。流在概念上与许多其他版本控制系统中的分支相似。

变更集

在Rational Team Concert中在版本控制下对文件进行更改时，需要对其进行管理和跟踪。变更集是一种将文件和目录变更分组到一起的集合的机制，这些集合在逻辑上构成一个完整的工作单元。该分组任务是作为Rational Team Concert的检入过程的一部分执行的。然后，在大多数情况下，变更集与工作项（例如任务或缺陷）相关联，从而使变更集的上下文可见。通过变更集，团队成员可以查看执行的变更，以确保满足工作项的要求。

交货

交付是将文件更改从开发人员的隔离工作区转移到当前与该工作区关联的流。交付操作的结果是新文件或新文件版本存储在流中，并且可供与该流关联的其他开发人员使用。 Rational Team Concert用户界面可以通知其他开发人员新内容的存在，并且他们可以选择适当的时间来接受更改。

接受

接受是使用其他用户最近交付的新文件内容更新用户工作空间的过程。

用户工作区

每个用户都有一个存储库工作区，该工作区连接到他们将工作交付到的流。当用户对文件进行更改时，编辑后的副本将保存在与存储库工作区关联的客户端沙箱中。用户完成更改后，将检入文件并将其从客户端复制到存储库中基于服务器的区域。该文件与用户也已更改的其他文件一起收集到“更改集”中。更改集完成后，用户将更改集传递到流中。

与Rational Team Concert进行协同开发

图1显示了用户与流的交互。用户1将文件更改检入到服务器端存储库工作区中，并创建一个新的更改集。然后，将变更集与工作项相关联以提供变更集上下文。然后，工作项（和关联的变更集）将交付给共享流。开发人员2接受将更新其存储库工作区的更改，并将文件更改复制到存储其存储库文件的本地硬盘上。

图1.流签入，交付和接受

持续集成

图2概述了持续集成过程中的交互。

图2.开发人员和构建自动化共享应用程序代码的过程

在图2中，三个开发人员通过一个共同的开发流共享他们的工作。例如，John完成了一项工作并将其交付给开发流。然后，Sue和Chris可以选择将该工作接受到他们的工作区中，以使他们能够将John的更改集成到他们的工作中。这个过程创建了一个协作环境，开发人员可以在其中隔离工作区中进行工作所需的隔离，但是他们也可以使用开发流进行受控的集成过程。存在连接到构建过程的特殊工作空间。定期间隔（可能短至每分钟），启动构建过程，构建工作区寻找交付给开发流的新更改。如果构建过程发现自上次构建以来没有任何更改，则它只是停止构建。如果构建过程确实找到了已提交的新更改，则将运行构建，并生成一个结果，其中包含创建的二进制对象和已执行的单元测试的任何适当记录。图3详细显示了构建过程的示例。 John完成了两个变更集的工作（与编号为2012和2013的工作项相关）。 John将更改传递到共享流，这导致邀请Sue和Chris邀请接受更改并更新其工作区。克里斯随后完成了有关缺陷1985的工作，并交付了工作项和相关的变更集。然后，John和Sue将更改集接受到他们的工作区中。

图3.交付并收集到构建记录中的变更的示例

在用户执行“交付关键概念和条款”部分中描述的交付操作之后，计划的构建过程开始。生成的日志文件和二进制对象存储在Rational Team Concert构建记录中，并生成一个新的快照。快照与构建记录关联。在大多数情况下，生成二进制对象（例如JAR文件，WAR文件，EAR文件，EXE文件或某些其他文件格式）的过程已结束。干净地构建集成的应用程序代码并通过所有自动运行的单元测试的能力是对工作质量的衡量标准，并且是项目团队朝着一个共同目标努力的良好标志。但是，许多团队希望走得更远，并扩展流程以将应用程序部署到运行时环境中，以进行进一步的测试操作。

Rational Team Concert的构建过程

在本文的可用空间内，不可能提供有关Rational Team Concert构建过程或build.xml文件的详细信息。产品帮助页面和许多基于Web的文章中提供了有关如何创建Rational Team Concert构建过程的更多信息：

“ Ant入门在Jazz构建引擎上构建 ”
“ Ant脚本和Rational Team Concert构建Ant任务入门 ”
注意事项 ：
本文之所以引起关注，是因为在本文的其他build.xml内容中都使用了Rational Team Concert构建扩展。

如果您想了解IBM开发团队如何使用Rational Team Concert来构建Rational Jazz产品系列的详细信息，请阅读“ 我们如何使用CLM来构建CLM” 。

持续交付

在构建连续交付过程时，需要执行其他任务才能在运行时环境中实际安装二进制对象。 Rational Team Concert负责流程的构建和单元测试（连续集成阶段），而UrbanCode Deploy负责部署。简单来说，两种产品之间的边界就是要部署的二进制文件。 Rational Team Concert生成二进制文件，而UrbanCode Deploy使用该二进制文件并将其部署到环境中。

团队可以对已部署到运行时环境的应用程序执行更实际的功能，性能和安全性测试。这是部署操作具有这种价值的原因之一。此过程还使部署成为团队标准操作程序的一部分，并确保每个人都了解部署环境，部署要求以及部署无法顺利进行时导致的问题。在数周的开发工作中，开发团队执行了数百次甚至数千次应用程序部署到开发和QA环境的部署。结果，在开发阶段对应用程序部署过程进行了测试，调整和修改，以使人们对部署到预生产和生产环境的过程充满信心。

一个简单的连续交付过程

您可以使用完全图形化的机制创建一个简单的连续交付过程，以将Rational Team Concert构建过程连接到UrbanCode Deploy解决方案以进行自动部署。 Rational Team Concert版本4.0.5上增加了一个新的构建后部署选项，其中包括一个新的构建后部署选项，该选项使构建过程可以轻松地与UrbanCode Deploy进行交互。您可以通过打开构建定义将构建后部署功能添加到现有构建过程中。单击屏幕顶部的“ 构建定义 ”一词，然后选择“ 配置” 。 “构建后”选项卡上提供了“构建后部署”选项。

通过此简单过程，您可以将新建内容上载到单个UrbanCode Deploy组件的新版本中。如有必要，有一个调用部署的选项。

图4.将构建后部署选项添加到现有构建中

配置发布后部署

构建后部署过程要求用户填写某些属性。所需的信息是：

UrbanCode Deploy服务器的URL。
用于UrbanCode Deploy登录过程的用户名。
在步骤2中标识的用户的密码或身份验证令牌。
新组件版本应存储到的组件的名称。
要赋予新创建的组件版本的版本名称。通常，使用$ {buildLabel}语法，将构建标识符用作名称的至少一部分。
基本目录引用，用于标识存储构建工件的位置的一部分。从此基本位置获取需要存储在UrbanCode Deploy中新组件版本中的内容。
新组件版本中包含的文件集。这是所需文件的模式匹配。 ** / *模式匹配将占用所有文件。
从新组件版本中排除的文件集。
需要复制到UrbanCode Deploy的所有属性。这样的名称/值对属性将作为新属性添加到组件版本中。这些可以在部署操作期间访问。此类属性的格式为：： snapshotUUID=${team.scm.snapshotUUID}
要在UrbanCode Deploy组件版本上创建的任何链接，例如指向Rational Team Concert构建记录的链接。通过在Web浏览器中加载任何构建记录并复制URL的相应部分，可以获得包含在此链接中的语法。完整的构建记录链接的示例如下：
```
https://rational-srv-02:9443/ccm/web/projects/
JKE%20Banking%20%28Change%20Management%29#action=com.ibm.team.build.viewResult
&id=_KclYURb0EeSlFMEP2zrMSg
```

要添加的构建结果包括整个URL，直至并包括'='符号。剩余的构建结果标识符将替换为参数$ {buildResultUUID}。
注意：
清单1中的存储库地址也被参数替换。

清单1.构建结果

Build Result=${repositoryAddress}web/projects/JKE%20Banking%20%28Change%20Management%29#
action=com.ibm.team.build.viewResult&id=${buildResultUUID}

构建后部署配置的最后部分包括一个复选框，用于指示在加载新组件版本后是否需要开始部署。
如果需要启动部署，则用户必须标识：
- UrbanCode Deploy应用程序
- 部署应在其中运行的应用程序环境
- 应用程序运行。

图5-7显示了完整的构建后部署配置。

图5显示了服务器连接以及用于建立与UrbanCode Deploy的连接的用户凭据。

图5.构建后部署–服务器连接

图6显示了“发布工件”页面，在其中输入要接收新版本的可交付成果的组件的名称。您还可以指定UrbanCode Deploy使用的版本标识符来命名新版本。图6中的示例显示了$ {BuildLabel}语法使用Rational Team Concert构建记录中记录的日期和时间戳构建标签。

图6.构建后部署-发布工件

图7显示了在UrbanCode Deploy中发布组件的新版本之后要运行的过程。部署流程的调用是可选的，如图7顶部所示的“ 部署”复选框的状态所指示。要运行部署，请键入应用程序的名称，要使用的环境和流程。

图7.构建后部署-流程请求表

运行后期构建部署的结果

成功运行构建后部署操作后，从构建过程中选择的文件将存储在UrbanCode Deploy中已标识组件的新版本中。该UrbanCode部署组件版本包含一个指向Rational Team Concert构建记录的链接。从UrbanCode Deploy中选择该记录后，将在Web浏览器界面中打开该记录。

如果请求，那么Rational Team Concert构建过程也会调用部署操作。该操作的结果包含在UrbanCode Deploy中。从UrbanCode Deploy应用程序部署结果记录到Rational Team Concert构建过程没有链接。产品之间的所有链接都从UrbanCode Deploy组件版本到Rational Team Concert构建记录。

摘要

本文介绍的连续交付解决方案易于设置和操作。它将帮助团队将内容推送到UrbanCode Deploy并调用该内容的部署。这种方法的主要优点之一是，可以在无需开发人员学习其他工具的情况下运行部署。他们需要使用的是现有的源代码管理和构建产品。

翻译自: https://www.ibm.com/developerworks/library/d-continuous-delivery-rational-team-concert-urbancode-deploy-1/index.html