软件配置管理

软件配置管理——对软件成果的有效保护原作：林锐博士Page2目录1.什么是软件配置管理2.为什么需要配置管理3.人的问题4.软件配置管理规范：概念与流程5.软件配置管理规范：配置管理计划6.软件配置管理规范：版本控制规则7.软件配置管理规范：变更控制规则8.软件配置管理规范：配置库操作9.软件配置管理规范：配置审计10.常用配置管理工具参考书：《软件工程与项目管理解析》，林锐著，电子工业出版社，2003Page31.什么是软件配置管理1.1忏悔录曾经有一个很好的配置管理工具在我面前，我没有理睬，直到版本混乱的时候才后悔莫及，工作中最大的痛苦莫过于此，如果上天再给我一次机会的话，我向对它说三个字：我要你。如果非得加一个期限的话，我希望是一辈子。1.2概念不要和“计算机零配件组装”搞混淆。软件配置管理（SoftwareConfigurationManagement,SCM）是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。配置管理与任何一位项目成员都有关系，因为每个人都会产生工作成果。配置管理是否有成效取决于三个要素：人、规范、工具Page41.什么是软件配置管理1.3配置管理的商业理念企业的商业需求决定了配置管理的力度，我们不必追求完美无缺的配置管理，而是让开发团队恰好够用就行，并将为配置管理所付出的代价控制在预算之内。富有成效的配置管理的特征：–任何项目成员都要对其工作成果进行配置管理，应当养成良好的习惯。不必付出过多的精力，最低要求是保证重要工作成果不发生混乱。–配置管理规范应当清晰明了，便于执行，不必在细节方面要求太多，不给项目人员添加过多的负担，不使人厌烦。–选择配置管理工具应当综合考虑价格、易用性和功能因素，而不是购买最先进的工具。令人满意的工具通常是价格低廉、简便易用、功能恰好够用。CMM/CMMI对配置管理过程域论述得十分清楚详细，假设完全按照CMM/CMMI的要求执行的话，你可以得到100分（满分）的配置管理成绩。–出于商业利益考虑，我不向往100分的成绩，因为代价太高了。我更愿意付出前者的30％左右代价获取60－70分（及格）的成绩，这样最划算。–70－100分的配置管理成绩对于大部分商业软件而言没有多少意义，那属于锦上添花，如果我们没有足够的精力的话，那么就以最低的代价达到及格分数就行了。Page52.为什么需要软件配置管理2.1如果没有软件配置管理，将有什么坏处？最大的麻烦是工作成果被覆盖。如果不采用配置管理软件来保存工作成果的历史版本的话，人们在同一个文件上修改内容，保存之后，那么新的内容覆盖了老的内容。–多数情况下新的内容比老的内容好，覆盖了也没关系。但是总有不少意外，例如程序员修改了老程序员之后，突然发现新程序是错误的，而老程序却是对的，可是老程序被新程序覆盖了，再也无法恢复。–怎么办呢？还能怎么办，只好重新写老程序再覆盖新程序呗，可是过一阵子又发现新程序也又可取之处，这时却无法恢复新程序了，只好重新写新程序再覆盖老程序，…如果你经常碰到这样的事情，你会发疯的。–为了避免成果被覆盖，很多人采用最原始的手工管理版本的方式，例如给文件加后缀“-01”、“-02”以表示版本。天长日久，工作目录下就会有一堆带数字后缀的文件，而且你自己也忘记了数字后缀代表什么内容，管理起来非常麻烦。–我在读大学的时候，我自己以及周围的人都不知道软件配置管理，所以大家都有上述经历。幸好在学校里的人时间不值钱，工作成果也不值钱，可以穷折腾。但是在企业里工作，我们可不能不懂软件配置管理，否则就贻误工作浪费金钱了。Page62.为什么需要软件配置管理2.2使用软件配置管理，将有什么好处？最直接的好处是工作成果的所有版本都被保留着，不会丢失也不会被覆盖，你不会气得发疯了。–如今硬盘的存储空间价格低廉，用于保存历史版本的存储空间的成本可以忽略不计。如果你保存了工作成果的100个历史版本，哪怕99版本都是“垃圾”，只有一个版本里有“黄金”，那也值了。所以你尽管放心保存历史版本好了，累的是计算机又不是你，你怕什么。间接的好处是，项目的所有工作成果被完整地保留下来，这是企业的知识财富，可以被人们很好地分享利用。而且减少了人员辞职造成的损失，企业老板可以放心很多了。–因为如果没有配置管理的话，人走了，即使他把成果刻录成光盘交给接收者，别人也搞不清楚那些成果的演化过程。我在事业部推广CMM的时候，有一天事业部总经理郑重其事地找我商谈，说某个产品线的经理要“跳楼N次”，请大家帮忙“解救”。因为他把更新北京客户的软件安装到天津客户那里，却把更新天津客户的软件安装到其他客户那里，现在他自己也搞不清除发生了多少错乱！如果跳楼一次能够消除一个错乱的话，那么他要跳楼N次。–这是典型的版本错乱问题，只有良好的配置管理才可以解救这位产品经理。Page73.人的问题3.1事在人为配置管理的方法是成熟的，而且相应的软件工具也是成熟的，基本上不存在看不懂、不会用的问题。配置管理的执行效果如何，完全应了中国的一句老话“事在人为”啊。妨碍配置管理的主要问题是人们“嫌麻烦”（还有侥幸心理）。在没有出乱子的情况下，执行版本控制看起来有些麻烦。每次修改工作成果的时候，总是先checkout，然后再修改，最后还要checkin，多了前后两步。–其实checkout和checkin两步操作只需花费几秒钟，而且不费脑子，凭良心说根本没有添加麻烦，仅仅是个人感觉不爽快而已。然而不执行版本控制的话，万一发生工作成果被覆盖或丢失等问题，那么麻烦就大了。–很多老百姓有闯红灯的不良习惯，本来只要等十来秒钟就可以安稳上路的，可就是感觉麻烦，就急着要闯红灯。人们平时不知浪费多少时间，你又何必节约这十几秒钟呢。在没有发行交通事故的时候，你闯红灯后有一股赚了的快感，万一你运气不好躺在医院里，就后悔莫及了。–所以不要嫌配置管理麻烦，这点小麻烦是为了避免你遇到大麻烦。侥幸心理导致人们麻痹大意。我也有这个毛病，我非常清楚版本控制的重要性，也能熟练使用配置管理软件，可是我常常把一个文件checkout出来后，修改了一两周后才checkin进去。–我只敢对个人文件的配置管理存在侥幸心理，我从来不敢轻视软件产品的配置管理。因为前者出乱子的代价比较小，我承受得起，后者出乱子我可承受不起。（例如Future软件的配置管理）。Page84.软件配置管理规范：概念与流程4.1配置项软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被妥善地保管起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。凡是纳入配置管理范畴的工作成果统称为配置项（ConfigurationItem，CI）。配置项主要有两大类：–属于产品组成部分的工作成果，例如源代码、需求文档、设计文档、测试用例等等。–在管理过程中产生的文档例如各种计划、监控报告等等，这些文档虽然不是产品的组成部分，但是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。4.2基线基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。Page94.软件配置管理规范：概念与流程4.3角色为了提高配置管理的效率和安全性，项目应当设有配置管理员这个角色。配置管理员的主要工作是为项目制定配置管理计划，创建和维护配置库等。对于大型的项目，鉴于配置管理的重要性和复杂性，机构应当设立配置控制委员会（ConfigurationControlBoard，CCB）。CCB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者。对于普通的小型软件项目而言，CCB这个概念难以落实，我们就不要玩虚的了，让项目经理或者配置管理员做决定就行了。4.4流程Page105.软件配置管理规范：配置管理计划配置管理员根据本项目的特征，起草配置管理计划，由CCB负责人（通常是项目经理）审批。配置管理计划的主要内容：–1.人员与职责–2.软件硬件资源–3.配置项计划–4.基线计划–5.配置库备份计划–6.版本控制规则–7.变更控制规则–8.审批模板见word文档Page116.软件配置管理规范：版本控制规则6.1概念版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。–所有项目成员都必须遵照版本控制规程操作配置库。配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。配置项状态变迁：–配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。Page126.软件配置管理规范：版本控制规则6.2版本号（1）处于“草稿”状态的配置项的版本号格式为：0.YZ–YZ数字范围为01-99。–随着草稿的不断完善，“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。（2）处于“正式发布”状态的配置项的版本号格式为：X.Y–X为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。–配置项第一次“正式发布”时，版本号为1.0。–如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。（3）处于“正在修改”状态的配置项的版本号格式为：X.YZ–配置项正在修改时，一般只增大Z值，X.Y值保持不变。–当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。参见规则（2）。Page137.软件配置管理规范：变更控制变更控制的目的是防止配置项被随意修改而导致混乱。–为了提高效率，对于处于“草稿状态”的配置项，不必进行变更控制，因为它们本来就是草稿，本来就是要被不断地修改的。–当配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）时，如果要修改配置项的话，那么按照变更控制规则执行。步骤：–第一步变更申请。变更申请人向CCB提交变更申请，重点说明“变更内容”和“变更原因”。–第二步审批变更申请。CCB负责人（或项目经理）审批该申请，分析此变更对项目造成的影响。如果同意变更的话，则转向第三步，否则终止。–第三步安排变更任务。CCB指定变更执行人，安排他们的任务。CCB需要和变更执行人就变更内容达成共识。–第四步执行变更任务。变更执行人根据CCB安排的任务，修改配置项。CCB监督变更任务的执行，如检查变更内容是否正确、是否按时完成工作等。–第五步对更改后的配置项重新进行技术评审（或审批）。–第六步结束变更。当所有变更后的配置项都通过了技术评审或领导审批，这些配置项的状态从“正在修改”变迁为“正式发布”，本次变更结束。在实际操作中，审批变更申请并非总是“客观公正”的，人们并不在乎变更申请是否合理，关键看是谁提出变更申请。官儿越大的人提出的变更申请总是优先处理的。Page148.软件配置管理规范：配置库操作所有人员都依照配置管理规范和计划来操作配置库。配置管理员的主要操作有：–创建配置库，并且至少创建配置库的所有第一级目录。–为每个项目成员分配