公司《2012年工作报告》中提出的生产一体化建设、质量体系建设等内容，都表达了公司对质量管理的重视，同时也反映出了在新形势下质量管理给我们提出的挑战。从质量核心竞争力的角度来讲，我们不断的优化生产过程、加强质量保证，终都是为了从质量角度保障公司的核心竞争力。本文想配置管理对保障和提升软件质量的作用谈一些个人的体会，欢迎各位批评指正，共同探讨。
　　通过日常工作的交流，发现有90%左右的人，并不真正的了解配置管理，对配置管理认识的一些误区，个人觉得对配置管理进行全面陈述非常必要，纠正一些认识的误区，使我们真正的了解配置管理，然后更好的利用它为我们服务；二是结合自己对配置管理的一些理解与体会，对目前的配置管理工作提一点建议。文中结合了一些实际工作中遇到的配置管理问题来佐证自己的观点，如有说明有误的地方，敬请谅解。
　　一、初识配置管理
　　接触配置管理这个词，起源于公司的配置库SVN。我想大家对于配置管理的认识也都源于SVN的应用。接下来，我先来回顾一下我们的配置管理工作内容。
　　（1）配置库权限：当有新项目立项时，我们要写申请建库，按公司的配置库规范建立相应的文件夹，再将权限分配情况附上。当有新员工入职时，我们要写权限申请，根据他的工作内容分配相应的访问权限。
　　（2）配置库管理：公司有相应的规范，说明了配置库的文件夹目录建立要求以及文件夹下存放文件的要求，同时要求所存放文件，除代码以外的文档类文件都要按统一的命名格式命名。
　　（3）变更管理：当项目计划、项目范围、配置库权限发生变化时，都需要提交变更申请，以记录这些变化。
　　（4）版本管理：公司的版本管理根据文件内容分为两种，一种是文档，命名上要求标识版本，由版本的数字便可识别该文档的状态和修改次数。二是代码，由各项目组自行约定命名规则，我们更侧重于基线管理，一般是当项目结项时，由项目组提交基线清单，配置管理员根据清单提取相应文件，将这些文件移入另一个地方存储，冻结起来，当要进行修改时，需走相应的变更程序。
　　（5）配置审计：每年各部门都会接到配置审计情况报告，说明我们有哪些文件夹长期不用、有哪些文档没有规范命名、有哪些文档没有放对位置、有哪些文档缺失。
　　通过这些管理工作，保证我们项目所有相关的资料都进入了SVN，当我们要输出项目成果时，从SVN里提取。可是我们遇到了一些小混乱，而且是时有发生的小混乱：
　　（1） 已经废弃的代码不知何时又出现在SVN中；
　　（2） 找不到哪个才是发布在生产环境上的代码；
　　（3） SVN提供了版本回退功能，可是这里一串没有日志的版本更新，不知道要回退到哪个版本才是对的；
　　（4） 还有一些缺陷没有修改完，这次不发布了，可是怎么才能从这一堆的文件里快速找到这次要发布的代码；
　　（5） 要验收了，这些功能在设计说明书上没有写，赶快补文档；
　　（6） 要验收了，用户手册上说明的功能操作和现在发布的版本不一致，赶快修改；
　　这些问题终体现在我们的交付成果上，是一个一个的质量问题；体现在团队的协作上，是一段一段不和谐的协作经历。明天要发布新版本了，修复的缺陷又出现了，我们的程序员面对SVN中一连串没有日志的更新，不知道自己正确的代码是什么时候提交的，也不知道提交之后又发生了多少次变化。只能抱怨自己配合配置管理人员把该交的文件提交了，还不情愿的把所有不规范的文件名称都修改了，可是有什么用呢，配置库关键时刻还是拿不出来自己想要的那个文件。什么版本管理、什么安全、什么提高大家的协作……这是一个大家公用的仓库，还是放到自己这里安全。
　　如果仅从仓库的角度理解，我想这些都归结一个原因，我们没有用好这个仓库，没有把代码放对地方，当然在需要时也不能去正确的地方拿到。从专业的角度讲，便是配置管理没有做好。那什么是配置管理？我们为什么需要配置管理？好的配置管理工作能给我们带来什么好处？目前我们的配置管理有哪些缺陷，我们可以朝哪个方向改进？我们从大家对SVN的普遍印象“仓库”为起点来探讨一下这些问题。
　　二、从理论上认识配置管理
　　什么是配置管理？
　　CMMI对配置管理的定义是“一套应用技术上和管理上的指导和监督的方法，用来：识别和记录配置项的功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其符合特定的需求”。
　　配置管理教科书上说得较为明白的定义：“配置管理是一门用来记录并控制软件产品数据的管理学科，是对各类工作产品的内容、版本、变更和发布进行控制，运用配置标识、变更控制、配置状态统计和配置审计等手段，建立并维护工作产品的完整性和可追溯性的一系列活动”。你理解什么是配置管理了么？有一头雾水的；有似是而非；有明白了，还是不知道怎么做的；接下来我从自己理解的角度来给大家通俗的讲下配置管理（通俗是我追求的目标，不要见笑）。
　　2.1用图书管理作比喻：配置管理管什么？
　　现在“资产”这个词很流行，软件资产，我想不用我解释，做软件的人员都知道它指的是什么。配置管理是对这些软件资产的管理。那具体有什么要管理的呢？我想用图书馆的图书管理做个对比来说明。

　　从对比中来看，软件资产的管理非常类似于我们平时所说的实物资产管理，其实从某种意义上讲，软件配置管理管理的也是实物，是一个个看得见、读得懂的文件。只是它还有一些自己的特点。比如软件资产会在这一“借”一“还”的过程中，程序员对它进行了修改，这些变化并非像图书弄脏了那样容易发现，它更类似于图书缺页，当借阅的人员归还图书时，管理员需要翻开图书才能发现是否缺页。软件资产也一样，通常情况下，打开SVN，你会发现几天前后都是10个文件，似乎没有变化，如果你打开了某个源代码文件，你才发现几天前它只有两行代码，现在有几千行代码了，它早已不是它了。而对这种变化的处理也大有不同，缺页的图书肯定是不能再用了，而变化了的代码却并非不能再用，它在合理的情况下发生的变化是允许的、可接受的。但为了确保这些变化确实是被允许的、可接受的，配置管理更关心各次的修改者、修改的原因以及这些情况是否应该被记录，以便将来可以理解当时的情形，理解为什么做出这样的改动？我们如何轻而易举的发现这些变化？这个文件未被修改前是否可用，可以在哪种情况下使用？还有更需要关心的，当两个人同时想要修改一个文件的时候，可能会导致其中一个人的改动丢失，那么，是让他们一个改完了另一个再改呢，还是让他们同时改，在将来合并？这可不像两个人要借同一本书，我们只需要买两本书放在图书馆那么简单。
　　所以说，软件配置管理是对这些不断变化的软件资产进行管理，但作为资产，它和图书有一些共同的特点，我们可以借鉴一些管理图书的经验。
　　2.2用生产奥迪作比喻：为什么要有配置管理？
　　奥迪大家都想有一张。奥迪是什么组成的？说大了，是底盘、发动机、车身和电器设备四大部分组成。这像我们说的系统的模块。再说小点，底盘一般包括传动系、转向系、制动系和行驶系。传动系主要由离合器、变速器、传动轴和减速器等部件组成。这像我们说的模块里的功能。再说的更小点，还有轮胎、方向盘、车门、车窗甚至轮胎的螺丝，这些都是零件了。这像我们一个个代码文件。想想我们要组成一张奥迪A6，要保证A1的发动机不被装在A6上，要保证选取了所有正确型号的零部件，大到车的颜色，小到一颗轮胎螺丝，我们都不能选错，否则可能A1的价格买到A6的性能，乐坏了用户，愁坏了企业。我想应该有某种列表或文档，标明各零部件型号和组成关系，也是标明车辆的配置信息。工人们按这个列表到相应的仓库或找相应的部门领取零部件组装。而当配置有变动的时候，更新一下列表或文档。工人们还是按这个表领取零部件，那A1的发动机应该好好的躺在A1的车盖里。
　　从硬件配置管理的视角看软件，软件也是这么配置起来的。说小点，各个源代码文件的正确版本配置在一起，编译产生正确的可运行程序。说大点，若干系统组件的特定版本，构成了特定的软件产品。而且有些软件组件或代码文件，可能参与了不止一个软件产品的构成。而当某个软件组件参与不止一个软件产品的构成的时候，可能是这个软件组件的同一个版本，也可能是不同版本。看，问题有很复杂吧！不管理怎么行！而且还要管理好！
　　所以软件配置管理非常必要，而且需要给予更多的关注。
　　综合前两个比喻，我们可以得出一个通俗点的配置管理定义：配置管理应该是一个具备类似资产管理功能的系统，需要记录构成软件系统的各组件的用途、组件间的关系、组件与系统整体的关系以及组件自身的变化，从而了解系统整体的变化，终目标是为了在用户需要时，我们能够根据用户需求，快速提取正确的组件组成符合用户需求的系统。
　　2.3用制造业作比喻：研究配置管理的好处？
　　我们可以仔细观察软件产品的生命周期（市场调研、设计、原型设计和开发、软件开发、销售、运维）和管理流程（集成、业务对象和组件、面向全球的研发网络协作与外包），这些类似制造业的过程向我们说明了软件行业朝着工业化发展的趋势，并且可以说软件工业化的词都早已不新鲜了。工业化使制造业的产品合格率越来越高。同时国外相关资料显示，在软件开发过程中，当构件的复用程度达到50%，生产率便可提高40%，开发成本和出错率分别降低40%和近50%。我们要不断的识别这些可复用的构件，提升软件质量和复用水平，我想快好的办法便是从对这些构件的整理与保管入手，即配置管理。
　　2.4再用制造业作比喻：配置库在软件生产过程中可以承担的角色
　　软件生产不像硬件生产一样，有看得到的生产车间，有摸得着的生产线。我们都希望或者理论上认为针对某一具体功能，软件生产如果遵循”调研-需求分析-设计-编码-集成-测试-再修改-集成-测试-通过”的流水线，我们也能像硬件一样，通过流水线生产提升产品的合格率。可是软件生产是个智慧活动，感觉上我们无法像生产奥迪一样，工人生产哪个零件进哪个生产车间或者上哪条生产线，零件在零件车间里生产，整车组装车间里组装等等。我们的软件开发人员都坐在一间办公室，可是有人在生产零件，有人在组装，有人在检验，我们无法通过看到谁在干什么来评估我们的软件生产进度。我们如何能像硬件生产一样，让流水线上不同的人员进入不同的生产车间？这是我想说的配置库可以承担的角色。
　　我们忽略了一点，是软件产品也有像硬件一样看得见摸得着的零件，它们都要被放在仓库（SVN）里保管，假如我们可以把仓库（SVN）按生产线划分管理，并且控制这些仓库的开放时间或开放条件，那么生产线看得见摸得着了。给大家看一个业界流行的配置库划分原型，大家看看是不是能够看到生产线了。

　　在这个生产线上，我们生产的未经检测的零件放到开发库里；程序员个人觉得符合集成条件的放到受控库里，等待测试、配置、变更控制等质检人员来检查；当通过各项检测后，认为可以发布了，我们把它放到基线库里冻结起来，以后只要生产环境一发生状况，我们可以从这里快速拿到代码进行编译、发布等。从这里你们是否可以看到或感觉到，我们建立了一个虚拟的生产线和生产车间，开发人员工作在开发库里，质检人员工作在受控库里，发布人员工作在基线库里。当然这只是一种划分策略，它更适合串行开发、版本单一并且进入运维期的系统。在实际应用中，我们可以根据软件产品的特点来划分，可以是两个库、三个库甚至四个、五个库等，我们可以根据软件自身的特点，又在这些库里划分出更多小的格子空间来，我们只需要管理好仓库好了，通过对这些仓库物品的进出来评估产品的生产进度。所以配置库有个比较重要的角色是固化生产线，让我们的软件生产也“流水线”起来。