配置管理知识.docx
《配置管理知识.docx》由会员分享，可在线阅读，更多相关《配置管理知识.docx（68页珍藏版）》请在冰豆网上搜索。
配置管理知识
实战Rational东软公司BS项目配置管理案例
实战Rational东软公司BS项目配置管理案例【CIOA报道】2007年8月30日，IBM在京举行了主题为“整合治理协作创新”的IBM2007开发者高峰论坛，IBM与1000多名与会者分享了最前沿的软件开发理念——加强跨地域开发团队的协作、突出模块化在软件开发中的价值和将科学的治理观引入软件开发，同时发布了与这些理念相对应的一系列新产品和解决方案。
CIOA与51CTO.com共同对Rational高峰论坛进行了全程网络视频直播并制作了专题页面
在当日下午的循规方案分论坛上，来自东软公司的王爱民博士与大家分享了BS项目配置管理工作的体验，以下是他的演讲实录。
我们知道Rational的CC&CQ是一个非常好的管理的工具，必须有一个方法论的支持，还有一个好的模式支持可以起到一个事半功倍的作用。
这是我的一个主要演讲的内容的提要。
我们首先问大家什么叫软件配置管理，我们到底配置的管理需要做什么呢。
我认为这个问题，虽然说我们都是做开发的，虽然我们不爱做配置管理，但是配置管理到底包含哪些内容，到底要做什么，或者说我们的开发团队都不是很清楚的问题。
这是ISO9000的定义，配置管理是一个管理学科，它对配置的开发和支持在技术上的和管理上的指导，还有一个应用取决于项目的规模、复杂程度和风险大小。
还有一个WayneBabich的解释，软件给配置管理能协调软件开发，使混乱减少到最小，目的是最有效的提高生产效率。
我们在看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成员、配置库，你的流的策划，你的产品发布的计划，你的版本的计划，以及你的审计。
你到底要做什么，什么时候建立基准，你的内容是什么，谁审批的等等。
当你做完版本之后，所有的变更，变更的记录情况什么样，变更的描述，包含哪些内容，以及审计。
你配置库的建立，配置库的权限，到底要怎么做，目录怎么规划，每个目录群是什么样的，这些都是需要你很好的规划的。
我们现在看一下所谓版本控制，IBMRational的CC提供很多的版本的策略，包括UCM，包括背景方式都有很多。
我们知道这种流的策略，你可以根据你的项目的情况，管理的情况要做相关的取舍，我们采用feature流的策略，采用两层流架构，开发流，集成流进行项目的配置管理工作。
开发流是开发人员日常工作使用的工作空间，相对独立的。
集成流是一个产品稳定版本流，也是获取项目发布程序的空间，以控件为单位实施版本控制设立并管理基线。
我可以通过基线实现整个版本的控制。
第四设立并管理基线，因为所有的IBM的CC也好CQ也好都是集成的，都要创建一个活动。
当然CC和CQ肯定是支持这种并发的集成工作，我们需要尽早地集成，还有每日的集成。
这是我们做项目的一个流程，我们要做版本构件也好，每日构建的时候，要锁定这个流。
就是说对于一个做150人的大型项目的时候，必须要做这种尽早地持续地集成，否则的话项目后期的话，每个项目和模块之间，子系统和子系统之间可以集成在一起，能不能发布是不可控制的，所以要尽早地集成、持续地集成，每日的集成。
我们也对使用CC和CQ的基础上，要进行代码统计，为了使我们量化管理，可以改进我们的整个的产品线。
我们说做代码统计的目的当然是用来度量和评估这个软件产品，对于项目的开发的预测。
你的生产效率到底是多少，每个月500行，每个月600行还是每个月2000行。
那么衡量的结果当然可以衡量一个软件的成本，并且提高性能和复杂度。
你说三个月后上线，半年以后上线的依据是什么，这个是要做评估的。
那么统计的方式里面，当然可以由根据当前视图，两条基线之间的，还有activity之间的。
那么实际上我认为我们大家都在做版本控制。
但是对于变更控制，我认为管理并不是很多。
也就是说当我打了一条基线之后，如果修改的话，那必须要按照这种变更控制的原则去执行。
如果我们建立一条基线，你没有做变更控制，你没有做这种变更的申请、审批的流程，最后无论是集成流也好，实际上是不可控制的。
我们看变更控制的一个步骤，第一步要做变更的申请。
你的变更申请人要向CCB提交变更申请，重点说明理由和原因，我到底要变更哪些配置项，变更的会不会受到其他的影响，对规模和成本有什么影响，对进度、验收日期，还有软件质量的影响。
这是我们说的一个审批的流程，那么从变更申请到CCB审批、如果通过之后，要安排相关的工作。
这个里面是导到CC和CQ里面去的，状态是一个开放的，这是整个的一个流程，那么变更之后要对结果进行审计、进行记录。
当你变更之后，所有的变更操作要做相关的内容记录，你的变更的描述、变更的内容，最后审批的内容什么样的，对其他有没有什么影响，都是要做的。
这是我们部门的整个闭环的一个流程。
我们知道刚才大师也讲了需求肯定一直在变化的，整个的需求管理我们有一个自己的流程。
我们这个系统更像一个办公系统，用户把需求入进来，我们大家要做分析、审批，要看，是不是合同内合同外的，是不是要做。
如果确认这个东西要做的话，才会变成一个开发任务，才会进入我们的CQ。
同样我们的产品发现了一些Bug，东软有一个产品叫BugBase，到这么一个系统来进行管理，这个里面有测试用力，测试大纲，测试方案等等，如果发现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表示真心的发自肺腑的感谢，谢谢大家！
如何制定有效的配置管理流程
如何制定有效的配置管理流程
以下是我们在实际工作中遇到的一个例子，这个例子充分说明了正确的工作流程对于保证软件产品质量的重要意义。
1问题描述
某一开发团队为其客户开发业务软件，系统上线之后存在着很多的业务需求变更，同时也有很多业务部门在使用过程中所发现的软件缺陷，我们把需求变更和软件缺陷统称为变更。
开发团队需要迅速响应客户所提出变更请求，把相应的软件版本修复及时地安装到生产系统上去。
为了保证产品质量，该开发团队建立了以下的软件发布流程：
这四个环节分别对应以下四种环境：
开发环境：
开发实现客户的变更请求
测试平台：
开发团队把软件发布给客户之前做内部系统测试
准生产环境：
客户把软件发布到生产系统之前做验收测试
生产系统：
最终的生产系统
当开发团队将变更实现提交用户验收测试时，凡是没有通过验收测试的变更将被拒绝，只有通过验收测试的变更才会被部署到生产系统上去。
整个流程如下图所示，假设开发团队总共实现了3个变更，其中变更1和变更2通过了系统测试被提交用户验收测试，但只有变更1通过了用户验收测试，最终只有变更1被部署到生产系统上。
为了支持这种工作流程，该团队分别在配置管理系统中管理了四种源代码版本：
凡是通过每一个环节的变更所对应的源代码版本将被复制到下一个环节的版本基线中去。
看上去这一流程非常合理，不是吗？
2质量陷阱
让我们来看这种流程的两个应用案例。
场景I：
未经测试的版本组合
在下面的例子中，文件f1、f2在修改之前的版本都是1，在实现了变更1、变更2后，它们的版本都变为了版本2，表示为f1（v2）、f2（v2）。
在整个的测试过程中，前面三个环境上测试的代码版本始终是文件f1和f2的版本2，但是最后变更1没有通过验收测试而变更2通过了，那么最终被部署到生产系统上去的版本将是：
f1（v1，这是f1原来在生产系统上的版本）
f2（v2，其中已包含了变更2所对应的版本2）
但f1（v1）应该是跟f1（v1，变更1修改以前的版本）相匹配的版本组合，跟f2（v2）相匹配的版本组合应该是f1（v2），由此可能发生的结果是：
在生产系统上运行的是未经测试的版本组合!
场景II：
未经测试的版本
在下面的例子中，在前面三个测试环节中，文件f2被测试的版本都是版本4。
当变更2未通过用户验收测试时，文件f2最终被复制到生产系统上的版本为3，这个版本是未经测试的。
结果令人难以置信：
在生产系统上运行的是未经测试的版本?
!
任何一个软件系统，它的所有代码应该被作为一个整体来进行交付，而不是象上述例子中那样只交付部分的代码（变更相关的代码）,这是造成质量陷阱的根本原因。
一个看上去合理的流程存在本质的缺陷。
3改进建议
为了避免以上所述的这些质量陷阱，我们应该改进现有的配置管理流程。
3.1建立闭环的质量保证流程
选成以上质量隐患的根本原因是系统代码没有被作为一个整体来处理，并且在发布过程中我们发布的是源代码，正确的流程（也是业界较为通行的做法）应该发布构建后的目标码而非源代码。
我们可以建立一个闭环的质量保证流程（如下图所示）来批量地进行软件发布。
其中系统测试过程中发现的缺陷应该被开发人员及时改正，然后再做构建，再测试，直到达到一个比较稳定的版本才会发布到验收测试环节。
同样的，验收测试中发现的问题也会回到开发环节进行修复。
这应该是一个多次循环的过程，不断地发现错误，然后改正，再测试。
这个循环到什么时候结束呢？
这个取决于各个软件项目的实际情况：
最理想的情况当然是到所有的缺陷都被改正为止，但是所花的时间比较长，可能赶不上项目的进度要求，现实工作不大可能做到这一点。
折衷的情况是所有严重的缺陷（即那些影响系统使用的的缺陷）都必须被改正，但允许有一些已发现的缺陷遗留到后面再去解决,前提是所遗留的缺陷不会影响其他变更的实现。
大家平时在一些商用软件的新版本中经常可以见到发布说明（ReleaseNotes）中所列的已知缺陷（KnownDefects）就是属于这种情况。
我们向开发团队提出这个建议后，马上遭到项目经理的反对：
“客户有些紧急的变更需要马上实现并交付生产运营，几乎没有时间来走这样完整的闭环流程。
”
3.2区别对待缺陷和新增功能
通过进一步了解我们发现紧急的变更一般是指影响系统正常使用的软件缺陷，这些缺陷需要及时的修复；而新增功能请求一般不是那么紧急的，允许开发团队有一段时间来开发实现。
但开发人员目前是把所有紧急和非紧急的变更请求混杂在一起实现的，往往是一个紧急的缺陷已经修复，但另外一个正在开发中的新增功能也修改了同一组文件版本，造成两者之间的版本依赖，从而导致紧急的缺陷修复不能按时提交。
我们建议把缺陷的修复工作和新增功能的开发工作区分开来，这就涉及到多个版本的并行开发，开发团队主要面临以下三个版本的开发：
v1.0中的缺陷修复
v1.0的新增功能版本v1.1
下一个版本v2.0
这样缺陷修复和新增功能开发相互独立，保证紧急的缺陷修复不会受到新增功能的影响。
3.3发布版本构建（build）而不是源代码
在这个案例中另外有一个不附合配置管理惯例的地方是在开发、测试、验收、生产四个环节发布的都是源代码，分别需要构建（包括编译）过后才能部署到相应的运行平台上。
由于软件构建的结果很可能会受构建平台及相应编译器版本所影响，最终在生产系统上的运行代码（在生产系统上构建得到）与准生产环境上的运行代码（在准生产环境上构建得到）可能不完全一致，有可能造成质量隐患。
比较通行的做法是所有平台上运行的构建代码应该只在构建服务器上生成一次，一次编译到处运行，这样才能保证各个平台上所用到的同版本运行代码是同一次构建的产物。
构建服务器通常就是由开发平台兼任，但如果是发布多个不同运行平台的版本的话，可以有多个构建服务器存在，如：
同一个软件既有AIX+DB2平台的运行版本，也有HPUX+Oracle平台的运行版本。
除了某些特殊的运行环境外，如IBM主机系统（mainframe）上明确要求在运行平台上对源代码进行编译构建，一般软件系统的开发都可以遵循这一个工作原则。
3.4版本发布管理
对于所发布的构建版本，我们也需要进行有序的管理，可以用版本号来唯一标识每一个发布版本。
一般可以把用于开发团队内部系统测试的称之为内部发布版本，把提交给客户的称之为外部发布版本，这两种软件发布版本都要统一编号管理。
在我们的例子中，内部发布版本可以简单地用构建号来表示，如：
v1.0_build_008表示版本v1.0开发过程中生成的第8次构建外部发布版本可以由版本号和发布号组合而成，如：
v1.0_rel01表示版本v1.0的第一个外部发布版本
对于v1.0中的缺陷修复，我们可以通过补丁的方式来发布，一个补丁中可以包含有多个缺陷修复，被修复的缺陷需要在补丁的发布说明（ReleaseNotes）中写明，补丁名称可以由版本号、发布号和补丁号组合而成，如：
v1.0_rel01_p001表示针对发布版本v1.0_rel01的第001号补丁
对于v1.0中新增功能，我们需要制定一个发布计划，根据客户新增功能请求的紧急程度来分期分批实现，一次发布中可以包含多个新增功能，并且包括所有已改正的软件缺陷，这些改动都必须在发布说明中写明，发布版本号可以在前一个发布版本的基础上递增，如：
v1.1_rel02表示版本v1.1的第二个外部发布版本
对于下一个版本v2.0的开发，则与版本v1.0开发的发布管理完全一致，如：
v2.0_build_002表示版本v2.0开发过程中生成的第2次构建
在版本发布管理的流程中，发布版本的安装应该由专门的角色负责，可以是配置管理员或者是集成员（integrator）；开发人员被禁止向各平台（测试平台、准生产环境、生产系统）上安装任何软件，并且各平台上所安装软件的版本号台试.0.0Notes11都应该有详细的记录。
当软件缺陷被发现时，我们就可以明确知道问题究竟是出在哪一个版本。
内部发布版本只会被安装到测试平台上，经过“开发à构建à测试à发现缺陷à修改代码”的多次循环之后，内部发布版本的质量趋于稳定，开发团队才会决定做一个外部发布版本。
外部发布版本被安装到准生产环境上，并且只有通过用户验收测试，它才可以被安装到生产系统上去。
如果该版本没有通过用户验收测试，那么开发团队需要提供相应的补丁来解决用户验收中发现的问题，直到通过用户验收后再将该发布版本及其所有的累积补丁全部安装到生产系统上去。
有些情况下，最终通过验收测试的也可能是下一个发布版本，所以生产系统上安装的发布版本前后之间不一定是连续的，中间可能跳过一些质量不够成熟的版本。
同样的，只有通过用户验收测试的补丁才会被最终安装到生产系统上去。
紧急的补丁经过用户验收测试之后会马上安装到生产系统上，不紧急的补丁可以累积几个以后批量安装上去。
4ClearCase工具实现
配置管理工具IBMRationalClearCase可以很好地支持这种并行开发模式。
在Cl
升级会员 