|
Rational Team Concert（RTC）是一款适合多种开发模式，集需求管理，软件开发，配置管理和构建为一体的多功能管理软件。自动化的数据收集和报告降低了管理开销并提供了高效管控软件项目所需的实时洞察。
Rational ClearQuest（CQ）是一款经典的，已经被广大客户所接受的变更追踪工具。目前已经被多家企业部署在企业环境中，用作项目流程管理，变更追踪。由于其高度的可定制化，不少企业已经按照其自身发展的需要，定制了相关的流程管理规约。
随着软件开发的发展，开发团队将会引进更先进的管理工具以提高团队效率。而对于传统的 CQ 用户来说，由于
CQ 具有高度的可定制化，所以 CQ 用户可能已经拥有庞大的已定制数据，在这个基础上引进 RTC 的困难在于数据同步或者数据转移的高风险和高消费。
Rational Team Concert ClearQuest Bridge（RTC CQ Bridge）将解决这个问题。
如何在企业中，基于既有 IBM Rational ClearQuest 环境，迅速的部署和使用这套基于
RTC-CQ Bridge 的解决方案，便是本文将要带给您的内容。
为了陈述方便起见，本文使用了如表 1 所示的缩写。
表 1. 缩写及版本号表
| 缩写 |
全称 |
版本号（本文中默认使用的版本号） |
| RTC |
IBM Rational Team Concert |
2.0 |
| CQ |
IBM Rational ClearQuest |
7.1 |
| DB2 |
IBM DB2 |
9.5 |
| WAS |
IBM WebSphere Application Server |
6.1.23 |
在本节中我们将介绍如何在 WAS 上部署 RTC，如何使用 DB2 作为 RTC 的数据库，以及如何配置
RTC CQ Bridge。首先我们来看部署拓扑结构。
RTC 与 CQ
集成的部署拓扑结构
对于已经部署了 CQ 7.1 的用户来说，使用 RTC-CQ Bridge 也进一步保护了用户的既有投资。在已有设备的基础上，用户仅需要多一台
RTC 服务器，就可以体验 RTC-CQ 互动的效果。图 1 给出了 RTC 和 CQ 7.1 集成的部署拓扑结构。（在这里我们要求
CQ 的版本必须是 7.1 以及以后的版本，而 RTC 的版本则必须是 2.0 或是以后的版本。）
图 1. RTC 与 CQ 7.1 集成的部署拓扑结构
我们可以看到，在原有的 CQ 7.1 服务器的基础上，我们添加了一台 RTC 服务器及其相关的数据库服务器。如果资源有限，RTC
DB 服务器和 CQ DB 服务器可以合二为一。图中显示 CQ 7.1 以及 RTC 中的用户都是使用统一的
LADP 来管理的。这样非常方便用户一体化管理。
部署拓扑结构图有了，接下来的工作就是要讲 RTC 部署到 WAS 上了。我们假设用户已经正确的安装了
CQ 7.1，关于 CQ 7.1 的相关信息，请参见 CQ 7.1 信息中心（参见参考资料）。
配置 DB2 数据库（以
DB2 V9.5 为例）
在 DB2 数据库服务器上，为 RTC 建立一个数据库。建立数据库的时候，对于表空间，我们推荐使用 8K
以上的表空间。而因为 DB2 内置的 8K bufferpool 比较小，因为我们建议为这个数据库新建一个大小至少为
1GB 的 bufferpool，以防止在多用户使用过程中出现 bufferpool page 不足的情况。鉴于
DB2 V9.5 自身的特点（参见 http://www.ibm.com/developerworks/wikis/display/im/DB2+9.5+for+Linux+-+Supported+Environments），我们推荐在企业级应用时，将
DB2 V9.5 部署在 64 位操作系统上。可以对所创建数据库的一些参数进行一些优化调整，使其能够更好的适应企业环境下多用户访问时的需要，比如修改堆栈大小：db2
update db cfg for <RTC db name> using APPLHEAPSZ
10000。
在创建了数据库之后，打开 Installation_path/JazzTeamServer/server/conf/jazz/
中文件 teamserver.properties，修改其中的 DB2 配置部分：
清单 1. DB2 配置
com.ibm.team.repository.db.jdbc.location=
//<DB2 Server address>:<db2 server port>
/<Jazz DB name>:user=<db2 user name>;password={password};
com.ibm.team.repository.db.jdbc.password=<db2 user password> |
然后打开文件 Installation_path/JazzTeamServer/server/conf/jazz/provision_profiles/license-profile.ini,
做如下修改：
清单 2. 修改 license-profile
url=file:///Installation_path/JazzTeamServer/server/license-update-site。 |
打开文件 Installation_path/JazzTeamServer/server/conf/jazz/provision_profiles/profile.ini，做如下修改：
清单 3. 修改 profile
url=file:///Installation_path/JazzTeamServer/server/update-site |
最后，使用位于 Installation_path/JazzTeamServer/server 目录下的
repotool.bat 工具，在数据中建立相关的表单以及数据。命令如下：
清单 4. 创建表单
repotool.bat -createtables |
将 RTC 部署到
WAS 上
在 RTC 发布的时候，由于已经内置了 Tomcat 以及 Derby 数据库，所以若想快速体验，十分简单，只需要直接运行
server.startup.bat/server.startup.sh 来初始化环境（包括应用在 TOMCAT
上的自动部署和 DERBY 数据库的初始化），然后用浏览器访问 https://<RTC Server
Host Name>:9443/jazz/web 就可以了。
在本节中，我们来看一下如何将 RTC 部署在 WAS 6.1 上。我们的场景配置如下，Websphere
6.1 Fixpack 23【注 1】@Windows 作为应用服务器 ,DB2 9.5 作为数据库服务器，LDAP
作为用户管理服务器。
注 1：对于 Websphere 6.1，需要升级到 Fixpack 23 版本，对于 WAS 7.0,
我们同样需要您将其升级到 7.0.0.3 版本。
参数设置
在 WAS 服务器上部署 RTC 应用之前需要对服务器的参数进行一些修改，
首先是 WAS 服务器上 JVM 参数的修改，进入 Application servers >
server1 > Process Definition> Java Virtual Machine，分别将
JAVA HEAP SIZE 的初始值和最大值设定为 100 和 1000，如图 2 所示：
图 2. WAS 参数设置 -JVM 堆
然后进入 Application servers > server1 > Process
Definition > Java Virtual Machine > Custom Properties，添加以下个性化属性。
清单 5. 个性化属性
JAZZ_HOME = file:///Installation_path /JazzTeamServer/server/conf/
java.awt.headless = true
org.eclipse.emf.ecore.plugin.EcorePlugin.doNotLoadResourcesPlugin = true |
如图 3 所示。
图 3. WAS 参数设置 -JVM 客户属性
其中，参数 JAZZ_HOME 的 Installation_path 表示 JazzTeamServer
的装载路径。下面也将使用这个表示方法。
最后配置 WAS 中的安全设定。
由于应用上安全设置的需要，我们需要在 WAS 的安全设定中，对 WAS 的默认安全性设定进行一些修改。进入到
Secure administration, applications, and infrastructure
中，选中”Enable administrative security”和“Enable application
security”。同时取消”Java 2 security”。由于我们选择用 LDAP 来管理 RTC
中的用户验证，因此我们选择”Standalone LDAP registry”作为用户域。点击”Configure”按钮来配置
LDAP 服务器的相关信息。如图 4 所示。
图 4. WAS 中的 LDAP 配置
接下来，我们从右侧选中”Web security” > General setting, 选中“Use
available authentication data when an unprotected URI
is accessed”，如图 5 所示。
图 5. WAS 中的 LDAP 配置
部署 RTC 应用 war 包
在应用了上述配置之后，重新启动 WAS
服务器，使得刚才的变动生效。接下来开始部署 RTC 应用的 war 包。
进入到 Applications> Install New Application 页面，输入 jazz.war
所在的绝对路径 ( 在 RTC 的安装路径下 )。并且输入 Context root 路径为 /jazz，如图
6 所示。
图 6. 部署 RTC 应用的 war 包
然后一步接一步按照默认的配置完成 RTC 的部署即可。
在启动 RTC 应用之前，因为 RTC 中对于用户的权限分配是按照角色的，所以我们需要在 WAS 中将
LDAP 服务器上的用户引入，并且按照角色进行分组，映射。进入 Enterprise Application>
jazz_war> Security role to user/group mapping，如图
7 所示。
图 7. RTC 的用户映射
配置 RTC
在完成上述配置之后，我们可以在 WAS 中启动 RTC 的应用。并在浏览器地址栏中输入 https://<RTC
Server>:9443/jazz/setup 来进行 RTC 的一些初始化配置。
★★这里，对于验证上面的配置，我们有一个小窍门分享给大家。鉴于我们刚才的配置过程中涉及到了数据库端，应用本身的配置文件，WAS
服务器端的一系列配置。这时，如果某个步骤出现了一些差错，那么在初始化 RTC 的时候，就会遇到问题。为了更好的来验证配置的正确性，我们建议在安装
RTC 的时候，将默认的 Tomcat 装上。这样在 WAS 上部署好 RTC 之后，我们可以先暂时停掉
WAS 服务，以防止端口冲突。启动 Tomcat, 然后访问 https://<RTC Server>:9443/jazz/
web。如果这时用默认的 ADMIN 用户访问 RTC 出现问题，那么我们需要检查我们的数据库以及应用本身的配置文件是否正确，如
teamserver.properties，license-profile.ini 以及 profile.ini。在确保数据库和应用本身配置正确的情况下，我们停掉本地的
Tomcat 服务器，启动 WAS，这样来进一步判断我们在 WAS 上的配置是否正确。
配置步骤如下：
- 通过 https://<RTC Server>:9443/jazz/setup 进入到配置界面，选择
Custom Setup。
- 首先进行数据库的配置。如果根据前面介绍的步骤已经正确修改了文件 teamserver.properties
的内容，数据库会自动配置成功。在配置完成之后选择测试数据库，如果给出的提示信息说明连接成功，说明配置正确。否则则需重新配置。
- 第三步是配置邮件通知系统。这里跳过。
- 第四步是配置用户注册信息。由于我们使用的是 LDAP 用户管理，所以现在 Step 1 里选择
LADP 选项。然后在 Step 2 里面修改一下字段的内容：
- LDAP Registry Location: LADP 地址，形如 ldap://ip:port。
- Base User DN: LDAP 相关信息，根据不同的 LDAP 系统而不同。
- User Property Name Mapping：同上。
- Base Group DN：同上
- Jazz to LDAP Group Mapping: Jazz 到 LDAP 用户组映射。如果没有做组映射，则使用默认值即可，否则应该根据默认值的格式修改组映射。
- Group Name Property：LDAP 相关信息，根据不同的 LDAP 系统而不同。
- Group Member Property：同上
- 配置完成之后需要测试，如果测试通过，即可到下一步，否则需重新配置。
- 配置结束，点击下一步，可以继续创建项目或者用户，或者跳转到别的界面进行操作。
导入用户。我们使用的是 LDAP 进行用户管理，在进行了上面的配置之后，还需要讲 LADP 里面的用户导入到
RTC 里面，方可进行使用。导入步骤如下：
- 通过 https://<RTC Server>:9443/jazz/admin 进入到管理员界面，选择“User
Management”。
- 选择 Import Users，在弹出的对话框中查询用户，然后进行导入。
- 分配权限。需要注意的是 RTC 的权限分两部分，一部分是存储空间权限，这种权限分四类，JazzAdmins,
JazzDWAdmins, JazzUsers, JazzGuests。在使用 LDAP 管理用户时，用户这部分权限是在做用户映射的时候分配的，详细请参见本文部署
RTC 应用的 war 包部分。另外一部分是客户端访问权限，这部分分五类，详细请参见 RTC
2.0 信息中心（参见参考资料）。
至此，RTC 配置结束。下面开始配置 RTC CQ Bridge。
配置 RTC CQ
Bridge
在通过 https://<RTC Server>:9443/jazz/setup 完成 RTC
的初始化配置之后，我们转到 RTC 服务器的 Admin 管理页面，通过下面几个简单的配置，我们就可以连接
RTC 与 CQ 之间的桥架通。
在 Admin 视图下，选择 Configuration > Advanced Properties,
找到 CQ Bridge 这段，如图 8 所示。
图 8. RTC CQ Bridge 配置
通过图可以看到，总共有八项属性。其中必须填写的只有两项。一个是 ClearQuest Web remote
server，默认值是 localhost. 这个只有在本地也安装了 CQWeb Server 才使用。通常情况下，这里填写所需连接的
CQWeb 服务器地址。另外一个是 Enable CQ Bridge Webui：默认值是 False。如果选择
False, 那么就意味着在 RTC 的 Web 界面上看不到 CQ Record 这样一个 Tab。如果选择
True，那么如图 9 所示。关于其他属性，请参见 RTC 2.0 信息中心（参见参考资料）。
图 9. 配置了 RTC CQ Bridge 之后的 RTC 界面
除此了上述配置之外，我们还需要在 com.ibm.team.repository.servlet.internal.ServletConfigurationService
属性中，将 Host Name 一值配置为 RTC 服务器的域名。如图 10 所示
图 10. 配置 Host Name 项
前面介绍了 RTC CQ Bridge 的安装和配置。本章将简单介绍 RTC CQ Bridge 在企业环境下的使用。对于企业级用户来说，CQ
Bridge 主要涉及到 RTC Web 客户端中的以下三个页面
- CQ Records 页：该页面类似于 CQ Web 客户端，实现了大部分 CQ Web 客户端的功能，另外包含
CQ Bridge 的功能。负责需求管理和负责变更管理的人员将主要在此工作。如负责需求管理的人员在此建立需求，测试人员在此创建、维护变更等。
- Work Item 页：该页面为 RTC 的功能页，用户在此对所有的 work item 进行增删改查的功能。与
CQ Bridge 相关的是，用户在该页面下，可以查看 work item 与 CQ 记录的链接信息。
- Dashboard 页：RTC Dashboard 中提供四种 CQ Bridge 相关的 CQ
Viewlet，这些 Viewlet 为用户提供了管理项目、查询当前状态的轻便视图。对于管理人员来说，可以通过这些
Viewlet 来查看当前的项目状态，比如当前项目下还有多少需求没有被实现或者有多少变更还处于未解决的状态。对于开发人员来说，可以通过这些
Viewlet 来关注自己当前的工作状态，比如可以查看哪些分配给自己的 work item 已经与需求关联起来，或者哪些分配给自己的变更还没有被解决。
在软件开发过程中，一般有这样的流程，初期的需求管理，中间的项目管理，测试阶段下的变更管理。下面我们结合这个简单的流程介绍
RTC CQ Bridge 在企业环境下的使用。
开发初期—在
CQ Records 页实现需求管理
在 RTC 2.0 版本中，经过适当的配置（请参见安装、配置小节），RTC
的 Web 客户端就有一个 CQ Records 页，如图 11 所示。
图 11. CQ Records 页）
RTC 在这个页面下实现了大部分 CQ Web 7.1 的功能，包括创建记录、查询记录、修改记录等操作。对于企业级用户来说，负责需求管理的人员将可以通过这个界面来实现需求的管理和维护。
一般来说需求只是笼统的概括希望实现的目标。真正开始开发时，需要有相应的方法或故事来实现这些目标。在 RTC
中，有一种 Story 类型的 work item 满足这个要求。显然，需求记录应该与 Story 相关联起来。如图
11 所示，可以通过 CQ Records 页下链接创建、显示区来创建 CQ 记录和 RTC 记录之间的链接。
有两种创建链接的方式，一是创建一个已有 RTC 工作项目与当前 CQ 记录之间的链接；另一个是创建一个新的
RTC 工作项目并建立他与当前 CQ 记录之间的链接。打开一个已有的记录。在链接创建、显示区，点击向下的箭头，会出现如图
12 的结果。
图 12. 创建链接
创建链接之后，在 CQ Records 页和 RTC 工作项目页都有显示。在 CQ Records 页下记录中的显示如图
13 所示。
图 13. CQ 记录中的链接显示
开发过程中—通过
Dashboard 和 Work Item 实现项目管理
在开发初期，需求和相应的故事已经建立。接下来就是开发过程。一般来说，故事是比较概括的说明，应该建议一些子
Work item，即 task 来细化故事内容。然后可以将 task 具体分配到某个工作人员。同时，为了统一起见，这些
task 应该与相应的故事的需求连接起来。至于如何创建链接，请参见开发初期—在
CQ Records 页实现需求管理。
开发人员只需要结合分配到自己的 Task 类型的 Workitem 来完成相应的工作。
前面我们看到，CQ Records 页内会显示链接内容。在 RTC 的工作项目中，有一个链接页，链接信息也会被显示在其中。如图
14 所示。
图 14. 工作项目中的链接显示
由于链接信息是以超链接的形式显示的，用户可以通过它连接到相应的 CQ 记录信息。
工作项目中显示的信息只是一条记录的链接信息。
而 Dashboard 下 CQ Viewlet 则将这些信息统计起来通过表的方式显示，更方便也更全面。
RTC 2.0 中有四种 RTC CQ Bridge 相关的 Viewlet。图 15 是创建这些 Viewlet
的界面。
图 15. 创建 CQ Viewlet。
通过 Viewlet 这样一个统计输出的方式，用户可以对自己当前关心的信息有一个概览。作为开发人员，可以了解到当前自己的任务状况；而作为项目管理人员则可以了解到整体项目的进展状况。
测试阶段—通过 CQ
Records 页实现变更管理
通过图 11 可以看到，在测试阶段，测试人员可以在 CQ Records 页面下创建、修改、删除 CQ
中的变更记录，并且修改变更记录的状态。
测试人员提交了变更之后，管理人员或者开发人员应将其分配到某位开发人员。在 RTC 中，可以创建一个 task，将此
task 与变更连接起来，然后将此 task 分配给某位开发人员。这样，该开发人员即可知道自己被分配了新工作并且可以通过
task 里连接页来查看相应的变更信息。关于创建链接以及链接显示，请参见图 12 和图 14。
本文着重介绍了 Rational Team Concert ClearQuest Bridge 的企业级安装、部署和配置。希望读者通过本文可以快速高效的将
Rational Team Concert ClearQuest Bridge 部署到自己的企业环境里去。另外，本文也简单介绍了
Rational Team Concert ClearQuest Bridge 在企业级环境中的使用，希望对读者有所帮助。
学习
获得产品和技术
讨论
| 
