传统和经典的解释

　　传统和经典一般意味着古老、守旧、过时，另外一方面说也代表着基本、核心和不可替代。传统的配置管理工作其实主要包括四个方面：配置识别，配置管控、配置审计和配置状态报告。

　　我嚓，这是啥？第一眼看到这么多术语肯定很多人会蒙圈，我也会。其实如果我们从工作需要去考虑这四个方面就容易理解了。

　　四个方面

　　大家肯定都听说过PDCA，也叫戴明环，质量环。简单说着是管理学中的一个模型。不一定完全适用这里，但是我们也可以顺着这个思路去想。

　　配置识别

　　我们做事的时候呢，我们首先就是要确定一个明确的目标，或者说管理对象。配置管理，是管理什么呢？当然是管理配置，那管理什么配置呢？哪些是该管理的，哪些是不该管理的？这些事情都是配置识别中的内容。配置识别的目标就是识别出你要纳入配置管理范围中的事物（配置项）。什么是配置项？可以用这么一个办法简单去识别：如果这个事物、流程、方法、文件、状态、资源会对产品或者项目的进度、质量、资源产生影响，那你就可以把它纳入配置项的范畴。这样解释就很容易明白了吧。比如需求文档、算法实现、测试计划、人员安排、风险评估表等等，都是配置项。

　　配置管控

　　上面我们识别出了配置项，这些配置项其实也就是我们工作中涉及到的所有工作内容，我们的大部分工作都是针对这些配置项进行有目的的变更，比如更新了个文档、抄了一段代码、更新了测试用例、拒绝了产品提出的要求、改变了工作流程等等，这些都是针对配置项的变更。配置管控可以说就是管控对配置项的变更，也可以称作变更管理。

　　配置审计

　　我们找到了需要我们管理的配置项、以及对这些配置项的变更也作出了合理的管理（拒绝或者接受变更），那下一步做什么呢？是配置审计。简单来说我们知道要做什么了（识别了配置项），也知道了怎么进行修改（配置变更），大家就开始热火朝天的码代码了。其中是不是少了评价工作好坏标准这一环？我怎么知道我做的事情是作对了呢？这个时候我们就要每个阶段都要进行配置审计。那审计的评判标准是什么？是公司的各项规章制度、研发流程、过程实践甚至是等。比如各种文档有无，代码命名规范、产品版本更新、项目结构、构建流程等等，主要审查这些。

　　配置报告

　　好，当我们按照各种规章制度、各种流程对配置项做了变更控制后，我们下一项配置管理工程师需要做的事就是配置状态报告。每个特定的阶段一般都会做一次。比如传统瀑布模型中设计阶段完成后，我们要做一次配置审计，形成一个完成的配置状态报告（注：配置审计可以一周做一次，但是配置状态报告并不是每次都需要做）。报告中明确写明了本阶段应该有经过评审和确认通过的架构设计规范、详细的审计规范、测试计划、配置管理相关系统、配置管理计划、项目计划和测试计划等。

　　小结

　　上面就是大白话描述了传统也是经典的配置管理的主要工作内容或者说活动，当然配置管理工程的职责就仅仅有这么多么？不是的，这里仅仅是介绍了配置管理的一些基本工作内容。为了完成上面四方面的内容，需要做的事情有很多很多。理论与实践还是有很大的差距。有人问了，那现实情况是这样做的么？除了这些我们还需要做什么？下面我就来说说配置管理周边的工作内容。有的人经常抱怨配置管理就像打杂的，除了照顾项目组衣食起居，其它都做了。那是因为虽然配置管理的核心工作内容就那么多，但是相关工作却有很多；甚至不同的公司、不同的项目对这个职位的认识都不统一，那么就形成了各种情况。在项目经理底下的侧重各种数据、各种报表；在测试经理底下的侧重测试环境搭建、环境部署、测试自动化；在运维底下的是聚焦各种运维系统。下面将要讲讲现实工作中的配置管理核心内容是哪些。