【IT168 技术文章】
2007年8月30日，IBM在京举行了主题为“整合 治理 协作 创新”的IBM 2007 开发者高峰论坛，IBM与1000多名与会者分享了最前沿的软件开发理念——加强跨地域开发团队的协作、突出模块化在软件开发中的价值和将科学的治理观引入软件开发，同时发布了与这些理念相对应的一系列新产品和解决方案。CIOAge.com与51CTO.com共同对Rational高峰论坛进行了全程网络视频直播并制作了专题页面 http://www.51cto.com/exp/830Rational/。
在当日下午的循规方案分论坛上，来自东软公司的王爱民博士与大家分享了BS项目配置管理工作的体验，以下是他的演讲实录。
我们知道Rational的CC&CQ是一个非常好的管理的工具，必须有一个方法论的支持，还有一个好的模式支持可以起到一个事半功倍的作用。这是我的一个主要演讲的内容的提要。我们首先问大家什么叫软件配置管理，我们到底配置的管理需要做什么呢。我认为这个问题，虽然说我们都是做开发的，虽然我们不爱做配置管理，但是配置管理到底包含哪些内容，到底要做什么，或者说我们的开发团队都不是很清楚的问题。这是ISO9000的定义，配置管理是一个管理学科，它对配置的开发和支持在技术上的和管理上的指导，还有一个应用取决于项目的规模、复杂程度和风险大小。
还有一个Wayne Babich的解释，软件给配置管理能协调软件开发，使混乱减少到最小，目的是最有效的提高生产效率。我们在看CMMI的定义，是应用于软件开发的技术和管理方法和监控的学科，包括以下几个方面的范畴，第一要识别和证实一个配置项的功能和物理特征，还要控制配置项物理特征的变更，记录和报告变更过程和实施项目，还有验证开发是否与特定的需求相匹配。
我认为这是CMMI的定义。我认为合理和合适的定义是通过对软件产品生命周期的不同时间点的产品配置项进行标识，并对标识的产品配置项的更改进行系统控制，从而保持产品完整性、一致性和可溯性的过程。
我认为实际上配置管理工作重要的就是这几点，我们所有的东西配置库上做操作，在这个上面做工作，首先有一个配置管理的计划，之后做管理控制，变更控制，要做配置审计，做版本控制，重要的五项原则。我认为只有把这五点确实落定之后，可以用好的工具实现它，才可以做到真正的配置管理。
首先回顾一下我们事业部使用CC&CQ的过程，我认为我们部门从2003年开始进行考察和评估一直到现在，经历了将近三年的一个过程，这个时间是挺长的，我认为分为几个期，摸索期、导入期，成长期，成熟期，导入期里面很痛苦的，我们原来用的是这个系统的转变是需要费很大的功夫的，需要大量的强制性的使用。大约到成长期的时候，整个事业部全面启动CC&CQ、UCM的使用，制定一个自己的管理体系，这个是产生我们的配置管理体系的1.0的文件。那么到成熟期的时候，也就是说整个配置管理深入人心了，成为大家一个自动的活动，并且在不断改进和完善这个配置管理的体系。换句话说，好的工具不一定成为好的效果，但是没有好的管理一定不会产生好的效果，好的管理碰上好的工具才能真正达到我们想要的一个项目的成功和作用。这是一个回顾情况，这里声明一点从使用到成熟可能需要两到三年的时间。换句话说，这个管理的工作不是一蹴而就的，是需要时间的不断摸索、积累、是需要持续改进的。这里我简要介绍一下我们目前配置的情况。
我们这套配置库是中国或者世界比较特殊的方式。我们整个的操作系统CC的操作系统用的是RHEL4，还有LINUX里面，做整个控制器，模拟整个WINDOWS开始出现的考虑我用我的开发在UNIX还有在LINUX环境。还有一点我的文件采用的是reiserfs的操作系统，而REISERFS的文件系统对小的文件系统是最优的，对于我整个的机器的性能都是一个翻倍的甚至于一个数量级的提高。我们在看我是双机的通过HA的做双机备份，换句话说我们本身做电信业务的，我这套配置库也是电信级的，可以保证7×24小时稳定的运行。我认为我们大多数厂家没有对配置库提高到这么高一个程度，如果宕机了，这个盘毁掉的话，可能所有的都毁掉了。我现在特别强调的是你的配置环境，是不是真正的安全可靠，如果是真正的安全可靠，或者说我这个配置库可有可无的情况下，那我认为根本没有这个配置。所以说也是配置管理的第一条，一定要在安全的配置库中进行文件的标识和存储。我们的开发环境，因为我们有每个每个现场，每个现场之间通过2兆的专线做的CCRC。我开始说了五点，要做配置管理的计划，要做版本控制，要做变更、审计，所有的东西都便于操作。
现在看配置管理计划，要做什么呢，主要的内容包括人员和职责，软件硬件资源，配置项计划，基线计划，配置库备份计划，版本控制规则，变更控制规则，以及审计。我记得去其他的公司交流的时候，他们非常郁闷，首先他们交流做的时候，根本不做配置管理系统，或者不知道配置管理计划是做什么的。换句话说，如果你做管理的话你先要有计划，如果没有计划，不知道你的管理做什么。这是我们一个做的一个项目，做电信的一个项目，投入到150人，最高到170人的一个团队。一个150人的团队，没有一个很好的计划，没有很好的管理，最后的集成也好，还有项目的上线等等，包括CCB成员、配置库，你的流的策划，你的产品发布的计划，你的版本的计划，以及你的审计。你到底要做什么，什么时候建立基准，你的内容是什么，谁审批的等等。当你做完版本之后，所有的变更，变更的记录情况什么样，变更的描述，包含哪些内容，以及审计。你配置库的建立，配置库的权限，到底要怎么做，目录怎么规划，每个目录群是什么样的，这些都是需要你很好的规划的。我们现在看一下所谓版本控制，IBM Rational的CC提供很多的版本的策略，包括UCM，包括背景方式都有很多。我们知道这种流的策略，你可以根据你的项目的情况，管理的情况要做相关的取舍，我们采用feature流的策略，采用两层流架构，开发流，集成流进行项目的配置管理工作。开发流是开发人员日常工作使用的工作空间，相对独立的。集成流是一个产品稳定版本流，也是获取项目发布程序的空间，以控件为单位实施版本控制设立并管理基线。我可以通过基线实现整个版本的控制。第四设立并管理基线，因为所有的IBM的CC也好CQ也好都是集成的，都要创建一个活动。
当然CC和CQ肯定是支持这种并发的集成工作，我们需要尽早地集成，还有每日的集成。这是我们做项目的一个流程，我们要做版本构件也好，每日构建的时候，要锁定这个流。就是说对于一个做150人的大型项目的时候，必须要做这种尽早地持续地集成，否则的话项目后期的话，每个项目和模块之间，子系统和子系统之间可以集成在一起，能不能发布是不可控制的，所以要尽早地集成、持续地集成，每日的集成。我们也对使用CC和CQ的基础上，要进行代码统计，为了使我们量化管理，可以改进我们的整个的产品线。我们说做代码统计的目的当然是用来度量和评估这个软件产品，对于项目的开发的预测。你的生产效率到底是多少，每个月500行，每个月600行还是每个月2000行。那么衡量的结果当然可以衡量一个软件的成本，并且提高性能和复杂度。你说三个月后上线，半年以后上线的依据是什么，这个是要做评估的。那么统计的方式里面，当然可以由根据当前视图，两条基线之间的，还有activity之间的。
那么实际上我认为我们大家都在做版本控制。但是对于变更控制，我认为管理并不是很多。也就是说当我打了一条基线之后，如果修改的话，那必须要按照这种变更控制的原则去执行。如果我们建立一条基线，你没有做变更控制，你没有做这种变更的申请、审批的流程，最后无论是集成流也好，实际上是不可控制的。我们看变更控制的一个步骤，第一步要做变更的申请。你的变更申请人要向CCB提交变更申请，重点说明理由和原因，我到底要变更哪些配置项，变更的会不会受到其他的影响，对规模和成本有什么影响，对进度、验收日期，还有软件质量的影响。这是我们说的一个审批的流程，那么从变更申请到CCB审批、如果通过之后，要安排相关的工作。这个里面是导到CC和CQ里面去的，状态是一个开放的，这是整个的一个流程，那么变更之后要对结果进行审计、进行记录。当你变更之后，所有的变更操作要做相关的内容记录，你的变更的描述、变更的内容，最后审批的内容什么样的，对其他有没有什么影响，都是要做的。
这是我们部门的整个闭环的一个流程。我们知道刚才大师也讲了需求肯定一直在变化的，整个的需求管理我们有一个自己的流程。我们这个系统更像一个办公系统，用户把需求入进来，我们大家要做分析、审批，要看，是不是合同内合同外的，是不是要做。如果确认这个东西要做的话，才会变成一个开发任务，才会进入我们的CQ。同样我们的产品发现了一些Bug，东软有一个产品叫Bug Base，到这么一个系统来进行管理，这个里面有测试用力，测试大纲，测试方案等等，如果发现Bug，并且确认之后也会找到CQ，会形成一个任务，找到开发人员做相关的工作。这个里面相当于有一个变更的流程。同样我们的项目计划，同样也可以通过集成的方式，找到CQ里面去，然后形成任务。换句话说，无论是需求也好，还是我们的计划也好，最后全部形成一种开发任务，这样的话，就形成了整个闭环的管理流程，这样的话数据基本上全部可以提出来，可以做相关的量化指标，对我项目的监控。这是一个例子，某个需求自动导入CQ。所有的这些需求必须有跟踪的，需求的来源，需求地基本信息什么样的，开发的状态、测试的状态什么样的，我们是面向客户的，还有一个现场的状态如何，最后测试是否通过，客户认可与否，从入口到出口是有一个相关的关系的。这是一个需求的处理流程，需求分析，然后进入开发，然后会导入，最后有一个操作，然后最后扭转。
这是一个演示，是PSM或者PM有一个计划，形成一个任务，会自动通过CQ导入到CQ里面去，形成一个开发任务分配给开发人员。这是一个Bug导入的，当某一个项目，发现了一堆的问题，发现人是谁，状态如何，已经确认的需要修改，它也会自动地导入到CQ里面去。我们知道CQ很强大，会提供很多的接口做这些事情。这是Bug处理流程，先是提交，然后待改状态的问题卡，如果问题确认之后，会返回到流程。当某一个Bug出现的时候，不是一两个工作人员可以做好的，当某一个需求被开发人员需要多个模块多个工作人员配合的时候，会产生这种子任务。换句话说，有一个任务关联，有一个副任务可以代替一个子任务，只有子任务关闭副任务才可以关闭，只有每一项都完成，最后副任务才可以都完成。
我们采用一种复合基线的方式管理Component。我们更好地更快地构建一个大的子系统，或者一个大的系统。第二一点，我们严格按照配置管理计划来建立基线。我们什么时候建立一个基线，什么时候建立一个基准。如果建立之后需要修改的话，必须提交变更申请。如果需求变了，后面一串全变了，然后待设变了，后来详设也变了，当你锁定基线之后，你后面的变更必须进行修改。我们做一些大项，如果发现这个问题对我的影响很小，需要改一下就可以了，但是这个改动对其他的模块和其他的子系统影响很大，当我锁定基线之后，它的变更必须发出申请，即使对大家没有影响，也需要告诉大家一下，我变更什么东西，大家看看这个东西是否有影响，我是不是要跟着变，是不是跟着改，如果需要的话，你这个改动对我是有影响的，我要跟着改。所以说变更申请不是增加工作量，可以使我们的工作更加制度化。变更申请也通过了，也修改了，最后修改之后要对基准进行变更。我们说有计划，配置工作，还有做变更管理，还要做审计。我们说审计的目的是确定这个产品是不是符合功能和物理方面的需求，第二要确定工件存储在已控制的库中，第三要确保工件和基线可用。我做了一个基线，我做了一个版本必须可用的。因为我们部门最后的实现，实际上QA和CM组织配置审计的，第二要严格按照配置管理计划进行配置审计，跟踪不符合问题的处理，更新不符合问题跟踪表。这是一个配置审计的一个记录。我们大家可以看到，基本上什么时间建立的，审计的内容，要不要修改，修改的建议是什么。这些都是需要做的。
我们把主要的几项内容讲完了之后看一下。我们刚才提到的我们做联通新一代的BSS项目。因为我们知道联通的需UCM的建设，是一个售前、售中的一个系统。把我们原先的很多系统融合成一个新一代的子系统。大家知道，一个150人到170人的团队作战，如果这个版本控制不好的话，将出现灾难。所以说有了这套很好的管理的方式，才能够保证整个版本是稳定的，是可靠的。举一个例子来说，比如说在这儿，本来在这个点准备要做一次上线，比如说0.8版，我们把它推到我们的生产系统，我们验证、测试，发现问题及之后要处理，然后要解决办法，还要很多的需求，我们在一个月内处理了700多个问题，我们不断地更新升级，不知道最后能不能控制住，我们4月15日正式上线了，我们封了一条1.0的基准，那么当我们把1.0和正式环境上面的版本拿下来的时候，是非常令我惊讶的，我们没有想到的是我们的配置库上的版本和我们生产环境几乎是一模一样的，我们以前不可想象的，我们也做过这种事情，配置库没有出错的概率非常小，几乎是没有可能的，为什么没有问题呢，实际上我认为不是工具本身的问题，而是你管理的问题，你只有管理到位，你才不会出现问题，否则的话，如果管理不到位，大家的意识不在配置库上工作，不做变更申请，最终这个版本肯定是否定了。所以说一个好的管理必须有一个好的团队，而且整个团队的意识必须跟的上，我们用三年的时间才可以走向成熟，就是大家管理工作的意识问题。整个的项目工作完全依赖于配置库，才能保证版本的一致，整个系统稳定的运行。还有我们提升了QCD的三个指标上，你要提高质量，你要降低你的消耗，你要按期地能够交付。那么提高你的生产质量，自然而然可以上来了。
在我的片子里面，基本上给大家做了一个简要的总结。基本上我们讲到了配置管理的非常好的实践，一共有十条，这是大家公认的：在安全的存储库中进行工件的标识和存储；控制并审计对工件的变更；记录并跟踪变更请求；维护稳定、一致的工作空间、以控件为单位实施版本控制；支持对工件和构件的并行开发；设立并管理基线；使用活动来整合最低版本，尽早集成、持续集成；确保软件构建的再现性。
我们150人的团队，每天集成作战，最后版本没有出现问题。我们说工欲善其事，必先利其器，如果你没有管理好的工具，你最后落实下去的话，还是管不好，最后的上线还会出现问题。虽然说我们可能有一套好的管理思路，但是说有一套好的工具的话，更合适的。我们从2004年开始买，Rational是乙方，我们是甲方，甲方为乙方服务好，是天经地义的事情。这个BS项目配置管理工作的巨大成功，使我感觉到我应该好好的谢谢Rational，我向Rational和IBM表示真心的发自肺腑的感谢，谢谢大家！
