一说起配置管理，有些部门就会说，我们没有专门的配置管理员，这块工作没法做啊。那么，配置管理就只是配置管理员的事儿吗?

那我们就先来看看什么是配置管理，为什么需要配置管理。

（IEEE定义）配置管理是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期各个阶段都能得到精确的产品配置。

（CMMI定义）配置管理的目的是通过配置识别，配置控制、配置状态记录及配置审计，来建立和维护工作产品的完整性。

这里面有几个活动：

1． 配置项识别

配置项通常是最终工作产品，以及对最终产品有直接影响的中间产品。对于一个软件研发项目来说，软件包、用户文档等是最终产品，什么对最终产品有影响呢，包括最初的需求文档，原型，设计文档，源代码，测试用例，甚至编译脚本都是对最终产品有影响的，上游变，下游也需要跟着变，它们也需要识别为配置项。而一些计划、周报、会议纪要等，属于管理性文档，并不需要纳入配置项的范围。

配置项的识别，是要建立在对工作产品了解的基础上，所以说，项目经理是最适合识别配置项的人，跟着工作任务分解和进度安排的时候就可以一起做了。

2． 配置状态记录

要管理配置项，首先在物理上要给这些配置项找个地儿存放起来，在没有现代配置管理工具的时候，建个档案室或公共文件夹就可以，但是需要把每个版本的输出都备份下来，以防需要回退的时候找不到。为了防止随意修改，需要有个人专门保管这些文件，或者对公共文件夹设置相应的权限。配置项修改后也需要经过专门的人再重新放回档案室或者文件夹。为了分清楚各个版本或基线的关系，配置项的版本变更记录，状态，以及不同基线的差异，还需要专门维护一张表格来记录。所以，配置状态记录更多地是用行政手段来完成的。这个维护工作量还是相当大的，所以需要一个专门的档案保管员或者配置管理员来承担。

在有了现代配置管理系统（SVN, GIT）等以后，版本的保留和回退，不同版本/基线的差异，系统都可以通过技术手段完成。

使用现代配置管理系统（SVN, GIT），项目起初需要建立配置库和分配权限，但是这个工作量基本是一次性的，并不需要专人。

3． 配置控制

说到配置控制，首先要谈的一个概念是“基线”。基线是由一个标识符分配到配置项目或一组配置项的集合，在一个特定时间点关联的实体。一般的基线设置包括系统级需求、系统组级设计需求、和最终开发和生产初期的产品定义，通常被叫做”功能基线“（或”需求基线“），”分配基线“（或”设计基线“）， 和”产品基线“。

通俗来说，就是我们标识出开发过程中某些关键阶段的关键工作产品，这些工作产品互相有关联，它们对于下一个阶段的工作有重要影响。比如需求基线， 包含市场或客户需求，以及与之对应的产品需求。

举个例子，当产品需求评审修改完以后，大家都达成一致在这版需求基础上开发了，需求就“基线”了，要控制起来，不能随意修改了。怎么控制基线不让人随意修改呢？有几种操作方式：

•可以把基线的文档放到专人保管的档案室里；

•可以把基线的文档放到一个权限受控的文件夹里；

•可以用GIT的分支来控制，基线后的文档提交到master分支上；

那怎么标识基线呢？有几种操作方式：

•可以把基线的文档放到一个约定好的基线标识（比如说REQBL）的文件夹里；

•可以在某个地方记录下某个基线（比如说REQBL）对应的文档名称，版本，以及存储位置；

•可以在SVN或GIT上对于以及基线的工作产品打上基线标签；

需求”基线“了以后，需要让大家都知道这是最新”官方“版本，这就是基线发布。可以人工发邮件，现在我们也可以使用技术手段让GIT上基线标签时自动发邮件。

”基线“建立了以后，可能又会因为某种原因需要变更。因为基线很重要，是后期大家工作的基础，当然不能随意修改，就需要对变更做审批（通常会成立一个项目CCB）），看到底需不需要变，如果变了会对下游哪些工作有影响，避免变更造成上下游不一致。已基线的工作产品变更完了，需要再次控制以及标识（区分上一次基线），对大家发布。

这里面有哪些工作需要“配置管理员“呢？ 将基线工作产品处于受控状态，打基线标签、发布基线，看起来像是”配置管理员“的事，其实这只是基本的管理工作，不需要什么专业知识，项目中可以指派某个人来做就行。大项目或长周期可能需要建立三个基线，对于小项目来说，可能只需要一个基线，就更没什么工作量了，而且更何况，还可以使用技术手段自动发布基线通知了呢！

4． 配置审计

配置审计是确认最终的基线和文件遵照了特定标准或需求。通常分为物理审计和功能审计。

物理审计要看，配置项标识、基线标识是否和约定一致，配置项存放位置是否与约定一致，变更是否有审批，有没有保留变更记录以及相应的评审记录等等。物理审计可以由配置管理员来做，也可以由质量人员来做，或者是项目内部指定人员。这个工作其实可以包含在日常的配置管理活动中。

功能审计内容要验证配置项目的测试功能特征，是否达到功能基线指定的需求。一般由项目经理或架构师进行，主要检查设计、代码内容是否一致，有没有夹带的需求变更，有没有走流程导致需求和代码不一致。这种审计一般只在相关事件驱动时才需要。

综上，配置管理的主要目的就是维护软件开发最终产品，以及关键中间产品。不是什么过程输出都管，所以要识别配置项；关键工作产品大家得达成一致，所以有基线以及基线发布；过程中如有变更，得识别出配置项哪些被牵连需要同时变更，所以有变更管理。

有了现代配置管理工具，配置管理所需要的“管理“工作，其实已经被技术手段减少了很多。这也是为什么，在华为，一个配置管理员可以支持四五百人的部门或团队。只要理解了配置管理的目的，团队事先约定好配置管理的规则和权限， 并不一定需要一个专职的”配置管理员“。