软件配置管理策略与Rational ClearCase (2008 年度畅销榜NO.476 )

软件配置管理（SCM）是一项基本的软件工程任务，用于管理当今复杂和快速发展的软件开发环境。\r\n\r\n 本书是一本综合而实用的软件配置管理指南，以市场上最流行的SCM工具Rational ClearCase作为示范工具。作者首先讲解了基础知识，然后展示ClearCase如何通过统一变更管理（UCM）模型实现SCM的最佳经验。本书清晰地展示了如何通过ClearCase简化和控制软件开发项目中的变更。本书并没有停留在基础知识层面，针对现实生活中的真实开发场景，讲解了很多高级技术专题，例如管理多个项目以及管理分布在不同地域的项目。\r\n\r\n 本书讲述的众多经验、技巧和见解来自于发掘和应用SCM最佳经验的工程实践，书中贯穿了众多精妙的见解和富有价值的建议。作为一本出色的配置管理书籍，本书适合于软件工程师和软件项目管理人员阅读参考。\r\n
\r\n

第一章 什么是软件配置管理 1 \r\n\r\n 1.1 SCM的最佳经验 2 \r\n\r\n 1.1.1 统一标识工件并存入安全的存储池 3 \r\n\r\n 1.1.2 控制和审计工件的变更 3 \r\n\r\n 1.1.3 将工件组织为具有版本的构件 4 \r\n\r\n 1.1.4 在项目的里程碑建立相应的基线 5 \r\n\r\n 1.1.5 记录和跟踪变更请求 5 \r\n\r\n 1.1.6 通过活动组织和集成一致的版本集合 5 \r\n\r\n 1.1.7 维护稳定而一致的工作空间 7 \r\n\r\n 1.1.8 支持对工件和构件的同步变更 8 \r\n\r\n 1.1.9 及早和经常地集成 8 \r\n\r\n 1.1.10 确保有能力重现软件的构建过程 9 \r\n\r\n 1.2 SCM工具和流程 9 \r\n\r\n 1.2.1 SCM工具 9 \r\n\r\n 1.2.2 SCM流程 10 \r\n\r\n 第二章 找到你的SCM解决方案 11 \r\n\r\n 2.1 应对不断变化的项目需求 11 \r\n\r\n 2.1.1 软件系统的复杂性增长 12 \r\n\r\n 2.1.2 项目环境的复杂性增长 13 \r\n\r\n 2.1.3 变化的生命周期阶段 15 \r\n\r\n 2.1.4 流程和人员的变化 15 \r\n\r\n 2.2 SCM工具的发展 16 \r\n\r\n 2.2.1 五种类型的项目团队 18 \r\n\r\n 2.2.2 如果没有SCM工具 19 \r\n\r\n 2.2.3 早期SCM工具的支持 22 \r\n\r\n 2.2.4 现代SCM工具支持 27 \r\n\r\n 2.2.5 高级的SCM工具支持 34 \r\n\r\n 2.3 小结 35 \r\n\r\n 第三章 统一变更管理模型概述 37 \r\n\r\n 3.1 什么是UCM? 37 \r\n\r\n 3.2 什么是ClearCase? 38 \r\n\r\n 3.3 ClearCase UCM过程概述 39 \r\n\r\n 3.3.1 系统构架师（The Architect） 40 \r\n\r\n 3.3.2 配置经理（The Configuration Manager） 40 \r\n\r\n 3.3.3 项目经理（The Project Manager） 40 \r\n\r\n 3.3.4 开发人员（The Developer） 41 \r\n\r\n 3.3.5 集成员（The Integrator） 41 \r\n\r\n 3.4 系统构架师：定义实施模型（Implementation Model） 41 \r\n\r\n 3.4.1 ClearCase构件 42 \r\n\r\n 3.4.2 UML中的构件 42 \r\n\r\n 3.5 配置经理：建立SCM环境 44 \r\n\r\n 3.6 项目经理：管理项目 44 \r\n\r\n 3.7 开发人员：加入项目并进行开发 45 \r\n\r\n 3.8 集成员：集成. 构建和发布 46 \r\n\r\n 3.8.1 发布构件 46 \r\n\r\n 3.8.2 系统集成 46 \r\n\r\n 3.8.3 发布系统 47 \r\n\r\n 3.9 基线＋变更模型 47 \r\n\r\n 第四章 ClearCase对象功能概述 51 \r\n\r\n 4.1 存储池：版本对象库 51 \r\n\r\n 4.2 工作空间：快照视图和动态视图 53 \r\n\r\n 4.2.1 快照视图 54 \r\n\r\n 4.2.2 动态视图 54 \r\n\r\n 4.2.3 快照视图和动态视图的差异 57 \r\n\r\n 4.3 项目管理：项目. 工作流和活动 58 \r\n\r\n 4.3.1 项目（Project） 58 \r\n\r\n 4.3.2 工作流 59 \r\n\r\n 4.3.3 活动 60 \r\n\r\n 4.4 版本对象：元素, 分支和版本 62 \r\n\r\n 4.4.1 目录版本 63 \r\n\r\n 4.4.2 元素类型 64 \r\n\r\n 4.5 构件管理：构件和基线 65 \r\n\r\n 4.6 过程：标签. 属性. 超链. 触发器 66 \r\n\r\n 4.6.1 标签（Label） 66 \r\n\r\n 4.6.2 属性（Attribute） 67 \r\n\r\n 4.6.3 超链（Hyperlink） 67 \r\n\r\n 4.6.4 触发器（Trigger） 67 \r\n\r\n 4.6.5 创建和管理类型 68 \r\n\r\n 4.7 构建：clearmake. 派生对象. 配置记录 69 \r\n\r\n 4.7.1 构建审计 69 \r\n\r\n 4.7.2 对象共享 69 \r\n\r\n 4.7.3 并行和分布的构建 69 \r\n\r\n 4.7.4 Clearmake同传统make比较 70 \r\n\r\n 第五章 建立初始的SCM环境 71 \r\n\r\n 5.1 ClearCase构架基础配置 71 \r\n\r\n 5.1.1 许可证服务进程和注册服务进程 72 \r\n\r\n 5.1.2 VOB服务进程和视图服务进程 72 \r\n\r\n 5.1.3 ALBD服务器和客户端进程 74 \r\n\r\n 5.1.4 多版本文件系统（Multiversion File System） 74 \r\n\r\n 5.1.5 硬件配置举例 75 \r\n\r\n 5.2 ClearCase硬件资源要求 78 \r\n\r\n 5.2.1 内存要求 78 \r\n\r\n 5.2.2 磁盘I/O要求 79 \r\n\r\n 5.2.3 网络带宽（Bandwidth）和可靠性（Reliability） 79 \r\n\r\n 5.2.4 CPU 80 \r\n\r\n 5.2.5 其他建议 80 \r\n\r\n 5.2.6 用户. VOB和视图限制 82 \r\n\r\n 5.2.7 VOB规模的考虑 82 \r\n\r\n 5.3 定义实施模型（Implementation Model） 83 \r\n\r\n 5.4 创建VOB 84 \r\n\r\n 5.4.1 使用命令行界面创建PVOB 84 \r\n\r\n 5.4.2 使用图形用户界面创建PVOB 85 \r\n\r\n 5.4.3 使用管理型VOB 86 \r\n\r\n 5.4.4 使用命令行界面创建VOB和构件 88 \r\n\r\n 5.4.5 使用图形化用户界面创建VOB和构件 88 \r\n\r\n 5.4.6 导入现存源代码 90 \r\n\r\n 5.5 基线晋升级别（Promotion Level） 91 \r\n\r\n 第六章 使用ClearCase的项目管理 93 \r\n\r\n 6.1 ClearCase项目是什么 93 \r\n\r\n 6.1.1 谁在做变更 93 \r\n\r\n 6.1.2 什么在变更 94 \r\n\r\n 6.1.3 如何进行变更 94 \r\n\r\n 6.1.4 变更如何流转并被集成 94 \r\n\r\n 6.2 创建ClearCase项目 95 \r\n\r\n 6.2.1 识别项目经理 95 \r\n\r\n 6.2.2 识别构件和基线 95 \r\n\r\n 6.2.3 定义项目制度 96 \r\n\r\n 6.2.4 为项目选择存储位置 101 \r\n\r\n 6.2.5 创建项目 101 \r\n\r\n 第七章 协调多个项目组以及其他场景 105 \r\n\r\n 7.1 组织大型的多项目开发工作 105 \r\n\r\n 7.1.1 面向构架的项目团队 105 \r\n\r\n 7.1.2 面向特性的项目团队 106 \r\n\r\n 7.2 协调合作的项目：独立的构件 107 \r\n\r\n 7.2.1 项目创建 107 \r\n\r\n 7.2.2 迭代计划（Iteration Plan） 107 \r\n\r\n 7.2.3 集成（Integration） 108 \r\n\r\n 7.3 协调合作的项目：共享的构件 109 \r\n\r\n 7.3.1 项目创建 110 \r\n\r\n 7.3.2 迭代计划 110 \r\n\r\n 7.3.3 集成 111 \r\n\r\n 7.4 协调多个并行的发布版本 112 \r\n\r\n 7.4.1 接续项目 112 \r\n\r\n 7.4.2 主线项目 113 \r\n\r\n 7.5 协调IS/IT开发项目 116 \r\n\r\n 7.5.1 选择要开发的特性 118 \r\n\r\n 7.5.2 贯彻审批流程 118 \r\n\r\n 7.5.3 执行紧急修复Bug 118 \r\n\r\n 7.5.4 计划一个主发布版本 119 \r\n\r\n 7.6 协调文档项目或者小项目组 119 \r\n\r\n 7.6.1 项目创建 120 \r\n\r\n 7.6.2 加入一个项目 120 \r\n\r\n 7.6.3 交付变更 120 \r\n\r\n 7.6.4 更新工作空间 121 \r\n\r\n 7.6.5 创建基线 121 \r\n\r\n 7.7 脱离基于活动的SCM使用UCM 121 \r\n\r\n \r\n\r\n \r\n\r\n 第八章 使用ClearCase UCM模型进行开发 123 \r\n\r\n 8.1 开发人员的UCM视角 123 \r\n\r\n 8.2 加入一个项目 124 \r\n\r\n 8.3 进行变更 126 \r\n\r\n 8.3.1 用活动来组织工作 126 \r\n\r\n 8.3.2 修改文件及目录 127 \r\n\r\n 8.3.3 通过命令行进行工作 128 \r\n\r\n 8.4 交付变更 129 \r\n\r\n 8.4.1 检入所有未完成的检出元素 129 \r\n\r\n 8.4.2 变基到项目最新的推荐基线 131 \r\n\r\n 8.4.3 执行ClearCase交付命令 131 \r\n\r\n 8.4.4 对交付结果进行构建并测试 132 \r\n\r\n 8.4.5 完成或撤消交付 133 \r\n\r\n 8.5 变基你的开发流 133 \r\n\r\n 8.5.1 运行变基操作 134 \r\n\r\n 8.5.2 构建并测试 135 \r\n\r\n 8.5.3 结束或撤消变基 135 \r\n\r\n 8.6 处理变更冲突 135 \r\n\r\n 8.6.1 交付场景1（没有冲突） 135 \r\n\r\n 8.6.2 交付场景2（没有冲突） 136 \r\n\r\n 8.6.3 交付场景3（有冲突） 136 \r\n\r\n 8.6.4 变基场景1（没有冲突） 137 \r\n\r\n 8.6.5 变基场景2（有冲突） 137 \r\n\r\n 8.6.6 ClearCase合并工具 138 \r\n\r\n 第九章 集成. 构建与发布 141 \r\n\r\n 9.1 软件集成 141 \r\n\r\n 9.1.1 合并集成 141 \r\n\r\n 9.1.2 组装集成 142 \r\n\r\n 9.1.3 不同规模开发组的集成情况 142 \r\n\r\n 9.2 使用ClearCase进行隔离和集成 145 \r\n\r\n 9.2.1 共享视图——无隔离开发 145 \r\n\r\n 9.2.2 分支/最新开发——最大化集成 146 \r\n\r\n 9.2.3 使用分支来进行隔离和集成 149 \r\n\r\n 9.2.4 使用UCM的集成 151 \r\n\r\n 9.3 使用ClearCase UCM来构建和建立基线 154 \r\n\r\n 9.3.1 锁住集成流 155 \r\n\r\n 9.3.2 为软件构件建立基线 156 \r\n\r\n 9.3.3 构建软件构件 157 \r\n\r\n 9.3.4 执行冒烟测试 158 \r\n\r\n 9.3.5 提升软件构件基线 158 \r\n\r\n 9.3.6 将集成流解锁 158 \r\n\r\n 9.3.7 夜间构建过程的自动化 159 \r\n\r\n 9.3.8 在项目之间移动变更 159 \r\n\r\n 9.4 进阶（staging）和版本发布 159 \r\n\r\n 9.4.1 商业软件 160 \r\n\r\n 9.4.2 嵌入式系统 160 \r\n\r\n 9.4.3 互联网站 161 \r\n\r\n 9.4.4 内部软件构件 162 \r\n\r\n 第十章 地域上分布的开发 163 \r\n\r\n 10.1 分布式开发的挑战 163 \r\n\r\n 10.1.1 组织 164 \r\n\r\n 10.1.2 通信 164 \r\n\r\n 10.1.3 技术 165 \r\n\r\n 10.2 ClearCase如何支持分布式开发 166 \r\n\r\n 10.2.1 远程访问 166 \r\n\r\n 10.2.2 Web访问 167 \r\n\r\n 10.2.3 断网使用 168 \r\n\r\n 10.2.4 本地访问 168 \r\n\r\n 10.2.5 什么是ClearCase MultiSite 169 \r\n\r\n 10.3 多开发组：生产者/使用者模式 170 \r\n\r\n 10.3.1 支持生产者/使用者开发组 173 \r\n\r\n 10.3.2 UCM如何支持生产者/使用者模型 173 \r\n\r\n 10.3.3 基本ClearCase（Base ClearCase）如何支持生产者/使用者模型 173 \r\n\r\n 10.3.4 总结 175 \r\n\r\n 10.4 多开发组：共享源代码 175 \r\n\r\n 10.4.1 UCM如何支持共享代码 177 \r\n\r\n 10.4.2 基本ClearCase如何支持共享代码使用方式 178 \r\n\r\n 10.4.3 总结 179 \r\n\r\n 10.5 单一开发组：分布式成员 179 \r\n\r\n 10.5.1 UCM模型如何支持本地访问 180 \r\n\r\n 10.5.2 基本ClearCase如何支持本地使用 180 \r\n\r\n 10.5.3 基于活动的分支 183 \r\n\r\n 10.5.4 总结 184 \r\n\r\n 10.6 ClearCase MultiSite的其他用途 184 \r\n\r\n 10.6.1 使用MultiSite来进行备份 184 \r\n\r\n 10.6.2 使用MultiSite来进行交付 185 \r\n\r\n 10.6.3 使用MultiSite进行跨平台互操作 185 \r\n\r\n 第十一章 变更请求管理和ClearQuest 187 \r\n\r\n 11.1 什么是变更请求管理 187 \r\n\r\n 11.2 什么是变更请求？ 188 \r\n\r\n 11.3 变更请求管理过程 188 \r\n\r\n 11.3.1 提交 189 \r\n\r\n 11.3.2 评估 189 \r\n\r\n 11.3.3 决策 190 \r\n\r\n 11.3.4 实现 190 \r\n\r\n 11.3.5 验证 191 \r\n\r\n 11.3.6 完成 191 \r\n\r\n 11.4 什么是ClearQuest？ 191 \r\n\r\n 11.5 我怎样使用ClearQuest的数据？ 193 \r\n\r\n 11.5.1 查询 194 \r\n\r\n 11.5.2 报告 195 \r\n\r\n 11.5.3 图表 195 \r\n\r\n 11.6 ClearQuest如何支持UCM？ 198 \r\n\r\n 词汇表 201 \r\n\r\n 参考文献 215 \r\n
\r\n

作为Rational Software配置管理业务部门的总工程师, 我很高兴能够致力于一个令人着迷的问题：如何“正确做”软件配置管理.

当我作为一个大学生在Harvard University学习数学时, 第一次体会到“正确做”的利害. 我的大一数学教授是一个35岁的研究生, 他总想解出一道题, 一个有一个世纪历史的和充满数学内容的小难题, 即四色问题. 他的收益是每天一起床就明确地知道要做什么. 他受害的一面是一直作了十五年的研究生. 实在值得庆幸, 在那年的晚些时候我第一次接触到软件工程（那时候我们仅称之为编程）, 彻底消除了我走上他那条危险道路的风险. 编程曾是带有内在正反馈机制的数学. 当你的试验（程序）正确之后, 你不仅能够得到智力上的满足, 而且很多公司还会争相为这些有意思的东西大笔地付钱.

但是后来到研究生院之后, 这种正反馈机制开始崩溃. 在那时, 我所做的软件系统中并入了大量不同程序员编写的文件, 有些人的工作时间比我还没有规律. 我无法专著于编写精妙的算法, 而是要花费大量时间搞清楚别人完成了什么工作并且让他们知道计划要做的事情. 这样一来, 不仅智力上的满足感大打折扣, 而且, 每样东西都要花费更长的时间去构建, 进而那些提供赞助的机构对日益迟缓结果的投资热情越来越低.

这也就变成了我的四色问题：找出一个流程, 程序员作为团队一员如同自己独立工作一样有效率. 通过引入管理变更制度与工序来解决问题的尝试的确使流程更可预测并且减少了特定类型的错误, 但是也付出了代价, 智力上的满足被进一步降低, 同时降低了编程的生产率.

一线希望的曙光来自于一个巧妙的小程序, 称为“make”. 不要求制度和工序. 只需用文件系统的时间戳与成为通用代码的“makefile”, 来自大量程序员的工作结果就能够被编译得可靠和有效率, 如同来自一个独立工作的程序员. 找出能降低甚至消除团队开发中管理负担的类似工具成为一个挑战. （边注：在那个时期, 四色问题终于被解决了, 不过是借助于计算机程序. 很明显, 一些数学问题只有借助计算机的帮助才比较容易解决. ）

在Inference Corporation, Sun Microsystems, Hewlett-Packard, 和Bell-core, 经过对软件配置管理问题十年的研究, 我有机会发现并实现一些自动化软件配置管理的关键组成部分. 后来, 在1995年11月, 我被邀请加入Atria Software, 作为“ratbert”的项目主管, “ratbert”是项目的代号, 该项目针对基于ClearCase的流程自动化处理层.

我加入Atria之后的早期工作是设计一个直接可用的（out-of-the-box）流程, 该流程将用于流程自动化产品. 最初被指派实施该流程的销售工程师就是口才很好的Brian White. 让销售机构的人负责实施新产品中的关键部分看起来有点儿奇怪, 但是不久的事实说明, Rational的销售工程师是SCM流程的世界级专家. 他们的工作就是去造访全世界大多数成熟的软件开发机构, 了解这些机构如何进行软件开发, 然后告诉他们如何用ClearCase自动化处理他们的流程. 我们需要最好的销售工程师帮助我们的项目, Brian就是这个人选.

针对直接可用流程的最初设计会议在Dave Leblang（ClearCase的首席构架师）即将完工的新居中召开. 成功创业者新宅的竣工意外地被休止了一下, 他的豪宅是爱尔兰风格的石体建筑, 使用花岗岩作露台的墙, 用于填充后花园的土足足有40车. 不管怎么说, 直接可用的流程逐渐成形了.

尽管我们很快就将注意力集中于流程中的关键要素, 还是出现了两种不同的观点. 一种观点认为每一个开发机构都很不相同, 无论我们开发出什么样的流程, 都只能作为一个初始的代码, 开发机构在此基础上进行大量的修改. 另外一种观点认为, Brian与我也这样看, 如果流程能够设计得易于定制, 那么大范围的开发机构可以共享同一种类型的流程. 有一个事实能够很好地支持第二种观点, ClearCase销售工程师总要开发一些标准的脚本程序, 他们在一个新的开发机构使用这些脚本时只进行很少的改动. 我个人的经验同样支持第二种观点, 大多数流程之间的差异源于底层工具的支持（不同）, 当工具能够全面支持关键SCM功能时, 不同流程中那些明显的共通内容可以适用于大范围的开发机构.

在ClearCase的最新发布版本中, 这种通用流程的观点被实现为“统一变更管理”的流程（Unified Change Management, 即UCM）. 对于“统一变更管理”的支持包括流程和工具两个方面（例如新的对象. 操作. 以及图形化用户界面）. 尽管工具对流程的支持将进一步发展, 但是, 我相信这种通用的流程将成为软件配置管理的标准. Brain White这本书, “软件配置管理策略和Rational ClearCase(r)”, 为理解和采用这一流程提供了基础.





Geoffrey M. Clemm 博士

Rational Software Corporation





中文版序言

随着社会的不断进步, 软件已经成为了整个社会信息化的基础, 如何按时开发出高质量的软件成为信息化中的一个重要课题. 目前, 产业界已经充分意识到, 传统的手工业作坊式的软件开发方式不适用了, 必须在软件开发过程中引入工程化的思想, 即必须全面实施软件工程.

软件工程的本质是保证团队的有效沟通. 协作与总结：沟通是为了保证团队成员对某个有待解决的问题达成一致的认识, 协作是保证在解决某个问题的过程中, 团队成员可以有效配合. 避免冲突, 以提高工作效率, 总结是对某个项目的开发过程进行量化分析, 从而可以将该项目累积的最佳经验捕获下来. 配置管理的目的是通过有效的管理软件开发过程的所有输出（工件）以及对它们的变更, 来保证团队的有效协作, 配置管理是实施软件工程的基础.

本书中介绍的配置管理方法 - UCM（统一变更管理）可以说是第三代的配置管理方法, 下面我们首先对配置管理方法的发展作一个简单回顾, 在简述以下UCM的发展历程：

第一代—手工管理：由配置管理员在文件系统的基础上, 用目录的方式来手工管理版本, 开发人员在完成纸面的审批流程之后, 从配置管理员处获得工件的特定版本, 修改后在提交给配置管理员,

第二代—版本+变更管理：利用工具来实现第一代手工管理的流程, 配置管理员利用工具提供的多版本文件系统或数据库来管理版本, 开发人员可以利用电子流来完成审批过程之后, 可以在工具提供的工作空间里来完成工件的修改工作.

在实施第二代配置管理方法的过程中, Rational作为全球最大的配置管理工具供应商, 敏锐地意识到, 有一些最佳经验（Best Practice）不断在不同的客户实施配置管理的过程中, 在付出高昂代价之后, 被重新发明. 因此, Rational提出了第三代的配置管理方法 - UCM, 将这些最佳经验固化其中.

本书的作者Brian White先生是Rational公司在配置管理方面的大师, 本书的译者尤克滨和李季华, 是Rational中国公司的员工, 他们在工作过程中参与了许多企业的配置管理实施工作, 积累了大量丰富的经验, 另一位译者王宁, 是Rational一家用户的SEPG负责人, 同样具有丰富的实践经验. 因此, 我相信, 这本书对于奋斗在信息化建设第一线的项目经理. 质量经理. 配置经理们是一本不可多得的实战指南, 同时也能够为大学生或研究生教育提供一本非常好的教材. 为了保证这本书的质量, 译者在繁忙的日常工作之余, 利用自己的业余时间完成了翻译工作, 为中国的软件工程事业献上了一份珍贵的礼物, 我在此深表敬意！！

借此机会, 作为Rational公司的第一名中国员工, 我想对Rational在中国的事业做一个小结, 仅仅是小结, 因为, 未来会更辉煌. Rational Software中国公司北京代表处成立于1999年10月21日, 三年来, Rational的客户群从单纯的外企研发机构发展到遍布国内通讯设备制造商. 银行. 保险公司. 电信运营商. 系统集成商. 独立软件开发商等很多行业, 帮助很多客户实施软件工程, 尤其是在配置管理方面. 2002年12月6日, IBM正式宣布将以21亿美元现金收购Rational软件, Rational将成为IBM软件部的第五个品牌, 这成为IBM在1995年收购Lotus Notes之后最大的一次软件收购, 这次收购从某种意义上也证实了软件工程已经成为大势所趋. 我相信, 加入IBM之后, Rational将能为客户提供更好的产品. 支持和服务.



吴穹

Rational中国有限公司北中国区经理

本书作者

Brain A. White在软件配置管理方法和工具方面拥有10年的实践经验. 他曾在工业控制和电信行业中多次成功部署SCM方案, 很多机构都达到了 ISO 9000和 SEI CMM提出的相关目标.

本书译者

尤克滨, Rational Software技术顾问, 主要从事软件需求管理. 面向对象分析和设计以及Rational统一过程方面的专业技术咨询, 是富有实践经验的软件工程布道者. 加入Rational之前曾就职于IBM中国技术支持中心.

李纪华, Ra

本书的内容

本书介绍作为软件工程规程之一的软件配置管理（SCM, Software configuration management）问题, 说明如何借助广泛应用的SCM工具Rational ClearCase(r). 贯彻“统一变更管理”（Unified Change Management, 即UCM）工作模型实现流程自动化并支撑SCM的最佳经验. 本书将介绍基本的SCM概念. 项目和系统规模及复杂性增长过程中所面临的SCM问题. 以及如何应用SCM工具和流程来解决这些问题. 本书还讨论了一些高级的SCM话题, 例如管理大型地域上分布的开发团队以及结合SCM规程与变更请求管理（或缺陷追踪）.

更具体地说, 本书将基于SCM工具ClearCase来讨论SCM问题. 尽管有些内容针对ClearCase, 本书涉及的很多内容适用于不同种类的SCM工具. 当今针对软件配置管理的书籍很少, 针对采用某种工具实现SCM策略的书籍更少. 很多项目在应用SCM工具时, 经常容易碰到各种各样的问题甚至遭遇失败.

ClearCase是一个商业化的成熟工具. 该工具适宜用来讨论相关问题, 因为它提供了一个开放型的体系构架, 用这种体系构架能够实现广泛的SCM解决方案. ClearCase适用于各类应用系统及多种开发环境, 例如关键任务系统. 嵌入式系统. 电信通讯系统. 金融应用. 网站内容. 以及其它种类的商业和政府软件系统. 如今, 各个行业不计其数的公司成功地将ClearCase作为其SCM环境的基石.

本书并不会一步步地教你如何使用ClearCase, 也不是ClearCase产品文档的替代品. 你可以使用本书的内容改进任一种SCM工具的应用. 但是, 如果你计划部署ClearCase或者改进当前使用ClearCase的方法, 你将从本书中得到最大收获.

本书的内容实质上是我过去十年经验的积累, 这些内容来自于我和SCM领域内众多出色人物的合作. 读完本书之后, 你能够更好地理解软件配置管理. 用SCM工具及技术解决软件开发问题的更好想法. 使用ClearCase解决这些问题并满足SCM需求的更明确思路. 我真诚地希望你能喜欢本书并挖掘出其中的价值.

阅读本书之前需要了解什么

你取得成功的关键是理解SCM的含义, 理解软件项目的相关需求. 以及如何应用SCM工具满足这些需求. 如果你刚开始接触软件配置管理, 本书将帮助你起步. 如果你事先有一些SCM的经验并使用过基本的版本控制工具, 那么你将得到最大的收获. 本书假设你熟悉软件开发流程. 如果你在阅读过程中能够结合一个具体的开发项目, 本书同样会很有帮助.

谁是读者和为什么要读这本书

本书不会讨论如何编写ClearCase触发器或是集成遗产工具脚本程序的细枝末节, 相反, 本书介绍一些通用SCM场景的高层次概念以及如何针对相关问题应用ClearCase. 如果你已经在使用ClearCase或拥有很强的SCM基础, 你最好浏览一下目录并挑选你感兴趣的章节.

针对软件工程师

对一个软件工程师而言, SCM工具所能作出的最大供献就是让他们不插手SCM. SCM应当以一种尽量透明的方式执行相关的功能. SCM工具的应用应当最大限度地允许对软件系统进行变更. 虚弱的工具和设计不良的流程都可能给软件工程师的工作增添额外的时间与精力负担. 本书能够帮你找到那些促使SCM工具与流程更有效率的办法. 其中一个重要概念就是基于活动的软件配置管理. 这种概念将抽象水平从文件提升至活动. 应用这一概念使得应用SCM工具. 追踪变更. 以及和其他软件工程师共享变更内容的工作变得更加直观.

如果你刚开始接触软件配置管理, 请阅读第1章“什么是软件配置管理”. 如果想总览ClearCase所管理的对象, 请阅读第4章“ClearCase对象功能概述”. 要想理解ClearCase如何支持日常的开发活动, 请阅读第8章“使用ClearCase UCM模型进行开发”.

针对软件项目经理或者技术主管

作为一个软件项目的负责人, 你关注对软件系统进行变更的决定, 而后确保这些变更的发生. 一个好心开发员作出的无计划变更也会给项目的进度带来风险, 甚至拖延进度或降低产品质量. 对变更的控制和追踪是确保项目成功的基本要素.

本书能够帮助你扎实地理解SCM, 你可以获知为什么需要SCM, 你可以学到如何借助ClearCase解决项目中的问题. 具体讲就是第6章“使用ClearCase的项目管理”和第7章“协调多个团队以及其他场景”. 如果你管理的团队不在同一个地点, 请阅读第10章“地域上分布的开发”, 这里探讨了相关的问题和策略.

针对工具工程师

工具工程师的角色经常被忽视, 但这一角色是成功的关键, 尤其在一个大型机构中. 工具工程师的任务是描述一个机构的人和流程如何使用特定的工具. 本书提供SCM和ClearCase的信息, 借助这些内容你可以确定将ClearCase应用到开发项目中的最佳方案.

针对那些评估ClearCase的人员

本书是一个用于评估ClearCase的很好起点, 因为这里介绍了很多常见的软件开发场景, 包括一些比较复杂的场景, 例如地域上分布的开发. 本书基于一组SCM最佳经验讨论对SCM工具和流程的需求, 介绍如何采用ClearCase支持这些SCM最佳经验. 相关内容包括对ClearCase直接可用流程即“统一变更管理”的概述, 以及对ClearCase对象的概述.

参考第1章“什么是软件配置管理”. 第2章“找到你的SCM解决方案”内容, 有助于你判断适用于特定项目的SCM工具需求. 阅读其余的章节, 进而判断ClearCase是否能够满足你的要求.

针对富有经验的ClearCase用户

如果你已是一个长期的ClearCase用户, 本书中具有普遍意义的软件配置管理内容将向你揭示一些深入的见解, 有助于在项目中更好地应用SCM解决方案. 如果你要支持一个地域上分布的开发团队, 本书给出了一些相关的建议（参见第10章“地域上分布的开发”）.

本书中概述了ClearCase直接可用的使用模型, 即统一变更管理, 这也是新近添加的内容（参见第3章“统一变更管理模型概述”）. 如果你对变更请求管理与ClearCase的集成感兴趣, 请阅读第11章“变更请求管理与ClearQuest”.

本书的内容编排

以下是对所有章节的简要介绍.

第1章, 什么是软件配置管理, 对软件配置管理及相关的最佳经验作一般性介绍. 这一章回答：什么是软件配置管理（SCM）？什么是SCM工具？什么是SCM流程？

第2章, 找到你的SCM解决方案, 探讨了软件开发项目持续增长的复杂性, 提出一个观念, 即项目复杂性的不断增长将要求更充分的SCM支持. 这一章回顾了SCM工具的发展历史, 有针对性地将软件项目粗略地划分为五种类型, 从一个人开发的软件应用扩展到地域上分布的多个团队协同开发的项目.

第3章, 统一变更管理模型概述, 介绍了ClearCase直接可用的使用模型, 即统一变更管理, 这一模型支持实现一种自动化SCM流程. 这部分内容的组织线索是各种团队成员所承担的角色与责任, 例如系统构架师. 项目经理. 开发员. 以及集成员.

第4章, ClearCase对象功能概述, 介绍了ClearCase对象的功能及相关概念. 这一章介绍了SCM通用术语和ClearCase专用术语之间的对应关系.

第5章, 创建初始的SCM环境, 介绍用于创建初始SCM环境的信息. 这一章讨论了ClearCase的基础构架. 这一章还讨论了软件构架向SCM工具中构件的映射, 并且简要介绍如何创建SCM存储池以及导入已有软件.

第6章, 使用ClearCase的项目管理, 重点介绍项目经理在SCM中所扮演的角色. 特别说明了ClearCase中用于支持项目经理的自动化处理和功能. 这一章给出了一个创建ClearCase项目的示例.

第7章, 协调多个团队以及其它场景, 讨论了协调并行工作的问题. 这一章还探讨了一些相关的场景, 例如多个小组针对同一个发布版本的协作, 多个小组并行工作于不同的发布版本, 针对IT/IS风格项目的协作, 以及在面向文档类型项目中的协作.

第8章, 使用ClearCase UCM模型进行开发, 介绍如何使用ClearCase, 着重说明开发员所扮演的角色. 展示如何找到并加入一个已有项目, 如何对文件进行变更从而完成活动, 如何交付与活动相关的变更内容, 以及如何利用其他项目成员所作变更内容来更新开发员的工作空间.

第9章, 集成. 构建与发布, 着重介绍集成员所扮演的角色并讨论软件的集成方法. 这一章概要地介绍构建. 定基线以及提升基线. 概述如何将构件放到一个用作交付的独立存储池中, 在该存储池对那些被构建的可交付文件及目录进行版本控制. 在对比不同类型软件系统的基础上, 这一章讨论了如何发布软件.

第10章, 地域上分布的开发, 探讨为了实现成功的分布开发而必须克服的挑战, 这些挑战来自机构的组织形式. 沟通方式以及技术手段. 这一章着眼于三种典型的分布开发场景及相关问题. 这一章的最后还讨论了ClearCase MultiSite的技术以及如何在三种典型场景中应用MultiSite技术.

第11章, 变更请求管理和ClearQuest, 讨论了变更请求管理（change request management, CRM）的内容, 缺陷追踪就是变更请求管理问题的一个子集. SCM和CRM是两个紧密关联的软件工程规程, 它们在一起形成综合的变更管理支持. 这一章介绍了Rational ClearQuest工具, 讨论该工具如何与ClearCase配合, 从而为统一变更管理模型提供技术基础.

所使用的表述习惯

命令和强调的文字

命令行操作用一种不同的字体表述, 前面有“promt>”子样, 例如：



prompt> command -flag1 -flag2



为了清楚起见, 采用多行表达长的命令（参见下面的例子）, 实际操作中还是要在一行中键入, 例如：



prompt> longcommand longobject-identifier

-flag1 //machine/pathname

-flag



注释

文字内容中一些需要强调的重点也会使用这种字体, 前面还会有一个箭头作为提醒.



警告：

这种被灰色框突出的警告文字用于强调可能遇到和需要避免的问题或关注点.



ClearCase提示

带有“ClearCase提示”子样的灰色框中内容针对那些clearCase的已有用户. 如果你不曾使用ClearCase, 可以跳过这类提示.

UML图的格式

本书包括采用图形化建模语言表述的图示, 这种建模语言就是统一建模语言, 即UML. 关于UML的更多信息, 请参考Grady Booch. James Rumbaugh和Ivar Jacobson所著《统一建模语言用户指南》[Booch 1999].

以下说明本书中所使用的一些UML语言表述：用一个方框表示一个对象, 其中是描述该对象的文字. 连线表示对象之间的关联关系, 线上的文字描述关联关系的含义. 例如, 一个房子有一个房顶：

可以为关联关系标注更多信息, 例如多少个对象可以被连接在一起. 这称为关联关系的多重性. 例如一座房子只有一个房顶, 一个房顶只能关联于一座房子. 一座房子可以有多个窗户或没有窗户. 一个窗户可能不对应房子（在它被安装之前）, 也可能对应一座房子. 这些标注信息如下所示：



如果没有窗户的房子还算是房子么？如果不是, 那么你可以用“1..n”而不是“0..n”表达窗户的多重性.

黑色菱形是对关联关系的另一种标注, 用于表述组合关系. 组合关系表示一个对象由其他对象组成. 这种类型的关联关系表达了一层重要的语义. 一个对象拥有另外的对象. 也就是说, 被拥有的对象可以被创建或删除, 它们一旦被创建将一直与其拥有者在一起. 如果拥有者被删除, 其拥有的内容也随之被删除. 例如, 一个数据库拥有数据表. 数据库被删除时, 其中的所有数据表也将被删除. 组和关系的UML表述如下：

最后, 有一种UML关系叫作“泛化”, 描述一般化事物和相对特殊事物之间的关系. 例如, 一般化事物可能是鞋子, 特殊类型的鞋子有跑鞋. 漫步鞋及网球鞋. 泛化关系表现为指向一般化事物的箭头, 参见图示如下：