配置管理+变更管理：三库两审"闭环"速记——案例"送分"考点
(文 / 老孙)
高项倒计时冲刺特辑 Day 45 | 免费
字数约 7500，阅读大约需 15 分钟
一、开场：为什么说这是案例分析的"送分题"？
各位老铁，今天咱们聊的话题，老孙敢打包票——你把这篇文章吃透，案例分析至少能多拿5-8分。
为什么？因为配置管理和变更管理是案例分析中出镜率最高、套路最固定、答题模板最好用的两个知识领域。翻看历年真题你会发现，几乎每年的案例分析都会涉及变更管理或配置管理的内容，而且考法极其稳定——无外乎就是"找错+分析原因+给建议"三段论。
老孙先给你画个"全景图"，让你一眼看清这两个家伙的关系：
看到了吗？配置管理是"管家婆"，管的是"东西在哪儿、版本对不对、改没改过"；变更管理是"审批官"，管的是"能不能改、谁批准改、改完了没"。两者相辅相成：配置基线一旦建立，任何变更都必须走变更管理流程；变更完成后，又要回到配置管理去更新基线和状态报告。
这个"闭环"就是案例分析的命题核心。只要你理解了这个闭环，案例题就是填空题。
好，下面我们一个模块一个模块来扒。
二、配置管理：管家婆的六件套
2.1 配置项：到底管什么？
配置管理的第一步是搞清楚"管什么"。教材的定义是：配置项是为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。
翻译成人话：凡是项目中需要被管起来的"东西"，都叫配置项。
配置项的范围很广，典型的包括：
| 类别 | 举例 |
|---|---|
| 文档类 | 项目计划书、需求文档、设计文档、测试用例 |
| 代码类 | 源代码、可执行代码、脚本 |
| 数据类 | 运行软件所需的各种数据、配置文件 |
| 环境类 | 设备型号、关键部件、服务器配置 |
| 管理类 | 变更请求、服务协议、合同 |
考试关键点：配置项分为基线配置项和非基线配置项两类。
- 基线配置项：设计文档、源程序等技术产物 -- 向开发人员开放只读权限
- 非基线配置项：项目计划、报告等管理文档 -- 向项目经理、CCB及相关人员开放
口诀："基线只读，非基线可写（给管理层看）"。
2.2 配置项的三种状态
配置项有三种状态，它们之间的流转关系如下：
- 草稿：刚建立的配置项，版本号格式为
0.YZ（如0.01、0.02） - 正式：通过评审后的配置项，版本号格式为
X.Y（如1.0、1.1、2.0） - 修改：正式版被修改中，版本号格式为
X.YZ（如1.01、1.02），修改完毕重新评审后回到正式状态，Z归零
考试陷阱：题目经常给你一个版本号让你判断配置项状态。记住：看到0.xx就是草稿，X.Y就是正式，X.YZ（三位）就是修改中。
2.3 三库：开发库、受控库、产品库
这是配置管理最核心的考点，没有之一。老孙给你一个口诀，一句话记住三个库：
"开发库随便改，受控库走流程，产品库不能动"
| 库名 | 别称 | 谁用 | 权限 | 类比 |
|---|---|---|---|---|
| 开发库 | 动态库、程序员库、工作库 | 开发人员 | 自行控制，随意修改 | 你的草稿纸 |
| 受控库 | 主库 | 项目团队 | 完全配置管理，Check out/in | 公司的文件柜 |
| 产品库 | 静态库、发行库、软件仓库 | 交付使用 | 完全配置管理，只有发布才动 | 博物馆的展品 |
三库之间的流转是案例分析的"送分考点"。这里重点解释一下受控库的Check out/Check in机制：
- Check out（检出）：程序员从受控库取出代码到自己的开发库修改。代码被检出后即被"锁定"，同一段代码只能被一个人修改
- Check in（检入）：修改完毕后，从开发库送回受控库。检入后锁定解除，其他人可以继续检出