| 公司《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）按生产线划分管理，并且控制这些仓库的开放时间或开放条件，那么生产线就看得见摸得着了。给大家看一个业界流行的配置库划分原型，大家看看是不是能够看到生产线了。
在这个生产线上，我们生产的未经检测的零件就放到开发库里；程序员个人觉得符合集成条件的就放到受控库里，等待测试、配置、变更控制等质检人员来检查；当通过各项检测后，认为可以发布了，我们就把它放到基线库里冻结起来，以后只要生产环境一发生状况，我们就可以从这里快速拿到代码进行编译、发布等。从这里你们是否可以看到或感觉到，我们建立了一个虚拟的生产线和生产车间，开发人员工作在开发库里，质检人员工作在受控库里，发布人员工作在基线库里。当然这只是一种划分策略，它更适合串行开发、版本单一并且进入运维期的系统。在实际应用中，我们可以根据软件产品的特点来划分，可以是两个库、三个库甚至四个、五个库等，我们可以根据软件自身的特点，又在这些库里划分出更多小的格子空间来，我们只需要管理好仓库就好了，通过对这些仓库物品的进出来评估产品的生产进度。所以配置库有个比较重要的角色就是固化生产线，让我们的软件生产也“流水线”起来。
三、我们的认识误区
为什么想要讲配置管理的误区呢？通过我们的实践来看，我们使用了配置管理工具SVN，做了权限控制、变更管理、版本管理、配置库管理、配置审计等工作，却无法让程序员和各位项目经理体会到配置管理对软件质量提升的帮助。以下误区主要是讲我在调研过程中发现的一些误区。
误区一：配置库（SVN）就是一个资产仓库，资料怕丢失，千万不要忘记提交SVN。
SVN是我们常用的配置工具，它更侧重于版本管理，同时提供了一些辅助功能，可以帮助我们进行项目进度、人员工作量等的管理。然而在实际应用中，由于我们的配置管理工作不到位，使得参与开发的其他人员，如项目经理、程序员等一般认为配置库最大的作用就是安全的保管资料，防止丢失。它们会把各种资料甚至是自己怕丢失的任何资料都放到配置库里。这里我想澄清一下配置库里所放的资料性质。其实可以分为两类：一类是项目管理的，如合同、计划、日志、申请，这些只是辅助管理的资料，从长远来看，我们只能从这些资料中获取一些管理经验，等待下一个项目开发时，我们可以参照着做一个更好的项目计划，当然前提是我们还需要专人对这些资料进行识别，我们保留在库里的是能够提供参考价值的项目计划。第二类是与开发成果相关的工作产品，如需求、设计、源代码、安装文件、用户手册等，我们需要用这些资料组装符合用户需求的产品。我们需要更注重利用配置库管理产品组装的材料。
误区二：版本控制就是配置管理。
前面说了，配置管理需要管理软件资产自身的变化，我们是通过版本来体现这些变化的。我们也知道这只是配置管理中的一部分工作，所以并不意味着有了版本控制配置管理就做得较为完善了。我们说配置管理的目标是能够通过能这些资产的管理，快速的获取正确的组件，组装成符合用户需求的软件系统，所以不只是版本控制，我们还需要考虑配置管理如何并行/异地开发支持、过程控制等活动，这样配置管理才能做得更好。
误区三：用了SVN，我们就做好了版本控制。
我们常说我们做了版本控制，我们要求开发人员的代码都要提交到SVN中，在项目结项时，我们要求入基线，通过基线清单从SVN里提取正确的文件封存，做为下一个版本开发的基础或者以便版本回退之用。我想我们是否太过于相信工具或者说我们没有善用工具，以为用了SVN，我们就做好了版本控制。版本控制的最终目标还是为了通过版本更新的信息记录来获取到正确的组件，最终能够快速组装软件产品。而基线是版本的一个特例，它可以在我们遇到下列情况时提供帮助：（1）当我们完成一个具备使用条件的系统，现在想进行一些探索性的功能开发，这个开发有可能失败。这时我们记录一个基线，当我们失败时，我们可以快速回退到探索性开发时。如果这个失败是大半年后的事情，那个基线给我们带来的好处更明显。（2）当我们所开发的系统具备了基本功能，可以根据不同用户需求增加新的功能，形成不同系列的产品时，我们可以记录一个基线。当遇到A类用户时，我们增加一些功能，形成一个系列产品。当遇到B类用户时，我们从基线开始增加另外一些功能，又形成了另一个系列的产品。
四、配置管理建设策略
通过前面的讲解，我想大家应该明白什么是配置管理了，规范的配置管理能给我们带来些什么好处。在公司当前情况下，我们的配置管理要采取什么指导思想或者策略，在这里和大家分享一点个人想法。
4.1公司的配置管理现状
我们现在已经使用了配置管理工具SVN，有公司级的配置管理员，并已经开展了公司级的配置库管理、变更控制、版本管理、配置审计等工作。部分部门也建立了相应的研发规范，通过对配置库的使用规范来控制代码的变更。但是公司的业务在不断发展，我们需要考虑更多的支持，比如：
（1）对通用产品个性化改造的支持：从产品型企业的特点来看，个人对其产品的理解是这些企业所售的产品本身具备所服务行业或用户所需要的共同功能，在具体实施时会根据具体的用户进行一些二次开发，当然如果产品本身较为智能或强大的化，仅通过一些配置即可实现具体用户的个性化需求。总结一句话，便是产品型的企业所积累的公共组件更多，而且注重公共组件的不断加强，使得面对个性化需求时所需的二次开发相对较少，。而项目型的企业积累的公共组件较少或者没有，相对公共组件而言，可以说每个项目都是二次开发，那么形成的资源浪费当然更高。公司提出了向产品服务型企业转变的战略思想，并开展了产品研发的业务，那意味着我们的产品或生产过程也将具备“强化公共组件积累，二次开发较少”特点。而我们的版本控制更侧重于结项时的基线管理，更关注项目结束时的一个功能固化，忽略了在生产过程中对通用功能的拆分和积累。比如我们目前有些系统已经具备产品的特征，并且有多个用户使用，这些用户使用的可以说是一个品牌的不同系列，就像大家都开奥迪，一个是A1，一个是A6，可是有很多共同之处。但是对我们对这样的软件产品的代码管理却是分开管理的，放置在不同的项目库中，公共功能和个性功能混合管理。假设我们需要在另外一个省网上线时，我们能否快速组装出一个具备基本功能的系统，在此基础上进行二次开发？我们组装的这个基本产品是否能达到最优，使二次开发的功能最少？
（2）对通用产品组装的支持：目前我们配置管理仅能支持全功能的产品组装形式。虽然市场上很多系统是通过授权许可或权限来控制用户对产品功能的使用权限，但是个人觉得依然不是太安全。其实很多程序员都有这样的经历，当某些产品只能使用部分功能时，我们找各种办法去破解许可证或系统权限管理功能来获取整个产品的使用权。市场上既然有很多产品采用这样的功能控制方式，一定有其优势，但是也有采取补丁形式不断的补充系统功能的方式，假如我们未来考虑采用这样的方式，我们的配置管理应提供或考虑提供这样的支持：需要几个功能组装几个功能，并且尽量减少缺陷。
（3）对固化软件生产线的支持：固化生产线，大家可以回顾下2.4的内容。目前公司有部分部门已经通过探索应用拥有了自己的生产线，迈出了工业化的第一步，而这些非常有用的经验还没有在交流沟通中发挥更大的作用。公司已提出生产一体化，配置库也是软件生产中很重要的一环，我们要把这些好的经验积累下来，形成方法论以供更多的人借鉴和使用，让我们的软件生产像制造业一样，可以根据产品的特点建立更高效的生产线，使软件生产过程中的需求、设计、编码、测试、实施、运维等各个工序连接更平滑，让我们的软件生产也“流水线”。
4.2配置管理建设建议
4.2.1借鉴硬件的配置管理思想
通过前面的一些解释说明，我们能感受到软件的配置管理与硬件的零部件管理接近或类似。我们要达到的目标可以说与硬件零部件管理是一致的，最终都是为了能够快速的在现有的零部件中提取正确的零部件组装为符合用户需求的产品。从管理内容与管理目标上都是一致的，我想我们从硬件产品组装的角度去思考配置管理如何做，会有更多更好的想法。
4.2.2深化SVN的应用，强化配置管理流程的建设
我们现在使用的配置管理工具是SVN，但对SVN深入了解的人却很少。从SVN自身功能上讲，SVN确切的说是一个版本管理工具，它可以记录使用人员的对库内文件的每一次改动；通过分支/合并模式可以支持并行开发；通过日志描述可以快速掌握变更原因，确认变更的落实情况，需要回退时，保证能够快速回退到正确的版本；配合规范的提交、更新机制可以使项目经理更准确的掌握开发进度和BUG修改情况，掌握每个团队成员的工作量、未通过正式评审的工作比例等；结合开发流程合理划分与管理存放源代码的文件夹，可以确切的掌握每个源代码文件的当前状态，在必要时快速提取到正确的文件组装成软件产品。当然SVN还有更多功能，需要我们深入的研究。
从配置管理流程方面讲，我们需要不断的提升流程的管控能力。比如我们目前更关注变与不变的控制，而没有有效的落实变更审批后的结果：是否遵行了变更审批、变更之后是否符合要求等；在配置审计方面，我们审计更关注管理过程，比如构件是否提交了、配置项是否规范命名，而没有从生产的角度去落实构件是否齐全了；构件的内容是否正确，比如设计说明书中描述的功能是否和实际的产品功能一致；提交的基线整体是什么情况，一个缺陷都没有，还是包括了若干个不重要的缺陷等等，我们需要有效的配置管理流程去保障这些构件的变化确实需要，并且在适当的时机记录了这些变化，以便我们需要时能够提取正确的版本构件。
4.2.2利用好SVN这个仓库
这里单独说SVN，是希望大家重视SVN这个仓库的分类使用。我们的所有产品组件都放在这里，我想可以借鉴一下硬件保管的思想，不同的仓库放置了不同的零件，对这些组件合理的分类，也能够在组装产品方面提升不少效率。分库管理在部分部门应用已非常普遍了，但随着公司研发业务的发展，我们目前的一些配置库在部分工作的支持上还不够广泛全面，当然相关的辅助工作就更难入手。我们需要更深入的研究分类管理的思想，根据不同的需求来采取不同的“仓库”建设策略。比如我们可以根据组件的类别来分类管理，可以根据组件的状态来分类管理，可以根据产品整体的状态来分类管理等等，由于扩展开需要更多的讲解，本文主要是提出一些指导性建议，这里就不细讲了，欢迎大家来交流。
五、也许还有另外一种惊喜
配置管理能够给我们带来什么好处，我想通过前面的诸多说明，其好处已不言而喻。那么还有什么呢？前面我们提到软件工业化，如果软件可以像硬件一样组装，那么应该也可以像硬件销售一样，拆分销售。也许有一天我们可以将我们生产过程中产生的、无法使用在我们自身系统上的组件以“零件”的形式销售，这样就减少了劳动力的浪费。当然前提是我们能够找到这些对我们来说无用的构件。那么研究下配置管理吧。
|
