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 |
直接访问 |
不支持 |
|
Windows (Using snapshot views) |
通过Clearcase自带的CCFS |
直接访问 |
|
UNIX |
直接访问 |
不支持 |
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 |
|
|