3. 配置基线管理：基线的定义与类型

聊到配置管理，有个概念你绕不开——基线。

说白了，基线就是一把尺子。它标记了某个时间点上，所有配置项的“标准状态”。我个人的理解是：基线就像游戏里的存档点。你打怪升级，万一挂了，还能从存档点重来。没有基线，项目出了问题，你都不知道该回退到哪个版本。

3.1 基线的定义

基线的官方定义很绕口：“一个或多个配置项在特定时间点的正式版本，作为后续开发的基础。” 嗯，我换个说法：基线就是经过正式评审和批准的配置项集合。

它有几个关键特征：

• 不可随意修改：一旦建立，修改必须走变更控制流程。
• 有唯一标识：比如版本号 V1.0、V2.0。
• 可追溯：能清楚知道谁在什么时候改了什么东西。

我在项目中遇到过最典型的反面教材：团队没有基线概念，开发人员直接在生产环境上改代码。结果呢？改完发现性能下降了，但没人记得之前是什么版本。最后只能回滚到一个月前的备份，损失惨重。

3.2 基线的三种类型

根据国家标准 GB/T 11457 和 CMMI 模型，基线主要分为三类。你想想看，这其实对应了软件工程的三个关键阶段：需求、设计、交付。

基线类型	英文名称	对应阶段	核心内容
功能基线	Functional Baseline	需求分析阶段	系统需求规格说明、接口需求
分配基线	Allocated Baseline	设计阶段	系统设计规格、子系统接口
产品基线	Product Baseline	交付阶段	可执行程序、用户手册、安装包

3.3 功能基线

功能基线，说白了就是“我们要做什么”。它通常在项目启动阶段建立，标志性文档是《系统需求规格说明书》。

我记得有一次，客户在验收时突然说“这个功能不对”。我翻出功能基线文档，白纸黑字写着当初双方签字确认的需求。这就是基线的价值——它是扯皮的依据。

功能基线的关键要素：

• 经过评审的系统需求
• 明确的验收标准
• 接口需求定义

3.4 分配基线

分配基线，解决的是“谁来做”的问题。它把功能基线的需求，分配到具体的子系统或模块。

举个例子：功能基线说“系统需要支持用户登录”。分配基线就会细化成：前端负责登录页面，后端负责认证接口，数据库负责存储用户信息。

我曾经在一个大型项目中，因为分配基线定义不清，导致两个团队都以为对方负责“用户权限校验”。结果联调时才发现，谁都没做。嗯，从那以后，我特别强调分配基线必须明确接口边界和责任归属。

3.5 产品基线

产品基线，就是最终交付给客户的东西。它包含：

• 可执行程序或安装包
• 用户手册、技术文档
• 测试报告、部署说明
• 源码（如果客户要求）

产品基线一旦建立，就意味着项目进入维护阶段。任何修改都要走变更流程。我建议你在产品基线中，一定要包含构建环境的描述。比如操作系统版本、依赖库版本、编译器版本。否则，三年后客户要求重建环境，你可能会发现当年的依赖包已经找不到了。

3.6 基线建立流程

基线不是拍脑袋定的，它有一套标准流程。我把它总结为五个步骤：

1. 识别配置项：确定哪些文档、代码、数据需要纳入基线。
2. 评审与批准：组织相关干系人进行技术评审，签字确认。
3. 建立基线：在配置管理工具中打标签（Tag）或创建分支（Branch）。
4. 发布基线通知：通知所有团队成员基线已建立，后续开发基于此版本。
5. 基线审计：定期检查基线内容是否完整、一致。

3.7 基线的生命周期管理

基线不是一成不变的。随着项目推进，基线会经历：

• 建立：初始版本
• 维护：通过变更流程更新
• 冻结：项目结束，不再修改
• 归档：移入长期存储

我个人习惯在项目结项时，把产品基线打包成 ISO 镜像，刻录到蓝光光盘或上传到对象存储。为什么？因为硬盘会坏，云存储会过期，但物理介质加上多副本备份，才是真正的“保险柜”。

好了，关于基线的定义和类型，就聊到这里。下一节我们讲讲配置审计——怎么确保你建立的基线是可信的。