产品升级是所有软件系统都必须考虑的重要问题，升级的复杂度会因具体部署环境不同而变化。企业环境中的 IBM Rational ClearCase/ClearQuest 通常就是一个多站分布式部署的复杂系统，由于部署采用多站，而且产品被分为各个组件分布在不同的机器上协作完成任务，机器之间有比较紧密的耦合关系；同时，企业应用的数据量庞大，数据和产品都存在集成，这些因素都增加了升级过程中的风险。本文将以一个典型的 ClearCase/ClearQuest 企业部署环境为例，介绍从 2003.06.15 版本到 7.0.1 版本的阶段式升级策略，这种策略能够保证项目进度在升级过程中不受影响。为了适应 2003.06.15 到 7.0.1 之间的那些版本间的升级，给用户更全面的参考，文章从版本兼容性的角度详细阐述了为何如此安排升级策略。另外，为了提供更好的保障，本文还提供了一些情况下的数据备份、恢复方法以供参考。

1. 前言

文章假设读者已经具备了 ClearCase/ClearQuest 产品的部署配置知识，所以没有给出细节描述。考虑到文章中涉及这些内容，读者可以参考以下几方面内容的文章：

1. ClearCase/ClearQuest 集成设置
2. ClearCase/ClearQuest 跨操作系统分布部署设置
3. ClearCase/ClearQuest 多站环境部署设置

本文主要针对 ClearCase/ClearQuest 系统升级管理员撰写。不过由于产品部署初期也会预先考虑到远期产品升级问题，因此也可为 ClearCase/ClearQuest 的系统管理员和部署配置人员提供参考。

1.1 简介

产品升级（Product Upgrade）是产品使用过程中一个不可缺少的重要环节。它在遵循向后兼容（Backwards Compatibility）的原则下，修正原有产品的缺陷（Defect），同时添加新的功能（New Feature）。在非企业环境下，大部分产品都孤立地安装于一台物理机器上，因此产品的升级相对简单。然而在大部分企业的应用环境中，产品之间互相集成、分布式部署，所以必须研究讨论产品的升级策略，这样才能降低升级存在的固有风险。

在此，主要针对 IBM Rational 两款软件配置管理（Software Configuration Management）工具展开升级的讨论：

ClearCase —业内优秀的软件配置管理工具。以下简称 CC。

ClearQuest —软件变更管理和缺陷跟踪工具。以下简称 CQ。

在企业应用环境下，CC 和 CQ 可以互相集成使用。它们的结合使得 CC 管理的各个文件的不同版本不再是孤立的元素，而是被 CQ 有机组合在一起，构成一个完整的软件变更集。这样集成，可以把需求分析员、开发者、项目管理人员有效的组织在一起，协同完成软件的开发和测试。

此外，CC/CQ 是相对典型的客户端 / 服务器（C/S）的结构，所有的资源由服务器控制。为了提高访问效率、平衡服务器负载，产品被分为不同的组件，分布式部署在不同的物理机器上；同时，为了减小跨国、跨地域低带宽访问的可能性，CC/CQ 都采用多站点（MultiSite）部署；为了提高数据安全性，产品和数据也是分离的。

在这样的环境中，各台机器、各个站点之间的产品和组件存在复杂的关联性；分离的数据和产品也存在关联性。因此升级存在风险。一台服务器升级失败可能会影响全局，甚至威胁到原有数据，从而影响整个项目的进度和成败。因此必须讨论和使用一种合理的升级策略去解决以上的问题。

1.2 约定

复杂环境的升级涉及两个重要的方面：产品部署的拓扑结构和软件版本。显然，在一篇文章中不可能完全覆盖所有的情况。为了更好的描述升级策略，文章做了两个前提性的约定（或假设）：

1. 以一个典型的企业部署拓扑结构为例讨论升级，力图用一次完整的升级过程给读者直观的印象。具体拓扑结构请参考第 2 章。
2. 以两个较为常见的软件版本为例讨论。版本的升级路线为：2003.06.15 升级到 7.0.1。前者是 2003 年 6 月的发布版本，后者是 2007 年 6 月的发布的版本。

不过，即使拓扑结构或者软件版本不完全相同也可以参考此文。因为在产品部署方面，升级策略是围绕一些基本理念展开讨论的，兼顾了相似的拓扑结构。而在版本升级路线方面，由于 2003.06.15 和 7.0.1 是目前差别较大且较常见的两个版本，因此在他们之间的那些版本升级也可以参考（例如：从 7.0.0 升级到 7.0.1）；另外文章还在第 4 章着重讨论了版本兼容性，以供参考。

下面，开始围绕这个典型的拓扑结构展开升级的讨论。

2. CC/CQ 升级综述

2.1 拓扑结构

CC/CQ 的复杂环境部署有非常多的组合类型。图 1 是一个比较典型的拓扑结构，适用于中小型企业，这是一个较通用的结构：可以通过继续缩小和删减机器达到简化作用，也可以通过扩展，增强功能，从而适应于大型企业。

图中，所有的 CC/CQ Server 和 Client 被划分为两大部分：Master Site（主站）和 Replica Site（从站）。在跨地区的团队协作中，为了提高 CC 和 CQ 的本地客户的访问效率，总是采用这种多站（MultiSite）的分布式部署。数据分别在每个站点有各自的拷贝，它们之间通过 MultiSite Server 进行同步和传输。

在 Master Site 和 Replica Site 中， CC/CQ 的 Server 有着相同的部署，它们各自服务于本地的 Client。因此两个站点中的同名机器承担着相同的角色。当然，在实际情况下，站点与站点的部署可能不相同，但是为了集中讨论主要问题，这里假设它们是相同的。下表 1 以 Master Site 为例，分别介绍每台机器承担的角色。Replica Site 亦同。

1. CC 的机器在同一个站点中是属于同一个域的，由一个统一域服务器来管理。拓扑结构中没有体现域服务器，但实际上是存在的。
2. 机器的操作系统可能是混合使用的，有的是 Windows，有的是 Linux。这样 CC 存在跨操作系统部署，配置和部署的方法请参考相关文档。
3. 机器的操作系统没有硬性规定。在升级中，若针对操作系统升级方法不同，则会同时提供 Linux 和 Windows 的解决方案。

在每个站点中，可以发现： CC 和 CQ 的集成是通过 CCCQ Admin 来管理的，而有的企业可能只需要单独使用 CC 或者 CQ，不需要集成。那么完全可以省略 CCCQ Admin，将 CC CQ 分开考虑，使其自成一体。这在表 1 中也有体现：红色标出的 CC 可以构成一个单独的 CC 站点；而蓝色标出的 CQ 亦同。

实际上，图 1 是一种特定的拓扑结构。更加抽象的拓扑结构如图 2 所示。图 2 力图简化图 1，从而给读者更清晰、完整的视角。

在此，MultiSite 的部署不仅仅只包含 Master Site 和 Replica Site 的情况了，MultiSite 由任意多个站点构成。每个站点之内的机器自成一体，拓扑结构可以相同，也可以不同。不过需要注意的是，虽然大部分情况下，Master Site 和 Replica Site 没有太大区别，地位是平等的；然而对于 CQ，它们还是有主从之分：因为 CQ Master DB 的修改权利只有主站拥有，所以在升级 CQ Feature level 和 CQ Package 时需要注意，只能先升级 CQ Master Site，后升级 CQ Replica Site，而不能颠倒顺序。

2.2 升级策略

针对于图 2 的抽象描述，可以将升级的策略归纳为一个更通用的指导方针：“阶段升级策略”（Stage Upgrade Strategy）。它将升级顺序分为几个阶段，每个阶段包含一台或多台物理机器，一次性对这些机器中安装的产品同时升级，每阶段升级完毕后，提供了相应的验证方法，以便及时找出问题。升级的阶段如图 3 所示。

阶段升级策略先升级服务器（Server），后升级客户端（Client），最后升级数据；而在升级 Server 的过程中，又将 CC 和 CQ 分开进行，先升级 CC，后升级 CQ。而对于 MultiSite，一般是先升级 Master Site 的一个产品，然后再升级 Replica Site 的同一个产品。MultiSite 的升级顺序最好不要颠倒，以免带来意外的麻烦。特别是升级 CQ Feature Level 和 Package 的时候。

阶段升级策略将整个升级分为了几个大的阶段，在每个阶段的间隙，升级工作可以暂停，CC 和 CQ 能正常使用。所以基本不会中断项目的进度。可以选择周末或者晚上来做升级工作。

而这些大的阶段中，还可以划分为更小的步骤。每个步骤都有保证是否升级成功的验证方法。在步骤之间，升级也是可以暂停的。这可以参考 CC/CQ 组件间版本兼容性，在第 4 章详细讨论。

另外，阶段升级策略还包含了备份与恢复的操作，它们属于升级的一部分，为升级的失败提供解决方案，降低升级风险。这在第 3 和第 5 章讨论。

根据图 3 所示的“升级阶段”思路，在表 2 中列出了图 1 部署环境的详细升级步骤以供参考。

在上表中，有几点需要注意：

1. CC Web 的升级本应属于第一和第二阶段的 CC 升级；然而为了确保在升级过程中所有老版本 CCRC 客户端能够不间断正常访问 CC 所有资源，所以把 CC Web 安排到了升级所有客户端之前。这是 2003.06.15 的兼容性要求，对于 7.0.x, 则完全可以把 CC Web 升级放在第一和第二阶段的。请参考第 4 章。
2. 备份工作融入了升级步骤中，遵守“升级哪些服务器就备份哪些服务器”的原则，因此可以分散备份的时间。但是由于在 CC 和 CQ 的集成环境中，CC 的 VOB 和 CQ 的数据库有着很大的关联性，所以为了确保了备份数据的一致性，必须同时备份 CC VOB 和 CQ 数据库。从而所有备份工作被分为了两个大部分：总体准备阶段，分步准备阶段。总体准备阶段指的是在所有升级开始之前的操作；分步准备阶段指的是在升级每个站点 CC/CQ 产品之前的操作。这样安排，各站点之间相对独立开来，能有效地把因准备工作产生的影响降到较低水平。

总之，在以上的升级详细步骤中，每个步骤之间都是可以暂停的，而每个步骤升级和验证的时间基本不会超过 2 个小时；每个阶段的时间从升级到调试成功不会超过 5 个小时。因此，这样的升级方法，能够在不影响项目正常进度的情况下，分阶段完成升级；同时其中的备份工作能够最大限度的保证大量数据的安全性。

当然，以上的升级策略只是一种参考，在了解了每个详细步骤和其中原理的情况下是能够更具需要自行调整的。下面从升级前的准备开始，围绕表 2 的升级步骤展开描述。

3. 升级前的准备

准备工作是为了防止升级过程中，人为操作失误或者不可预测的原因导致重要数据损坏。在“阶段式升级策略”中。准备工作分为两个部分：

（1）总体准备阶段。

在所有站点，停止同步、传输的服务，并手动导入所有剩余的 CC/CQ MultiSite packets。此动作的目的，主要是保证所有 packets 导入，因为新老版本的 packets 格式有可能是不兼容的。兼容性请参考第 4 章。

• 停止同步、传输服务的方法：

暂停系统中和 CC 计划任务中所有和 MultiSite 传输相关的计划。

• 导入 Packets 的方法：

CC 使用命令“multitool syncreplica -import”导入。

CQ 使用命令“multiutil syncreplica –import”导入。

（2）分步准备阶段。

• 备份 CC/CQ 相关数据。备份方法以下分 CC、CQ 两个部分介绍。
• 备份 Web Server
• 检查 CC VOB 的 Schema Version。

3.1 备份 ClearCase 数据

3.1.1 备份 ClearCase 的注册文件

CC 注册文件保存在 CC Registry Server 上（在表 1 中也就是 CC RGY）。它记录整个 CC 站点所有注册信息，包括：VOB Object、VOB Tag、View Object、View Tag、CC Host、Region、Vob Storage Location、View Storage Location 等注册信息。

注册文件实际上是一组普通文件的集合。如果 CC 按默认路径安装，在 Windows 平台上，注册文件位置在 C:\Program Files\Rational\ClearCase\var\rgy 目录下。在 Linux 平台上，注册文件的位置在 /var/adm/rational/clearcase/rgy 目录下。

备份它们只要用系统自带的复制命令，如：xcopy，cp 等，将这个文件夹的内容复制到备份的位置，恢复的时候也只需要将备份的文件复制到原来的位置就可以了。

3.1.2 备份 ClearCase 的 VOB 和 VIEW

VOB 的备份

在介绍 VOB 备份之前，首先需要了解一下 VOB 的存储目录。在 VOB 的存储目录中（如：VOB Storage Location），有很多以 <VOB-TAG>.vbs 命名的文件夹。这个文件夹里面存储的是 VOB 的物理数据，真正的 VOB 数据就在这里面了，所以这就是所说的 VOB 数据库文件。这些文件由于存储于文件系统之上，因此对文件系统有很大的依赖性。例如，Windows NTFS 文件系统会记录文件的 ACL，而 Linux 也会有类似的记录。这些记录不能被手动更改，一旦更改就会导致很多访问 VOB 的奇怪问题，甚至会损坏 VOB。这种损坏有时是很难恢复的。因此，在备份工具的选择上有三点需要特别注意：

① Windows 的备份工具要能够保留 NTFS ACLs 的信息。当然，如果是在 FAT 文件系统上的话就不需要考虑这一点了，因为 FAT 文件系统没有关于 ACLs 的元数据。

②备份工具要能够保留文件的访问时间。

③在 Linux 系统上，推荐使用 cpio 命令。因为无论文件处于什么状态，它能够安全、无遗漏的读取所有 VOB 数据库文件，并保留原有信息，因此是备份 VOB 的最好选择。

以上有关“.vbs”文件更详细的信息，请阅读参考文献。下面介绍 VOB 备份。

备份 VOB 有两种方法，快照（snapshot）和标准（standard），这里介绍后者。

备份的步骤：

①锁定 VOB，即所有用户都不能够访问此 VOB。在 Windows 图形界面上，可以通过 ClearCase Administration Console 来锁定 VOB，或者在命令行的方式下使用 cleartool lock 命令。命令行方式适用于任何平台。

②停止所有 ClearCase 的服务，以保证没有任何内部进程在访问 VOB。

③备份 VOB，将 VOB 的存储目录里面的文件全部都拷贝到备份介质上。

④备份完成后，解锁 VOB。使用 cleartool unlock 命令。

下面是一个命令行方式的示例：

• 锁定 VOB

cleartool lock vob:/cc/vobs/cvob1

• 暂停 CC 服务
• 备份 VOB 存储目录
  • 在 Windows 端使用 xcopy: ( 推荐 )

xcopy d:\vobs\cvob1.vbs c:\vobs\backup\cvob1.vbs /E/O/I

• 在 Linux 端使用 cpio: ( 推荐 )

cd /cc/vobs/
find . /cvob1.vbs/ -print | cpio –o > ~/backup/cvob1.vbs.cpio

• 重启 CC 服务
• 解锁 VOB

cleartool unlock vob:/cc/vobs/cvob1

VIEW 的备份

备份 View 的方法与备份 VOB 相比，相对容易一些，也比较相似。需要注意的是，无论是备份 Dynamic View 还是 Snapshot View，都一定要备份完整，保证一致性。这些对保存 View 中那些 private file 和 check-out file 很重要。以下是备份 View 的命令行示例：

• 查看 View 的存储目录

cleartool lsview –long myview
Global path: /net/svt/viewstg/myview.vws 
... ... 
View on host: mars
View server access path: /viewstg/myview.vws
... ...

• 将 View 变为只读，保证其完整一致性

cleartool chview –readonly myview

• 若是 Linux 系统，查看其“.s”子目录是否连接到其他网络路径。如果链接到其他地方，还要备份那个地方的目录。

cd /viewstg/myview.vws
ls –ld .s
.s -> /net/ccsvr/viewstore/myview.stg

• 备份 View

cd /viewstg/
find . /myview.vws/ -print | cpio –o > ~/backup/myview.vws.cpio
cd /net/ccsvr/viewstore
find . /myview.stg/ -print | cpio –o > ~/backup/myview.stg.cpio

• 恢复 View 的可写性

cleartool chview –readwrite myview

当然，以上 VOB 和 View 的备份都是针对于图 1 描绘拓扑结构的。对于更复杂的情况，例如 VOB 的 Multiple Storage Pool，请参考相关文档。

3.2 备份 ClearQuest 数据

CQ 的数据主要是存放在 CQ DB 中。所以 CQ 的备份包含两个方面：备份 CQ DB；备份 CQ 数据库的连接信息。备份 CQ 遵循以下步骤：

1. 确保 CQ Schema 没有在 Checkout 的状态。如果在 Checkout 状态，请用 ClearQuest Designer 执行“checkin”或者“undo checkout”操作。
2. 使用 ClearQuest Maintenance Tool 的“Export Profile”功能导出 CQ 数据库的连接信息，如图 4。这里有一点需要注意：在 2003.06.15 版本的 CQ 中，连接 IBM DB2 数据库需要安装 IBM DB2 的客户端产品，因此其连接信息是用数据库别名表示的；但是在 7.0.x 中，所有的 DB2 数据库连接都不再需要额外安装 DB2 客户端，也就不再通过 DB2 别名访问数据库，因此老版本连接信息的 profile 文件不能在在新版本 CQ 上用于连接 DB2，连接信息需要手动录入。

1. 备份 CQ DB 数据库。这实际上就是备份数据库，每个产品都不相同。请参考详细数据库产品的备份方法。

3.3 备份 Web 数据

CC 和 CQ 的 Web Server 备份的主要是配置文件，备份方法相同，如下：

• 暂停 Web Server 的服务
• 备份 RWP 配置文件。CC/CQ 版本 2003.06.15，如果产品是安装在默认路径下，则 RWP 配置文件的路径如下：

Windows：
C:\Program Files\Rational\common\rwp\conf
Linux：
/opt/Rational/common/rwp/conf

• 重启 Web Server 的服务

恢复的方法其实就是把 RWP 配置文件拷贝回原路径，这在第 5 章将不在讨论。更加复杂和详细的备份（包括 SSL 的配置备份）请参考相关文档。

3.4 检查 VOB Schema Version

CC 2003.06.15 支持 2 种 VOB Schema Version：53 和 54，与 schema 53 相比，schema 54 具有如下的优势：

• 改良的稳定性。
• 更大的容量：可以处理大于 2G 的字符串文件数据库。
• 加强的安全性以及数据保护。

CC 7.0.0 以上的版本完全抛弃了旧的 schema 53 格式，全部采用了 schema 54 格式，所以必须将现有的 VOB Schema 版本升级到 54。

可以使用“cleartool describe -long vob: <vobtag>”命令来查看 VOB 的 Schema Version，可以使用“cleartool -ver”来确定 VOB Server 当前所用的 Schema Version。

如果你的 VOB 的 Schema Version 是 53，在升级完成之后需使用 reformatvob 命令来升级 Schema Version。请参考第 4 章关于 VOB Schema Version 的讨论。

至此，升级前的准备工作就完成了。以下展开升级的讨论。

4. 升级

4.1 升级方法

4.1.1 产品升级方法

第二章讨论了 CC/CQ 的升级步骤。不过并没有具体介绍针对于每台机器怎样升级。这里将讨论如何升级这些机器上的产品。

升级产品的方式分为两种：

1. 直接升级：在原有版本基础上，直接安装新产品，用新版本自动代替原有版本。
2. 卸载原有版本后重新安装。

第一种方式，升级依照原安装路径安装，原有配置文件依然可以使用，升级快速便捷。但是在版本跨度较大的产品升级时或许存在一定风险的。例如：从 2003.06.15 到 7.0.1 的升级。

第二种方式，在升级过程中，一些原有配置文件也许会被卸载程序清除，因此安装新产品后需要手动恢复。不过，在跨度较大的产品升级时是安全的。

采用第二种方式，升级的过程和安装卸载过程完全相同，可以参考相关安装卸载文档。这里对第一种方式——直接升级方式做出描述：

（1）在 Window 环境中，使用 Desktop Image 的安装方式，直接将 7.0.1 安装盘插入，安装向导会自动选择本机器上已经安装的组件进行升级。如果从 2003.06.15 升级到 7.0.1，在安装向导中，可以修改选择的组件，然后升级；而如果从 7.0.0 升级到 7.0.1，安装向导不会出现组件选择界面，直接升级。

（2）在 Linux 环境中，我们利用 Release Area 安装方式升级，利用 Release Area 的文件直接安装。安装向导也将会自动选择已安装组件，我们也可以增加新的组件，然后升级。

以上的升级方法，对于 CC/CQ 都是适用的。CC 依照以上方法升级完后就可以正常使用了。而对于 CQ，当从 2003.06.15 升级到 7.0.x 后，为了保证新老版本的 CQ 都能够正常连接 CQ DB，需要执行以下几个重要的后续操作：

1. 导入或者重新建立 CQ DB 的连接信息。

当原有版本为 2003.06.15 时，对于 Master DB 为 Oracle 和 SQL Server 的情况，只需要导入原来备份的 profile 文件即可。对于 Master DB 为 DB2 需要重新创建新的连接。这在 3.2 节提到过。

2. 更新 Schema Repository 连接信息。

打开 CQ Maintenance Tool，选择需要更新的连接，然后依次点击 Schema Repository -> Update -> Selected Connection，如图 4。这时候界面就变成了可编辑的状态，修改数据库的连接信息，点击 finish。如果原来的信息是正确的，那么就不需要修改任何字段，直接点击 finish 就可以了。

3. 更新 User DB 属性

打开 CQ Designer，在 Database 菜单中选择 Update User Database Property，如图 5。然后选择要更新的数据库名，确认数据库连接信息，无误后点击 Upgrade，数据库属性就被更新了。

通过以上的步骤和方法，就能够升级每台机器上的 CC/CQ 产品了。另外，在升级中，还有几点需要说明：

1. 在同一台机器上，CC 和 CQ 它们谁先升级没什么影响，但当这两个产品的 Multisite Server 是同一台机器上时，在这台机器上我们必须先升 CC。
2. 在同一台机器上 CC 和 CQ 需是同一个版本。所以在升级的时候，当升级某台机器时，需把此台机器上的 CC 和 CQ 产品同时升级。

4.1.2 ClearCase 数据升级方法

CC 的数据升级包含两个方面内容，VOB Schema 和 Feature Level。前者的升级使得 VOB 对文本文件大小的支持提高到 2GB；后者的升级使得 VOB Container 的大小提高的 2GB。不过，它们的升级在第二章被放在了分开的两个部分，以下分别讨论：

① CC VOB Schema Version 的升级

升级前的准备包含检查 VOB Schema Version 的步骤。如果 Schema Version 是 53 的，就需要执行升级了。升级 VOB Schema Version 必须安排在 VOB Server 升级后立即进行，否则 VOB 是没有办法被 VOB Server 正常访问的。以下是升级的命令行示例：

cleartool reformatvob /cc/vobs/cvob1

需要注意的是：升级 VOB Schema Version 也可以在升级完 VOB Server 前就进行。但是在 VOB 升级前，如果 2003.06.15 的 VOB Server 上的 Schema Version 是 53 的话，是没有办法直接将其 Schema Version 升级为 54 的。除非重新安装 2003.06.15 版本的 CC 产品，并在安装时选择支持 VOB Extension。

② CC Feature Level 的升级

当产品升级到 7.0.x 后，CC VOB 支持的 feature level 5, feature level 5 支持某些元素超越 2GB 的大小限制。如果你想利用 feature level 5 带来的好处，当 CC VOB Server 升级完后，建议将 CC VOB 的 feature level 升为 5。

CC VOB 的 Feature Level 被分为 2 种：VOB Family Feature Level 和 VOB Replica Feature Level。前者指的所有 Site 上同一个 VOB Family 的 Feature Level；后者指的同一个 VOB Family 下，每个 Replica 的 Feature Level。其升级顺序必须遵循：首先逐个升级每个站点的 VOB Replica Feature Level，再升级 VOB Family 的 Feature Level。

现假设 VOB 有两个 Replica：R1，R2，分别在 Master Site 和 Replica Site，以下是升级步骤：

• 准备工作

  确定 VOB 对象的 mastership

  cleartool describe vob:\VOB

  确定 replica 对象的 mastership

  cleartool describe replica:R1@\VOB cleartool describe replica:R2@\VOB

  现假设 VOB 对象的 mastership 在 Mater site, R1 Replica 和 R2 Replica 对象的 mastership 分别在 Master site 和 Replica site。

• 首先升级具有 VOB 对象 mastership 站点的 replica 对象的 feature level, 在这里是 R1 replica 对象

  在 Master Site，升级 R1 的 Replica Feature Level, 并导出 Packets

  cleartool chflevel –replica 5 R1@\VOB multitool syncreplica –export -fship

• 在 Master Site，将 VOB 的 Mastership 传给 Replica Site，并导出 Packets
  

  multitool chmaster R2 vob:\VOB multitool syncreplica –export -fship

• 在 Replica Site，导入 Packets

  multitool syncreplica –import –rec

• 确定 R2 replica 对象的 mastership

  在升级 R2 的 Replica Feature Level 之前，还要确定 replica 对象的 mastership 是否在本 site，这里是在 Replica Site。

  cleartool describe replica:R2@\VOB

• VOB 对象的 mastership 传到 Replica site 后，在 Replica Site 升级 R2 的 Replica Feature Level，并导出 Packets

  cleartool chflevel –replica 5 R2@\VOB multitool syncreplica –export -fship

• 在 Master Site，导入 Packets

  multitool syncreplica –import –rec

  以上是升级 replica Feature Level 的步骤，如果有多个站点，那么要重复上面的步骤。当一个 VOB 在所有站点 Replica Feature Level 都升级完毕了，就可以升级 Family Feature Level。而升级 Family Feature Level 需要 VOB 的 Mastership，因此此时必须把 VOB 的 Mastership 传回要做升级操作的站点。

• 在 Replica Site，将 VOB 的 Mastership 传给 Master Site，并导出 Packets

  multitool chmaster R1 vob:\VOB multitool syncreplica –export -fship

• 在 Master Site，导入 Packets

  multitool syncreplica –import –rec

• 在 Master Site，升级 VOB Family 的 Feature Level，并导出 Packets

  cleartool chflevel –family 5 \VOB multitool syncreplica –export -fship

• 在 Replica Site，导入 Packets。

  multitool syncreplica –import -rec

实际上在每次升级操作后，后续操作都可以中断，继续其它的工作而不影响正常使用，所以可以将 VOB Feature Level 的升级安排在每个站点的 VOB Server 升级之后，然后在所有站点的所有的 VOB Server 升级完后再升级 VOB family 的 feature level。这里为了方便，将其安排在了所有 CC/CQ 升级结束之后。

4.1.3 ClearCase/ClearQuest 集成的升级

CC 和 CQ 的集成包括 Base CC-CQ 集成和 UCM-CQ 集成。集成的配置主要依靠 CCCQ Admin Host，因此集成的升级和这台机器的升级有较大的联系。

在第二章升级策略中，这台机器的升级是属于 CC 升级部分的，因此在 CC 升级后，这台机器的 CC 和 CQ 产品就同时更新到了新版本（7.0.1）。此时，所有 CC 的服务器都是新版本（7.0.1），而 CQ 的其他的服务器和数据库都是旧版本（2006.06.15）。对于 UCM-CQ 集成，此时所有的新老客户端都是可以正常访问 CC VOB 和 CQ 数据库的；对于 Base CC-CQ 集成，推荐把老客户端都升级到 7.0.1 版本后使用。

在这里我们要注意，Base CC-CQ 集成是由 CCCQ Admin Host 上的集中控制脚本完成的，此时这个脚本还处于旧的版本。为了保证以后当其他机器上的 CQ 升级到新版本后能够正常使用集成功能，这个脚本也必须跟新到新的版本。以下是新脚本相关文件的路径：

<CC installed directory>\lib\CQCC
<CC installed directory>\bin\cqcc_launch.bat

把以上的目录和文件拷贝覆盖原来版本的集中控制脚本，并依照原来 config.pl 的配置，重新配置 ..\CQCC\config.pl。

另外，在升级过程中还有以下几个方面需要注意：

1. 当 CQ Feature Level 升级后，旧版本 CC 客户端无法正常运行集成操作，因为旧版本的 CQ Client 无法正常运行。所以在整个升级步骤中，最好采用先升级 CC，后升级 CQ，最后再升级 CQ 数据（包括 Feature Level）的方式，如第二章所述。
2. 对于 Multisite 环境，Base CC-CQ 集成和 UCM-CQ 集成需要在 Master Site 和 Replica Site 分别配置，不能通过同步直接完成 Replica Site 的集成配置。

4.1.4 ClearQuest 数据升级方法

在第二章的详细步骤中，还包括 CQ 数据的升级，分为两个部分：CQ Feature Level 的升级和 CQ Package 的升级，这两者的升级顺序可以颠倒，以下展开描述：

1. Feature Level 的升级

①在升级 Feature Level 时，有几点注意事项：

• 只有客户端升级到 7.0.1 后才能登录 Feature Level 为 6 的数据库。
• 对于 CQ Multisite 来说，从低 Feature Level 站点导出的 packets 可以导入到高 Feature Level 的站点；但从高 Feature Level 站点导出的 packets 不能导入到低 Feature Level 的站点。

当 Master Site 升完 Feature Level 后，Replica Site Feature Level 需在 Replica Site 手动升级，而不是直接从 Master Site 同步实现的。

② Feature Level 升级方式有两种：

• in-place 升级方式，即直接在原来的 Schema Repository 和 User Database 上升级。这样升级的好处是，其它的客户端不用更新 CQ DB 的连接信息，并且升级速度较快。
• 标准升级方式，即创建两个新的空 Database, 升级后的数据转移到这两个 Database 中来，以免破坏原来的 Database，降低风险。但是一旦升级完成后，原来的数据库就会被锁定，不能再被使用。

Feature Level 升级是在 CQ Maintenance Tool 工具中实现，点击 Schema Repository > Upgrade > Selected Connection，按照导航界面对 Master DB 和 User DB 的 Feature Level 进行升级。

③ Multisite 环境中，升级 Feature Level 的详细步骤如下：

• 升级 Master Site 的 CQ Master DB 和 User DB Feature Level
• 升级 Replica Site 的 CQ Master DB 和 User DB Feature Level
• 同步并导入所有 CQ Multisite packets

实际上，Master Site 和 Replica Site 的 Feature Level 可同时升级。

2. CQ Package 的升级

①升级 Packages 有以下几点注意事项：

• 如果把所有 Packages 升级到 7.0.1 的最新版本，也必须把所有的 ClearQuest Clients 升级到 7.0.1 版本，因为 7.0.1 最新的 Packages 有些在旧客户端上可能运行不正常。
• 如果是从早于 ClearQuest 2003.06.00 版本升级，在升级 Packages 时，必须先升级到 2003.06.00 - 2003.06.16 间的一个版本（这里最推荐 2003.06.16），然后再升级到 7.0.1 版本。
• 在 Master site 升级完 Packages 后，只需要同步到 Replica site, 而不是在 Replica site 再次执行 Packages 升级操作。

②升级 Package 的方法：

在 CQ Designer 里实现升级 Packages，以下是两种升级方法：

• 点击 Package > Upgrade Installed Packages，按照向导同时升级所有的 Package；
• 也可以通过点击 Package > Package Wizard，按照向导将某一个 Package 的版本升级到某个版本。

③ Multisite 环境中，升级 Package 的详细步骤如下：

• 升级 Master Site 的 CQ Master DB，并升级 CQ User DB
• 将更新同步到 Replica Site
• 导入 Replica Site 的 CQ Master DB packets，并升级 CQ User DB
• 导入 Replica Site 的 User DB 的 packets

4.2 版本兼容性

为了兼顾从 2003.06.15 到 7.0.x 以及 7.0.x 之间的各种升级路径，同时为了更好诠释阶段式升级策略，下面讨论升级过程中的版本兼容性以及相关的升级注意事项。

4.2.1 ClearCase

（1）Register Server、VOB Server、View Server

从 2003.06.15 到 7.0.1 版本，CC Servers 按照 Register Server、VOB Server、View Server 的顺序，前者的高版本与后者的低版本兼容，但前者的低版本与后者的高版本不兼容。如下表 3 所示。“√”代表兼容，“×”代表不兼容：

对于这几个 CC Servers，有以下几点需要说明：

①因为 Register Server 上有 ClearCase 所有注册信息，所以它需要先升级。从 2003.06.15 升级到 7.0.1 后，如果是 Windows 环境的 Register server，Register server 不需要修改文件；如果是 Linux 环境的 Register server，需要在 /var/adm/rational/clearcase/config/ 目录重新创建 rgy_svr.conf 文件，并在其中写入 Master。

② View server 必须要在 VOB Server 后面升级，因为高版本的 View server 不能兼容低版本的 VOB server。

③从理论上讲，只要遵循 CC 升级策略的顺序，VOB Server 和 View server 升级完毕后，不需要修改任何文件，都可正常运行。

（2）Multisite Server

Multisite Server 的兼容性包含两个方面的内容：shipping server 和 packets。

2003.06.15 版本与 7.0.x 版本的 Shipping Server 是完全兼容的，也就是说使用 shipping server 在站点之间传递 packets 是没有问题的。

Packets 版本的兼容性实际上和 VOB 及其 replica 的 feature level 兼容性有关。在本文的升级策略中，原有 VOB 的 feature level 为 4，并且一直保持不变，没有升级，因此它们产生的 packets 是兼容的。具体的兼容性可以参考 VOB feature level 有关文档。

总之，在 2003.06.15 与 7.0.x 之间各版本的 CC Multisite server 从升级的角度看是相互兼容的。

（3）CCRC、CC Web Server 和其他 CC Servers

对于 CC, 在这里特地介绍 CCRC 客户端、CC Web Server 和其他 CC Servers 间的兼容性。当 CCRC 升级到 7.0.x 版本时，Server 也必须升级到新的版本，旧 CCRC 客户端与新的 7.0.x Server 不兼容；7.0.x 版本的 Web servers 只与 7.0.x 版本的 VOB servers 兼容，所以 Web Server 在 VOB Server 后面升级。CCRC、Web Server 和其他 Servers 间的版本兼容性如下表：

对于 CC Web Server, 还有如下几点需要说明：

①对于 2003.06.15 到 7.0.1 的 Rational 产品，在同一台机器上，这些产品的 Web Server 必须是同一个版本。升级某一个产品的 Web Server 时，也应该升级同机器上其他产品的 Web Server.

②在升级前需要备份 Web Server 的客户化配置文件。对于 2003.06.15 版本的 Rational 产品来说，这些配置文件在 <Rational 产品安装目录 >/common/rwp/conf 目录；对于 7.0 的产品来说，这些配置文件在 <Rational 产品安装目录 >/common/rwp/IHS 目录。一旦升级完毕，需要恢复这些客户化配置文件。

对于本实验环境，由于 Web Server 没有相关的客户化配置，所以对于 Web Server 不需要备份什么文件，升级完毕后，不需要修改任何文件，Web Server 直接就可正常运行。

4.2.2 ClearQuest

（1）Multisite Server

2003.06.15 版本的 Multisite Server 与 7.0.x 的 Multisite Server 不兼容 ; 但 7.0.x 版本间的 Multisite Server 相互兼容。如下表：

（2） CQ Web Server

除了前面 CC Web Server 谈到的内容外，对于 CQ Web Server 还有如下内容需要补充：

① Rational CQ Web 包括两个组件 The Rational CQ Server 和 The Rational CQ Web Application。

② Rational CQ Web server 可能分布在一台、两台或三台机器，如 CQ Server 在一台机器上，CQ Web Application 在第二台机器上，IBM HTTP Server (IHS) 在第三机器上。在进行 Web server 升级时，这三台机器都需要升级。

③在本文实践环境中 CQ Web Server 都放在一台机器上了，当 CQ Web Server 升级完毕后，不需要修改任何文件，在另外一台机器浏览器上进行测试，一切正常。

（3）Feature Level 与 Client 版本兼容性

CQ 的 2003.06.15 版本和 7.0.0.x 版本都只支持 Feature Level 5, 7.0.1 版本支持 Feature Level 5 和 Feature Level 6。Feature Level 与 Client 版本兼容性如下表：

由于当 Feature Level 升为 6 时，只有 7.0.1 版本的客户端运行正常，所以在升级 CQ Feature Level 之前需将 CQ 的所有的客户端都升级到了 7.0.1 版本。

5. 升级后处理

升级以后首先要检查 CQ 和 CC 各个服务的状态，并启动所有的服务，如果所有服务都能正常启动，并且一些基本的操作也都没有问题，那么升级就算成功了，如果遇到服务不能启动的情况，查看系统和应用程序日志，会有很大帮助的，如果一切顺利的话我们就顺利的完成了升级。

虽然，按照以上所述的升级策略，能够保证大部分的升级顺利进行。但是不能否认，任何操作都有可能导致失败。有时是人为的因素，有时是不同系统之间的差异性和兼容性导致的。总之有失败就必然要讨论如何从失败中恢复。这也就是第 2 部分需要备份的原因。

另外，这里指的恢复主要是指数据的恢复，而不包含整个产品的降级安装和回滚。换句话说就是在一个部署、安排、版本和原来完全一样的空白系统中，把原来的数据恢复到备份时的状态。分为两个部分：CC 和 CQ。

5.1 ClearCase 数据的恢复

在第 3 部分，CC 的备份包括三个部分：注册文件、VOB、View。

注册文件的恢复较为简单，在第二部分已经提到，这里不做论述。而 View 的恢复可以参考以下 VOB 的恢复。以下就 VOB 恢复做出讨论：

对应第 3 部分的示例，这里接着通过一个简单的例子来说明恢复 VOB 的过程。

• 第一步和备份 VOB 时相同，要锁住 VOB。

cleartool lock vob:/cc/vobs/cvob1

• 停止所有的 CC 服务

在 Windows 平台 :

控制面板 -> “ClearCase”-> “Services Startup” -> “Stop ClearCase”

在 Linux 平台上 :

/usr/atria/etc/clearcase stop

• 如果准备恢复 VOB 到原始的位置，那么要先删除原始的 VOB 存储目录，因为这个 VOB 是你要恢复的，当前的这个 VOB 也要删除。如果要恢复到不同的目录，这一步就可省略。本文建议删除，以免引起混淆。

在 Windows 平台 :

rmdir d:\vobs\cvob1.vbs\ /S/Q

在 Linux 平台 :

rm –r /cc/vobs/cvob1.vbs/

• 复制你备份的 VOB 文件，到 VOB 的存储位置，这里依然要注意复制的时候要保留文件的访问时间和 NTFS ACLs 信息，很重要。恢复 VOB 到原来的位置不需要注册，并且不需要创建新的 tag，但是，注意，这里只是恢复到相同的 VOB 存储目录，并且 VOB tag 都是相同的，如果使用不同的 VOB Tag 或者存储路径，则还是需要用 register 命令重新注册一下，注册之后还要重新创建一个对应此 VOB 的 Tag。
  • 在 Windows 上使用 xcopy

xcopy c:\vobs\backup\cvob1.vbs d:\vobs\cvob1.vbs /E/O/I

• 在 Linux 上使用 cpio:

cd /cc/vobs/
cpio -imv < ~/backup/cvob1.vbs.cpio

• 检查 VOB。

cleartool checkvob -pool /cc/vob/cvob1.vbs/ 

• 如果这个 VOB 被复制（replica）过，还要运行 restorereplica 命令来恢复 replica 的信息。
• 解锁 VOB

cleartool unlock vob:/cc/vobs/cvob1

5.2 ClearQuest 数据的恢复

ClearQuest 的恢复也包含两个部分，CQ DB 连接的恢复；数据库的恢复。这里只介绍前者。关于后者，涉及到 DB2、Oracle 或者 SQL Server 的数据库恢复，请参考相关文档。

第一种方法是使用之前备份的 profile，使用 CQ Maintenance Tool 将其导入 CQ 中就可以了，如图 7 所示。

6. 总结

至此，大部分和复杂环境升级相关的主要内容介绍完毕。在文章的开头，我们设计了一种假设情况下的复杂部署环境，覆盖了有关集成、产品组件分散部署、多站点三个主要方面。接下来，在准备工作和升级工作中，围绕阶段升级策略展开讨论，并从版本的兼容性以及相关注意事项出发，为升级策略的正确性提供了有力的支持和参考。最后，以升级失败后的恢复收尾，为产品升级中遇到的大部分情况提供了较为完备的参考。

不过，在实际环境中，产品的部署和所假设的环境有很大差别：

1. 多站点的部署不限制在两个站点，而是真正的多站。
2. 每个站点的 CC 和 CQ 部署和集成情况不一定相同，并且有可能和其他产品配合。
3. CC 和 CQ WEB 服务器，尤其是 CQ WEB，为了取得更好的负载平衡，会被拆分的更加细致。（这方面可以阅读参考文档 : 《如何在企业应用中分布部署 IBM Rational ClearQuest Web/Requisite Pro Web 与 IBM HTTP Server》）
4. CC 的 Registry Server 为了保证安全，一般会设置另一台 Backup Registry Server；而 CC VOB 有可能不是部署在 VOB Server 上，而是部署在专门的存贮服务器，例如 NAS 设备上，并且一个 VOB 的 pool 可以分布是部署在不同的机器上；CC 的 VOB Server 有可能是 Windows 的，而客户端有可能包含 Linux。（涉及到不同平台的 CC 服务器部署请参考：《在不同网络环境中 ClearCase 的管理》）；CC 的 View Server 为了更好的管理部署在不只一台服务器上；等等。

由此可以看到，复杂环境的升级和复杂环境的部署其实有很大关系。一方面，由于部署的复杂化，一些其他的用户自定义配置文件在升级准备阶段需要备份（例如：HTTP 服务器的配置文件，CC 和 CQ 日常事务定制文件，等等）。另一方面，升级设计的服务器就不仅仅只是假设环境中那些服务器了。

但是，万变不离其宗——分阶段的升级策略依然是值得参考的。只要明白了为什么采用这种策略，就可以根据需要，自主调整升级方案的细节，参考版本兼容性，完成升级。当然，学习更多关于 CC/CQ 复杂环境部署的文章会利于理解其升级。这方面可以阅读参考文档中的相关文献。

参考资料

• 访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。
• 订阅 Rational Edge 中文版，获取软件开发领域的最佳实践。
• 订阅 IBM developerWorks 时事通讯，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。
• 学习 Hello World 系列教程，这是学习 IBM 软件工具的快速通道。在每一篇教程中，都会有快速入门产品演示动画。您可以通过其中的动画演示快速浏览如何使用 IBM 软件完成开发任务。

• 访问 IBM Rational ClearCase 产品专题，获取最新的 ClearCase 产品文档和信息。
• 访问 IBM Rational 软件交付平台 V7 专题，了解 Rational V7 产品的方方面面。
• 获取免费的 Rational 软件工具包系列，了解最新的 IBM Rational 软件开发工具技术文档和资源。
• 下载免费的 IBM Rational 试用版软件，了解 IBM Rational 软件的最新特性。
• 获取更多 IBM 试用版软件，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。

• 参加 Rational 大学，与 IBM Rational 专家一起分享 Rational 产品最佳实践。
• 查看 developerWorks 博客 并加入 developerWorks 社区。