未雨绸缪：理解软件配置管理

　　本书是作者多年专注于软件配置管理理论和实践的结晶，书中不少观点实际上也代表了很多软件配置管理相关从业人员的感受和心声。 全书尽管只有二百余页，但却深入浅出地道出了与配置变更管理相关的多个基本概念，如版本控制、配置管理、缺陷跟踪与变更管理、构建、组件、集成、分支等。同时书中根据不同实际场景给出了业界的实践，而且处处渗透了作者在软件配置管理方面的心得，例如对分支运用的分析、对组件复用的理解和实践、对于集成过程及集成责任的清晰阐述等。并且，本书结合工具（ClearCase、ClearQuest、Subversion、Bugzilla等）简单明了地指出了当前流行的配置工具是如何实现这些实践的。 该书值得所有软件开发从业人员仔细阅读、细细品味及随时参考！

　　软件配置管理为软件开发提供了基础性的支持环境，它与软件开发中的所有角色都有联系，因此本书是写给所有与软件开发有关的人士看的，而不仅是给软件配置管理人员。
　　本书分为两部分，第一部分详细介绍了软件配置管理的基本知识；第二部分主要讲述了软件配置管理的一些实际问题。本书的目标是让读者在很短的时间就能掌握软件配置管理的基础知识，在参与当代软件开发时，具备软件配置管理方面的基本素养。
　　本书的一大特色是作者用诙谐生动的语言来讲述专业的技术知识。文中充满睿智的调侃为读者营造出一种轻松的氛围，让原本比较沉闷的技术阅读成为一种愉悦的享受！

　　董越，男，1977年生。

　　他目前的公开身份是索尼爱立信公司的SCM Strategist，而他的秘密身份是SCMLife这个组织的核心成员，代号为流水先生。他毕业于清华大学，拥有一个硕士学位和两个学士学位：

　　他曾工作于西门子、摩托罗拉和雅虎等公司，一直专注于软件配置管理：他曾发表软件配置管理相关的多篇文章；他曾NIBM Rational用户组等组织提供多次讲演、讲座和咨询：他曾领导Flooda、EasyCM等多个开源软

　　件项目。

　　最后，特别重要的，他目前单身。

上篇：基本话题
第1章 恼人不休的问题：什么是软件配置管理
　1.1 问题的引出
　1.2 与图书管理作对比
1.3 为什么称作配置管理
　1.4　其他一些比喻
第2章 基本的版本控制：记录版本，防止混乱
　2.1 即使只有一个程序员
2.2 建立公共存储区
　2.3 防止版本覆盖
2.4 行话
第3章 按任务单元组织工作
　3.1 为什么
3.2 从创建到提交
　3.3 适时更新工作空间
3.4 保证任务单元完成的质量
窘4章 产品的整体版本
　4.1 记录源代码整体版本
4.2 保存安装包
　4.3 开发-测试-发布
4.4 版本号
　4.5 表达质量状态和版本目的
第5章 集成：关注源代码整体质量
　5.1 集成的含义及其演变
5.2 谁宋承担集成责任
　5.3 集成的一般步骤
5.4 利用集成成果
　5.5 及早和经常地集成，持续集成
5.6 多层集成
第6章 构建管理与环境设置
　6.1 基本知识
6.2 保证构建的可重复性
6.3 全量构建与增量构建
　6.4 让构建更快
6.5 记录构建相关信息
　6.6 环境和设置：不止是在构建的时候
第7章 分支：减少等待，分头工作
　7.1 文件级分支
　7.2 产品级分支
7.3 典型应用一：实现多层集成
　7.4 典型应用二：实现交迭
7.5 分支为什么这样有用
　7.6 策略：集中精力于主线的演进
7.7 分支管理
第8章 管理文档
　8.1 文档的标识和存储
8.2 自带的说明信息
　8.3 趋势：Wlki
8.4 趋势：数据文件和数据库
第9章 跟踪缺陷，直到消灭
9.1 别让发现的缺陷跑掉
　9.2 状态转换图
9.3 准确记录，便于修复
　9.4 消灭它?立刻消灭它?
9.5 关联缺陷记录与任务单元
　9.6 分析统计缺陷相关数据
第10章 管理变更
　10.1 理清变更的概念
10.2 管理细小的变更
　10.3 在瀑布模型中管理变更
10.4 在迭代模型中管理变更
　10.5 影响变更控制的因素
10.6 记录产品版本间的差异
　10.7 控制产品版本间差异
第11章 产品整个生命周期内的配置管理
　11.1 制订计划
11.2 做好准备
　11.3 日常工作
11.4 监控、调整与改进
　11.5 收尾
第12章 玄妙的学院派
　12.1 配置识别
12.2 配置控制
　12.3 配置状态报告
12.4 配置审计
　12.5 在相关标准里
下篇：应对各种各样的挑战
第13章 一波未平一波又起：管理交迭
　13.1 发布补丁版本
13.2 并行发布
13.3 解除测试对开发的阻滞
　13.4 解除集成对开发的阻滞
13.5 都是交迭
第14章 兄弟姐妹：管理变体
　14.1 什么是变体
14.2 用分支支持变体
　14.3 支持变体的多种方法
14.4 交迭和变体对变更管理的影响
　14.5 少用变体
第15章 世间万物息息相关：管理相关性
　15.1 在软件领域的相关性
15.2 源代码相关
　15.3 静态链接库
15.4 运行时相关
　15.5 如果在总体集成时发现问题
第16章 世界是平的：管理第三方
　16.1 从开源到外包
16.2 管理第三方资产
　16.3 本地记录第三方源代码的演进
16.4 再加上本地的改造
第17章 从生产产品到生产组件：管理复用
　17.1 复用概述
17.2 实现复用：结构、过程和组织
　17.3 对复用规划的表达
17.4 对复用开发的支持
第18章 在不同地点共同工作：管理分布式开发
　18.1 何时出现分布式开发
18.2 主要困难和解决方法
　18.3 离线工作模式
18.4 远程访问模式
　18.5 本地版本库模式
18.6 只读模式
18.7 分布式开发中的变更管理
第19章 关心线上运行：管理部署
　19.1 安装包的存储和管理
19.2 管理安装过程
　19.3 记录运行系统配置
19.4 管理变更请求
　19.5 管理网站
第20章 从树木到森林：组织级管理
　20.1 概述：平衡集权与自治
20.2 工具与环境
　20.3 流程与规范
20.4 人员组织结构
结语：提倡务实的精神
附录A 相关工具索引
配置管理工具比较报告
参考书目
在线资源
书网互动

　　上篇：基本话题
　　第1章 恼人不休的问题：什么是软件配置管理
　　1．1　问题的引出
　　作为软件配置管理工作者，差不多都有这样的经验：在认识新朋友时，当别人问起自己所从事的职业，自然会回答道：“我从事软件配置管理工作”。接着，十有八九，会被问到下一个问题：“什么是软件配置管理？”。总被问到相同的问题，倒还称不上是苦恼，真正的苦恼在于回答这个问题，因为软件配置管理真是不太容易说得清……解释了半天，结果往往是：“你这份工作好玄妙啊。隔行如隔山啊，我是搞不懂了。”
　　是的，软件配置管理，确实不太好解释。软件开发过程中的其他工作，似乎都比它容易理解。开发工程师在编写源代码；测试工程师在测试、挑毛病；需求分析师配合用户确定需求，并且用精确严谨的语言表达出来……虽然这样说未必严谨，但是至少能够得到一个大致的印象。但是，软件配置管理呢？软件配置管理是什么？
　　下面是软件配置管理的一个权威定义：
　　“A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical char’acteristics of a configuration item，control changes to those chin’acteristics，record and report change processing and．implementation status，and verify compliance with specified requirements．”
　　“一套应用技术上和管理上的指导和监督的方法，用来：识别和记录配置项的功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否符合特定的需求。”
　　如果你看得一头雾水，别担心，这不是你能力上的问题。大部分人和你的感受相同。这个定义，以及类似的权威定义，都高度抽象。用一两句话，确实很难把握好软件配置管理这个概念。需要更多的描述，才能把它说清楚。事实上，这一整本书，就是在认识和理解软件配置管理。而在这一章中，我们将用一些我们相对熟悉的概念来打比方，做对比，来讲解软件配置管理这个概念。通过这样一种方式，让大家对软件配置管理有一个初步的，但比较正确的认识。
　　1．2　与图书管理作对比
　　软件配置管理，是关于软件资产的管理。什么是软件资产呢？源代码、设计文档、可以运行的程序等在软件研发过程中产生的有价值的东西，都是软件资产。软件配置管理就是关于这些内容的管理。那么，具体有什么要管理的呢？让我们把它和图书馆的图书管理做个对比。
　　它们有一些相似点。首先，图书管理管的是图书资产；软件配置管理管的是软件资产。这两种管理，管的都是信息资产。其次，图书管理，需要把图书进行分类，以便检索；需要将图书存放在合适的地方，以便存取；还要防止虫吃鼠咬。而软件配置管理也类似，需要把软件资产——主要是源代码，放在合适的目录结构里，放在合适的地方存储，防止丢失或者弄乱。再次，在图书馆，要记录谁借出了哪本书，还没还。这是为了保证图书馆的书不会丢失；而在软件配置管理中也类似，需要记录谁“借”出了什么文件，什么时候“还”的。在这一“借”一“还”的过程中，如果程序员修改了它，软件配置管理就要记录下这些修改。那么，为什么要记录呢？
　　因为软件资产与图书资产不同，软件资产在不断变化，不断演进。项目初始的时候，可能只有一份简单的项目计划，而项目结束时，已是可以交付给用户的产品。