HBNX软件配置管理服务实施方案

1引言

1.1编写目的

本文针对hbnx目前软件开发的现状，提出如何实现完整的软件配置管理解决方案IBM Rational ClearCase的设计方案。该方案包括系统的实现功能、基本设计思路、实施方案、实施进度安排等，为具体实施提供依据。

1.2背景

信息中心承担着hbnx软件研发的重任，每年担负着几十项软件项目的开发工作。开发中心拟采用大集中方式来进行软件开发环境的整合，建立一个稳定的软件开发平台，对目前及今后的项目进行统一管理。
基于这一目的，通过对信息中心的软件开发现状进行了详细评估和考察，基于考察结果初步定制了一套适合信息中心研发现状的配置管理流程方案，并计划将该方案在整个信息中心开发部进行部署，从而进一步提高部门软件研发的管理水平，提高软件质量和生产率。
通过在信息中心内部各项目团队中部署配置管理工具平台ClearCase，使得所有的项目团队都工作在同一个配置管理平台上，提高工作效率，增强团队内部的沟通。同时将软件资产纳入自动化工具的管理之下，提高软件项目的量化管理水平，帮助管理人员及时了解项目进展的情况，强化项目管理，提高软件质量。

1.3定义

1）软件配置（Software Configuration）
软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。
2）软件配置管理（SCM，Software Configuration Management）
软件配置管理（SCM）是在整个软件生存周期中管理开发过程和软件产品的方法和规程，它标识、定义系统中软件项并指定基线；控制软件项的修改和发行；记录和报告软件项的状态和修改申请；保证软件项的完整性、协调性和正确性；以及控制软件项的储存、装载和交付。

2 系统架构

从系统实现方法来说，配置管理系统是一个基于客户/服务器结构的应用系统，Client端通过网络访问server上的数据，完成对变更管理数据的控制和跟踪的。

2.1 ClearCase系统结构

图1. ClearCase系统结构图

从总的构架来看，ClearCase的环境是一个Client/Server的结构，同时只要配置相应的Web服务器，也可以实现 用Browser方式访问应用。
在设计此方案时，以项目组的开发环境在同一个局域网的环境为前提进行设计的，这种方案以Client/Server结构来描述方案的实现。
在图1中，按照执行的任务的不同划分了相应的角色：

Ø
License Server
是存储License 信息的服务器 ， 负责提供ClearCase License 服务 ；

Ø
VOB Server
是ClearCase 专有只读数据库VOB 的物理存储机 ， 一台VOB Server 可以存储多个VOB ；

Ø
View Server
是ClearCase 工作空间管理机制View 的物理存储机，一台View Server 可以存储多个View 数据库；

Ø
Register Server
是存放ClearCase 各种数据库登录信息的物理存储机；

Ø
NT PDC – NT Primary Domain Controller
是Windows 域用户信息的管理机器；

Ø
NIS Server
是UNIX 用户信息的管理机器；

Ø
Web Server
ClearCase 的Web 功能是通过在Web 服务器上安装IBM Rational 自主开发产品IBM Rational Web Platform(RWP) 实现的。
在实际部署的时候 ， 一台服务器可以担当多个角色 ， 如ClearCase VOB服务器可以作为NIS server ， ClearCase registry server和ClearCase license server。
全部的用户认证系统通过NIS来控制用户可以通过Windows Terminal 方式、Telnet方式和Web方式透过Firewall的固定端口访问ClearCase的数据。

3系统配置

参照图1所描述的系统构架 ， 为保证信息中心在现有开发环境的基础上实施配置管理平台ClearCase ， 环境搭建需要考虑如下方面的因素 ：

3.1安全管理机 制

在ClearCase中，实现了严格的安全访问控制管理。对于“谁”可以对数据访问及访问权限可以进行各种控制。正因为如此，在识别“谁”的举动上，ClearCase以用户名存在的唯一性为判定基础，通过采用Windows域用户和UNIX的NIS用户管理的管理机智，实现对ClearCase各种操作的安全管理。

Ø
Windows 操作环境的用户，需要建立域服务器（PDC ），实现对于Window 环境的用户唯一管理。Windows 域用户由系统管理人员统一进行管理。

Ø
UNIX 操作环境的用户，需要安装并设定NIS 系统，实现对UNIX 的用户唯一性管理。UNIX 的用户帐号及信息管理由系统管理人员进行统一管理。

Ø
对于Windows/UNIX 混合运行环境操作的用户，实现Windows/UNIX 的相同账号管理和主组的设定，统一混合运行环境下的用户统一管理。
总之，对于每一个在信息中心进行开发的人员均进行统一安全认证，每个人都有一个login，该login包括Windows域用户，Unix NIS用户。关于安全性设计的具体内容，请参见“5.安全性设计”部分。

3.2 ClearCase运行环境操作

3.2.1 Windows客户端

ClearCase提供了丰富的、界面极其友好的WindowsGUI访问方式。ClearCase对于Windows客户端用户，提供了多种方便的界面操作方法，即ClearCase专有Explorer操作法、与Windows Explorer集成互动操作法、命令行方式操作法和与各种各样的主流IDEs环境集成操作法。

3.2.2 UNIX客户端

对于大众化的UNIX客户端环境，如AIX、HP、Solaris、Linux、SGI等，ClearCase提供了界面友好的UNIX GUI访问方式，同时也为熟悉命令行操作的UNIX客户用户准备了丰富的命令行操作命令。

3.2.3 Windows/UNIX混合运行环境操作

ClearCase通过不同的操作模式，支持各种类型的混合类型操作。但需要遵循下述互访规则：
Windows/UNIX View 访问Vob数据规则

客户端平台	访问unix上的VOB	访问window上的vob
Windows (dynamic views)	客户端安装第三方NFS 或unix 安装SMB	直接访问
UNIX (dynamic views)	直接访问	不支持
Windows (snapshot views)	通过Clearcase自带的CCFS	直接访问
UNIX (snapshot views)	直接访问	通过Clearcase自带的CCFS

访问Windows /UNIX View使用规则

客户端平台	访问unix上的view	访问window上的view
Windows (Using Dynamic Views)	客户端安装第三方NFS 或unix 安装SMB	直接访问
UNIX (Using dynamic views)	直接访问	不支持
Windows (Using snapshot views)	通过Clearcase自带的CCFS	直接访问
UNIX (Using snapshot views)	直接访问	不支持

3.2.4 对其他平台的支持

对于从事主机系统（OS390）开发的项目，可以使用TSO client和Remote Build两种方式，如果开发人员习惯于从主机进行编码、开发，可以使用ClearCase在主机系统上安装的TSO client对Unix系统上的VOB库进行checkout、checkin版本比较等基本配置管理操作。如果开发人员习惯于在开放系统上进行编码和开发，利用主机进行编译调试，则可以使用Remote Build方式，在Windows/Unix客户端上进行编码，通过Remote Build向主机系统发送需编译的代码，然后在Windows/Unix客户端接收编译结果。
对于ClearCase不支持的其他Unix平台，可以采用ClearCase独特的导出视图方式，利用VOB server作为其他平台的视图服务器，在VOB server 上建立相应的动态视图，然后通过mvfs_export，利用Unix NFS机制将该视图共享给其他没有ClearCase安装的平台，如AS400，Turbo Linux，SCO Unix等其他Unix平台。
另外，如果项目组不在特定Unix平台上进行checkout/checkin操作，可以考虑采用NFS/SMB中间件共享Unix平台上的目录，在Windows平台或其他Rational 支持Unix平台上建立ClearCase静态视图，视图的工作目录建立在Unix共享目录上，这样可以在Rational支持的平台上进行checkout，然后可以在特定Unix平台上进行修改，编译，调试，当达到要求或需要入库时在Rational支持的操作平台上进行checkin。

3. 3 ClearCase工作流程 设计

ClearCase工作流程如下图所示：



图6. ClearCase 配置管理流程

3.3.1 搭建配置管理环境

搭建配置管理环境包括以下步骤：

Ø
建立基础操作系统及网络运行环境
安装ClearCase 软件，保证项目组网段与配置管理服务器网段畅通。

Ø
安装ClearCase 客户端软件。

Ø
规划配置库结构，包括详细的组件划分及目录结构。

Ø
规划用户组，包括项目管理组，开发组以及业务组等。在NIS 服务器、Windows 域控制器中建立相应用户及组。

Ø
在配置管理服务器端建立一个为项目服务的项目管理库（PVOB ），用于存放配置管理元数据。ClearCase 中PVOB 与一个实际的产品相对应，例如网银等建立相应的PVOB 与之对应，而ClearCase 的项目一一对应于实际应用项目，例如网银2.0 开发项目，网银3.0 开发项目对应网银PVOB 下的IB2.0 和IB3.0 项目。

Ø
根据组件数目及逻辑关系等建立组件配置库（Component VOB ）。如果项目内组件数目较多（10 个以上），并且组件规模不大，可以根据一定逻辑关系将其组织到一个component VOB 中；如果组件数目不大（10 个以内）并且组件内文件数量较大，可以为每个组件建立一个component VOB 。

Ø
按照规划的配置库结构准备初始导入文件。

Ø
利用clearfsimport 或CCImportWizard 将初始导入文件导入component VOB 。

Ø
通过Apply Label Wizard 为导入后的文件打一个标签。标签名为“INITIAL_IMPORT_<date> ”

Ø
在ClearCase Explorer 中通过component 文件夹右键菜单中的Import Component 和Import Label 将component VOB 和label 先后引入。

Ø
制订项目策略，确定项目中哪些组件是只读的，哪些是读写的。

Ø
确定ClearCase 并行开发模式，详细参见4.3.2 “ClearCase 并行开发模式”一节。

Ø
在ClearCase Explorer 中通过New project 创建项目（project ），选择项目所用组件，确定组件访问方式（只读/ 读写），并选择并行开发模式。

3.3.2 并行开发模式

根据各个项目的实际情况，可能出现下面几种类型的使用模型，项目经理和配置管理人员从下面几种模型中选择定制合理的ClearCase使用模型。

Ø
每个开发人员一个开发分支/ 开发流
在这种方式下，每个开发人员拥有一个属于自己的开发流，每个开发人员有两个视图：一个为开发视图，用于浏览和修改开发流所选择的文件版本；另一个为集成视图，用于浏览其他人在集成流上提交的工作成果，以及用于提交自己的工作成果。该种使用方式可以达到最大程度的并行性或隔离性，每个开发人员同其他开发人员是彼此隔离的，开发人员在保存文件或检入文件时看不到彼此的更改，从而最大限度避免了其他人员更改所带来的干扰。
当开发人员需要进行文件共享时需要提交他们的修改结果到集成流，该提交动作可以由开发人员从自己的开发流来完成，也可以由系统集成员统一完成。
该种方式优点是开发人员的环境是稳定的，开发人员决定什么时候提交结果，什么时候看到其他人的结果，以及什么时候并入其他人的结果，缺点是每个开发人员处于彼此隔离状态，集成时间可能会加长，集成工作量较大。为了较好地解决这一问题，可以在项目策略中设置“rebase before deliver ”，使每次提交工作成果时同项目开发主线（即集成流）上的版本进行合并。

Ø
多个开发人员共享一个开发分支
在这种方式下，多个开发人员共享一个开发分支，但每个开发人员仍然有两个视图：一个为开发视图，用于浏览和修改所共享的开发流所选择的文件版本；另一个为集成视图，用于浏览其他人在集成流上提交的工作成果，以及用于提交自己的工作成果。
该方式的最大特点是共享一个开发流的多个开发人员可以在检入文件时看到彼此的修改结果，从而在多个开发人员之间实现了集成的最大化。因而此方式比较适于彼此之间需要紧密协作的开发场合，如果彼此立即看到（如果使用动态视图，立即可以自动看到其他人的修改；如果使用静态视图，通过更新也可以看到其他人的修改）检入文件干扰了其他开发人员的工作，则不适宜使用该方式。当该组人员需要与不共享该开发流的其他开发人员进行集成时，仍然通过提交工作成果到集成流来实现。
另外需要注意的是，由于多个开发人员共享一个开发流，如果存在对一个文件的并发修改，容易引起冲突；另外，这种方式也容易引起交付依赖，即一个人改了某文件的版本1 和2 ，另一个人改了同一个文件的版本3 ，4 和5 ，则第二个人不能在第一个人提交成果之前进行提交。也就是说，当出现这种提交依赖时必须以一定次序进行提交。

Ø
所有开发人员共享一个分支
这种方式是所有开发人员使用一个且仅使用一个分支/ 流，也就是集成流，这样每个开发人员只有一个视图，即集成视图，任何开发人员所做的检入，都会很快为其他开发人员所见，这种方式是最大化集成的集中体现，适合整个项目组的各个成员之间需要紧密协作的场合下，一般在项目组规模较小（少于8 人），并行修改很小的场合使用。
这种方法的优点是维护简单，没有deliver 和rebase 操作。缺点是开发人员之间几乎没有隔离性。

Ø
建立多个集成分支
在以上前两种使用方式下，缺省均为一个集成流，集成流下为开发流，只有两层分支结构。但根据情况，可以将某个开发流作为次级集成流，并进而在其下进一步进行分支，从而形成多层分支结构。

Ø
其他用途分支
开发流的设计不一定均以开发人员作为唯一标准，也可以根据需要设立其他用途的开发流，例如构建（build ）流，专门用作从集成流上取基线然后在构建视图中更方便、清晰地进行编译链接等工作。

Ø
项目小组长负责入库方式
以上介绍的开发方式所有开发人员均在使用ClearCase ，但如果项目情况特殊，例如不能大规模部署ClearCase ，或者暂时不能部署ClearCase 等情况时，可以在项目小组长一级进行文件的集中汇总，即各个项目组长使用以上ClearCase 的工作方式，各个开发人员仍然按照原有方式进行开发，然后将工作成果手工传递到项目小组长处，由项目小组长进行检入入库。
在该方式下如果各小组之间冲突不大，可以考虑使用共享一个分支（集成流）的使用方式，因为项目小组长人数较少。

Ø
配置管理员简单入库维护方式
该种方式是上面项目小组长负责入库方式的进一步简化，即只有配置管理员使用ClearCase ，其他人员均按原有方式进行开发，然后将工作成果手工传递到项目配置管理员处，由配置管理员统一进行检入并进行基线标识。

3.3.3 开发人员加入项目，创建开发人员工作视图

通过ClearCase Join Project Wizard来完成。

3.3.4 开发人员在开发空间进行变更

通过checkout、checkin、undo checkedout、find checkedout等操作在ClearCase Explorer、Windows Explorer或命令行窗口中实现。。

3.3.5 开发人员提交工作成果

通过deliver from stream to default来实现。该操作可以在ClearCase Project Explorer中完成，也可以在ClearCase Explorer中完成。

3.3.6 集成人员集成上交结果，建立基线

通过ClearCase Project Explorer实现，具体操作为make baseline。另外当基线达到某种稳定程度后可以使用修改promotion level以及recommended baseline来进行基线提升以及推荐基线标识。

3.3.7 开发/测试人员与项目基线的同步

通过rebase stream来实现实现。该操作可以在ClearCase Project Explorer中完成，也可以在ClearCase Explorer中完成。

3.3.8 配置管理人员进行最终发布版本入库

通过ClearCase findmerge命令或通过ClearCase Merge Manager来实现，具体原理是查找集成流/构造流上的最终测试版本，将其自动并入主干分支。同时，应将构造后的可执行代码一起入库。在完成代码合并后，应建立相应最终发布标签。

3.4 人员角色的统一

ClearCase的流程需要一些人员介入。在此，我们对这些人员做一个统一。
ClearCase流程中的角色 ：

Ø
项目经理

Ø
架构师

Ø
配置管理员（包括组织级配置管理员和项目级配置管理员两个层次）

Ø
开发人员

Ø
集成人员

关于各类角色的职责和相关操作见下表：

角色	职责	相关工具及操作
项目经理或项目管理人员	进行项目级变更请求决策及分配	ClearCase Project Explorer ，创建组件、项目并制定项目策略。
架构师	系统架构设计	分析设计工具
分析设计、开发人员	负责系统的具体分析、设计以及开发，是软件工件的主要生产者	ClearCase Explorer ，执行checkout ，checkin ，比较版本，浏览版本历史，deliver 及rebase 等基本操作。
集成人员	主要负责开发人员交付版本的集成、编译以及初始测试工作	ClearCase Explorer ，ClearCase Project Explorer ，ClearCase diff/merge manager ，主要操作包括比较版本，浏览版本历史，deliver 及rebase ，make baseline ，recommend baseline 等操作。
组织级配置管理人员	负责配置管理环境的搭建和维护。 配合项目经理建立和定制符合开发状况的配置管理流程。 创建、设置VOB 和View 。 备份和恢复ClearCase 的数据存储区。 阶段性维护数据容器 ( 清理VOB 存储池和数据库) 。 安装、监控和管理ClearCase license 的使用。 监控和性能调优。 安装补丁包。 创建组件及项目 审批项目级配置管理员提交的工作申请	ClearCase Explorer ，ClearCase Project Explorer ，以及其他管理工具或命令，可以执行配置管理范围内的所有操作。
项目级配置管理员	建立基线，设置推荐基线， 提交配置管理申请工作单	ClearCase Explorer ， ClearCase Project Explorer ， 主要操作包括make baseline ， recommend baseline 等操作。其他管理工具同组织级配置管理员相同。
系统/ 网络管理员	负责维护配置管理系统赖以运作的基础操作系统平台及网络	各类系统维护工具，创建操作系统用户（包括Unix NIS 用户和Windows 域用户），安装及维护操作系统和网络等等。

以上仅为角色划分，实际上一个人往往担当若干角色，例如项目级配置管理员也往往是集成员。组织级配置管理员也可以担当系统管理员等。

4安全性设计

4.1操作系统及网络安全性要求

ClearCase的安全性依赖于操作系统及网络的安全性，因此保证操作系统及网络的安全性是配置管理系统安全运行的前提。由于在开发中心开发环境较为复杂，而且对于开发客户机的要求较松，建议在所有Windows客户端统一安装反病毒软件，并定期随需更新。整个开发中心与外网应设防火墙进行隔离。

4.2操作系统用户体系

ClearCase直接使用操作系统用户，设立统一的Windows和Unix操作系统管理体系。

l
配置管理系统组
组内成员由开发中心配置管理员组成，主要负责组织级配置管理系统维护使用。

l
项目级管理组
组内成员由项目级配置管理员及项目管理人员组成，主要负责项目级配置管理工作。命名遵循“<项目短名>_adm”的格式。

l
项目级开发组
进行实际项目开发的组，根据需要可以进一步细分，例如对某个配置库具有读权限的组，对该配置库具有写权限的组等。组名规范为<项目短名>+<用途英文缩写>格式，项目大组采用<项目短名>+grp。如****网银项目拟采用以下几个组，即ib_grp（网银项目大组）、ib_adm（网银配置管理组）、ib_dev（网银应用软件开发组）等，关于项目级开发组的设计方法将在“5.3 ClearCase安全性设计”中论述。

同Windows域用户管理相对应 ， 在Unix端利用NIS统一管理所有的Unix系统帐号以及组 ， Windows与Unix用户名相同 ， 但口令设置可以不同。

4.3 ClearCase安全性设计

4.3.1操作系统级权限设置

ClearCase用户权限可分为配置管理超级用户（Windows上为clearcase组用户，Unix上为root），VOB属主，元素属主，元素同组用户等几个层次，权限依次减小，超级用户可以对整个组织内的所有配置库拥有绝对控制权限，VOB属主对所属配置库具有绝对控制权限，元素属主对于所属元素具有完全控制权，而元素同组用户可以co/ci元素版本。
为了方便对配置库的管理，设立一个ClearCase超级用户ccadm，在Windows上该用户属于clearcase超级组，由该用户建立所有的配置库，即该用户为所有VOB的属主，元素属主设为项目级配置管理用户，元素组根据需要设为相应的开发组。
ClearCase的VOB和view存储在操作系统文件系统上，对于该文件系统的权限设置为：
VOB存储的根目录，例如/ibm/rational/ccstg，可设为
Owner: ccadm
Group:ccadm_grp （ClearCase管理组）
Access mode: 700
这样可以有效地防止对配置库的非法或意外破坏，也可以防止代码拷贝。

如果view放在Windows端客户机上，在个人客户机上可以建立一个共享目录，该共享目录的安全权限可以设为只有自己有完全控制权限。

4.3.2 ClearCase VOB级权限设置

在ClearCase VOB上可以设置有权对VOB进行写操作的所有组列表，该操作通过cleartool protectvob 完成，一般情况下，项目级开发库应包含ccadm_grp（clearcase管理组），项目级管理组，项目级开发组等。

4.3.3 ClearCase元素级权限设置

ClearCase元素级访问权限同Unix操作系统文件权限基本相同，分为用户、组及其他三个角色，每个角色均可设置读、写和执行三种权限。
存取模式的含义如下：
7：读和执行（能够进入；可查看目录内容）、写（可创建视图私有文件、目录）
5：读和执行（能够进入；可查看目录内容）
0：无任何权限
例如775意味着属主和属组有全部权限（可进入、可查看内容、可创建私有文件和子目录），other有部分权限（可进入、可查看内容、但不能创建私有文件和子目录）。

在具体设计时首先应明确配置库中的目录结构，其次确定目录的存取访问要求，如哪些人可以对库内记录具有读权限，哪些用户对库内记录具有写权限等。如果存在较为复杂的权限配置要求，如一个配置库某些人具有读权限，但只允许其中一部分人具有写权限，而除此意外的其他人则不具有任何权限，例如网银项目组的所有成员均可以访问IB_App库中的文件，但只有开发组（ib_dev）中的人员可以修改文件，另外不是网银项目组的人员不能访问库中的任何文件。此时应根据需要以被访问对象进行用户组的设计，在库的根目录设置权限为:
owner:ccadm
group:ib_grp （网银项目大组，包含所有网银项目成员）
access mode:770（即除网银项目组以外的其他人员不能访问该库中的文件）
在根目录下的各层子目录则可以设置为
owner:ibadm（网银项目配置管理员）
group:ib_dev（网银项目开发组）
access mode:775（即属于开发组的成员可以修改文件，但只要是网银组的成员都可以读取文件）。
一般情况下目录组织及相关的用户及组权限设置如下表所示：

根目录	一级子目录	二级子目录	三级子目录	属主	属组	存取模式
/XXX				Ccadm	项目大组	770
	/AAA			项目admin	项目具体开发组	775
		/xxxx		项目admin	项目具体开发组	775
		......		项目admin	项目具体开发组	775
	/BBB			项目admin	项目具体开发组	775
		/xxxx		项目admin	项目具体开发组	775
	/CCC			项目admin	项目具体开发组	775
		/xxxx		项目admin	项目具体开发组	775
		......			项目具体开发组	775

元素级权限设置用cleartool protect命令完成，单个文件的权限设置也可以从图形界面下在元素属性对话框中完成。
为了简化元素级权限处理，通过一个post-mkelem-op触发器来进行自动修正，即在加入一个新文件后，该文件的属主自动变为项目级配置管理员，组自动置为项目开发组。

4.3.4利用锁机制限定对象访问范围

ClearCase lock可以从被访问对象角度进行安全性设置，即锁定被访问对象，只允许授权用户进行访问，可以加锁的对象包括VOB、project、stream、version、element、activity、component等。例如为了防止对集成流的修改，可以对集成流（integration stream）和主干（main branch）加锁，只允许配置管理员进行访问，然后所有提交活动由配置管理员完成。

4.3.5利用ClearCase Trigger进行更为复杂的权限控制

当出现上面几种机制无法满足的情况时，可以利用ClearCase触发器trigger来实现，ClearCase触发器可以根据特定事件（如checkin、checkout、目录改名等）进行在事先或事后触发相应处理脚本或可执行程序，从而满足特定需要，例如只允许组内某个（些）具有修改权限，其他人不能进行修改。

利用ClearCase Trigger可以封锁某些重要操作，只允许配置管理员执行。这些重要操作包括：rmelem，rmname，rmproject，rmbl，mkbl，mkproject等。附件一列出了本次实施中用到的trigger的实现过程及参考脚本。

5备份和恢复

配置管理系统管理了企业的所有软件资产以及过程资产，因此其备份工作相当重要，由于配置管理系统建立在操作系统环境上并且同操作系统的用户体系紧密相关，因此在备份时应进行多层次、全面的备份的策略。

5.1备份设施和环境

在备份设施上主要采用磁盘镜像与磁带相结合的方式，镜像磁盘实际上是实际使用磁盘的拷贝，当VOB的存储目录均驻留在一个磁盘上时使用镜像磁盘时可以安全地进行ClearCase VOB的数据复制而不用在数据库上加锁。当一块磁盘损坏时可以快速从镜像盘中进行恢复。
磁带备份机制则提供了更为长久和可靠的备份的策略，定期进行磁带备份可以在整个服务器发生意外时将系统恢复到某个最近的历史状态。

5.2 操作系统用户的备份

由于ClearCase Unix 直接使用NIS用户，ClearCase Windows直接使用Windows域用户，因此对于NIS Master以及Windows域控制器也设计了相应的备份策略。首先设立将VOB server也配置作为NIS Slave，作为NIS Master的备份。另外设立专门的备份域控制器（Backup Domain Controller）作为主域控制器的备份。这种主从备份保证了在主要服务器发生意外时的快速恢复。

另外，为了防止更大的意外，应注意定期将NIS及Windows域的用户导出并备份。

5.3 ClearCase备份和恢复策略

在ClearCase环境中有三种元素需要备份：VOB存储区，视图存储区，以及ClearCase注册信息。以下描述了各种元素的备份步骤。对ClearCase备份的核心是VOB中的数据，由于view只是VOB中某个历史快照，因此此次实施不考虑对view进行备份。

5.3.1 VOB备份软件

由于ClearCase VOB的备份是文件系统的备份，因此备份策略不依赖任何特殊的硬件或第三方备份软件。有可能会有某些变化。欲获得下述各步的详细信息请叁见《ClearCase管理员手册》。

5.3.2 VOB直接备份

由于ClearCase的操作包括对文件和数据库两部分操作，例如checkin一个文件会首先根据文件类型决定如何对文件及其版本进行存储，接着将版本相关信息，如修改人、修改版本、修改时间等记入数据库，因此在对VOB进行备份时一定要保证增量文件系统和数据库之间的一致性，具体实施时就是要在备份前对整个待备份的VOB加锁，保证在备份期间不会出现对VOB的写操作。当VOB被锁住时，虽然VOB是不可访问的、不能执行任何ClearCase操作，但可保证在被锁的时刻VOB的拷贝与初始VOB一致。这意味着在备份时间内开发人员可以访问VOB中的任何文件的任何版本，但不能执行任何ClearCase操作，因为文件是只读的。另外在备份时间内不能执行clearmake/ omake。
根据所选用备份工具是否支持对打开文件的备份，备份策略有所不同，如果备份工具支持对打开文件的复制，则VOB备份策略包含以下三步：

l
锁住VOB

l
将VOB 拷贝到磁带上

l
解锁VOB

如果所使用的备份工具不支持对打开文件的备份 ， 则可采用另外的备份方法 ： 在VOB server上停止ClearCase ， 拷贝VOB内容 ， 然后在VOB server上重新启动ClearCase。

l
锁住VOB

l
停掉ClearCase VOB 服务器上的服务器进程

l
将VOB 拷贝到磁带上

l
重新启动ClearCase VOB 服务器上的服务进程

l
解锁VOB

5.3.3从VOB拷贝执行备份

这种备份策略与第一种的差别在于它有缩短的锁定时间的优点，包括四步：

l
锁住VOB

l
将VOB 存储目录拷贝到本地磁盘或其他计算机磁盘，由于VOB server 采用了镜像磁盘，实际上磁盘镜像就是VOB 存储目录的拷贝

l
将VOB 拷贝到磁带上

l
解锁VOB

因为将VOB存储目录拷贝到本地磁盘所花费的时间较少， VOB的锁定时间也相应减少，但带来了额外的需要存储VOB存储区的临时拷贝的磁盘空间的开销。

5.3.4 视图备份

在实施中不设立专用的视图服务器，视图驻留在客户开发机上，开发人员负责对自己视图中私有文件，文件的检出拷贝，以及已构建的本地二进制文件的安全。

5.3.5 注册信息备份

对注册信息的备份应与VOB备份同步进行(在VOB锁定时间内)以保证环境的一致，备份的频率应至少与VOB备份相同。

6性能监控及其他维护

6.1并发访问用户数的确定

ClearCase的license数目与实际用户数之间的比例平均大约为1:4，或1:5，高峰期间可能会更高，达到1:3，1:2。

6.2 ClearCase性能监控及调节

本节描述了用来改进ClearCase性能的监控和调节技术。因为ClearCase是分布式的软件，所以应当监控和调节三方面的内容：ClearCase Servers，Client机器和网络设施。
通常情况下应把VOB Server机器上的磁盘访问减少到最小，意味着应在内存中驻留尽可能多的VOB数据库页。对client机器，意味着应保持适当尺寸的MVFS和视图缓存。

6.2.1服务器性能

l
进程负载
最佳的VOB server是只服务于ClearCase VOB操作的独占的服务器。其他的非VOB进程会竞争内存、磁盘I/O和CPU资源。将其他的非ClearCase应用程序置于同一系统上将会使管理员难于决定造成性能瓶颈的原因并解决这些原因。
ClearCase VOB server不应置于作为网络主域控制器或备份主域控制器的NT server之上(PDC或BDC)。也不应安装其他第三方的比如Oracle或SQL Server的数据库，不允许普通用户直接登录到VOB server去工作，VOB server也不应当是其他数据的服务器如用户的主目录，email server(非exchange, POP server)，web server (非IIS/PWS, Apache等)，不应当是其他应用程序的gateway机器或proxy server。

l
VOB 大小
下面是创建VOB时的一些指导原则：
避免一台机器有太多的VOB。因为一台机器只有一个lockmgr进程来为该机上的所有的VOB服务。此条仅适用于单一服务器上可能容纳超过50个VOB的非常大的环境。
每个VOB拥有少于8000个的元素。
避免目录下包含多于300个元素。超过600个元素就会造成显著的性能下降。
当VOBs增长得过快并超过了上述原则时就会引起client访问性能的下降。对大规模的ClearCase实现可以增加另外的VOB servers机器。

l
VOB Server 内存
理想的VOB server应当有足够的RAM以有效地利用块缓冲区存储VOB数据。

6.2.2 Client性能

开发人员应尽可能的确保自己计算机的稳定和高性。

7配置报告

配置报告是获取项目状态、准确及时进行项目管理的重要手段。配置报告由一系列衡量指标及报告组成，其中最常用的包括基线类报告、元素类报告等。下面分别举例说明其设计方法。

7.1 基线类报告

基线类报告通过ClearCase Report Builder来完成，常用的基线类报告有基线及所包含开发活动统计报告，从该报告可以列出每条基线中包含的开发活动，例如某个补丁包中修复的所有缺陷有哪些。

简要步骤如下：

l
在Report Builder中选择baseline

l
选择报告样式及报告类型

l
选择需统计的基线所在的流

l
运行报告，得到结果

Report Builder中的报告可以转存为.html格式进行打印或发布。

7.2 元素类报告

元素类报告通过ClearCase Report Builder来完成，常用的元素类报告有文件历史版本统计报告，特定类型（如文本文件、图形文件等）文件统计报告，某开发人员所修改的文件报告等。这些报告可以进行针对配置项（主要指文件和目录）的变动统计。

简要步骤如下：

l
在Report Builder中选择element

l
选择报告样式及报告类型

l
选择查询条件

l
运行报告，得到结果

Report Builder中的报告可以转存为.html格式进行打印或发布。

8 实施进度安排

工作内容	说明	周期
环境准备	机房环境准备 ClearCaset服务器准备 Nis和AD环境准备 网络环境准备	约1周
系统安装	ClearCase安装配置 按照设计方案进行配置和编写脚本 测试	约2周
试点项目	项目组环境评估 项目组现场培训 数据导入（代码、文档） 系统配置 跟踪系统运行情况，进行系统优化	不少于2个月
培训	管理员培训： Rational ClearCase Unified Change Management Mastering Rational ClearCase Administration	1周

$(document).ready(function(){dp.SyntaxHighlighter.HighlightAll('code');});

原文链接：
http://blog.csdn.net/jaminwm/article/details/4538873