三、我们的认识误区
　　为什么想要讲配置管理的误区呢？通过我们的实践来看，我们使用了配置管理工具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这个仓库的分类使用。我们的所有产品组件都放在这里，我想可以借鉴一下硬件保管的思想，不同的仓库放置了不同的零件，对这些组件合理的分类，也能够在组装产品方面提升不少效率。分库管理在部分部门应用已非常普遍了，但随着公司研发业务的发展，我们目前的一些配置库在部分工作的支持上还不够广泛全面，当然相关的辅助工作更难入手。我们需要更深入的研究分类管理的思想，根据不同的需求来采取不同的“仓库”建设策略。比如我们可以根据组件的类别来分类管理，可以根据组件的状态来分类管理，可以根据产品整体的状态来分类管理等等，由于扩展开需要更多的讲解，本文主要是提出一些指导性建议，这里不细讲了，欢迎大家来交流。
　　五、也许还有另外一种惊喜
　　配置管理能够给我们带来什么好处，我想通过前面的诸多说明，其好处已不言而喻。那么还有什么呢？前面我们提到软件工业化，如果软件可以像硬件一样组装，那么应该也可以像硬件销售一样，拆分销售。也许有我们可以将我们生产过程中产生的、无法使用在我们自身系统上的组件以“零件”的形式销售，这样减少了劳动力的浪费。当然前提是我们能够找到这些对我们来说无用的构件。那么研究下配置管理吧。