配置管理规范

文件编码文件密级最新发布日期当前版本XX软件股份有限公司配置管理规范郑重声明：XX软件股份有限公司版权所有。本文档中任何部分未经XX软件股份有限公司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播。变更履历版本日期变更位置变更理由/变更内容变更人备注1.0新建，将原配置管理规范、OSSP中的配置管理规程进行整合，并结合目前公司要求。

目录1 概述 22 术语定义 23 适用范围 34 阅读对象 35 配置管理计划 35.1 配置管理计划流程图 45.2 配置管理计划流程说明 46 配置管理软硬件资源确定 56.1 配置管理服务器 56.2 配置管理工具 67 配置项/文档管理 77.1 配置项识别 77.2 配置项编写及命名 87.3 配置项入库 88 配置库目录结构规划 89 权限管理 99.1 用户角色定义 99.2 配置库操作定义 109.3 配置库授权控制参考 109.4 注意事项 1010 基线管理 1110.1 基线计划制定 1110.2 基线建立时机 1110.3 基线建立流程 1210.4 基线命名规范 1311 分支合并管理 1311.1 分支建立 1411.1.1 分支建立时机 1411.1.2 分支建立模式 1411.2 分支合并 1411.2.1 分支合并类型 1411.2.2 版本库发布模式 1512 代码集成管理 1513 发布管理 1613.1 正式版本发布 1613.2 测试版本发布 1713.3 临时版本发布 1714 变更管理 1814.1 变更控制 1814.2 变更流程 1914.3 变更结束准则 2015 备份/还原管理 2016 生效 2017 参考及附录 20

概述配置管理（CM）的目的是协调软件开发过程、对项目生命周期过程中各种阶段产品的演化和变更进行管理、使混乱（一旦发生，其代价通常都很大）减至最小，从而保证软件工作产品的一致性和完整性。从变更的意义讲，配置管理要解决变更标识、变更控制以及变更发布的问题。配置管理是项目质量管理的重要组成部分，在控制由多人参与项目所生成的大量工作产品时，配置管理过程规范化至关重要。本文档的编写目的是统一软件配置管理规范，为配置管理活动提供指导。配置管理活动主要遵循以下原则：受控：公司所有产品/项目产生的所有工作成果（即信息资产，也体现为配置项）都必须纳入公司统一管理之下，并接受公司级配置管理的监控。安全：所有工作成果都必须存放在配置库，配置库需配备相应的安全管理措施，包括访问控制、备份/还原等。一致：所有工作成果各阶段版本都应该提交到配置库中，而且其内容是一致的，比如工作成果中参考或引用的其他工作成果的正确版本是否存在配置库中或者是否提供了访问链接。完整：配置库中存放的工作成果应该包含产品/项目组全体成员为此项目完成的全部工作成果；要求能够基于配置库的最新内容随时构建无损发布包（包括程序代码、可执行程序和相关文档资料）。及时：立项产品/项目各项工作成果的新建或修订均应该及时纳入配置库。未立项产品/项目的文档应及时纳入公司专门的服务器中。术语定义No.术语定义1配置管理（CM）配置管理是对项目生命周期过程中各阶段产品和最终产品演化和变更的管理，是质量管理的重要组成部分。配置管理通过一系列技术、方法和手段实现：指导和监督对配置项的物理与功能特性的标识和归档工作。控制上述特性的变更，记录并报告变更的处理和实现状态，并验证与需求的一致性。2变更控制委员会（CCB）CCB是一个虚拟小组，由项目监理小组、项目经理、资深项目成员、配置管理员、品质保证工程师等组成，项目经理为CCB召集人；CCB对配置管理各项活动拥有决策权（例如评审计划、评审变更请求等），负责评估和审批配置项的变更、确保所有的变更都是经过审核的。3配置项（ConfigurationItem,CI）配置项是指纳入配置管理范畴的工作成果的最小集合。例如一个文档（如需求文档、设计文档、测试用例、用户文档等属于产品组成部分的工作成果以及项目管理、组织支撑过程域产生的文档）或一组构成独立功能单元的源代码文件都可以定义为一个配置项。4基线（Baseline）基线由一组稳定的特定版本的配置项组成，是进一步开发的基础。基线中的配置项是被“冻结”的，不能被随意修改。基线通常在开发过程中的里程碑（Milestone）处建立，一般包括需求基线、设计基线、开发基线、发版基线、结项基线等。5配置管理员（CMO）每个项目应配备一个配置管理员（可专职或由项目组某个成员兼职），为该项目制定配置管理计划、创建和维护配置库、适时出具配置管理各种报告如基线建立控制报告、配置项变更控制报告、版本发布通知等。适用范围本配置管理规范适用于公司产品/项目从可研论证、立项、需求分析、设计编码、测试验证、版本发布、运行维护直至结束的全生命周期过程中文档、代码、构建、发布等的管理，暂不适用于其他资产如测试数据、美工工作产品、售前资料、非产品/项目培训资料、多媒体资料、部门管理文档、公司信息化数据等的管理。阅读对象配置管理员、产品/项目经理、开发人员、测试人员、维护人员、系统架构师配置管理计划配置管理的计划过程主要由明确配置管理软硬件资源、识别配置项、规划配置库目录结构、确定权限配置、制定基线计划、确定项目分支合并策略、确定代码集成策略、项目构建策略、版本发布策略以及制定《配置管理计划》等一系列活动组成，每个活动计划的最终成果体现在《配置管理计划》中。通过配置管理计划，将项目开发、测试、实施、发版各阶段涉及的配置管理工作明确下来，保证项目生命周期过程中产生的配置项被识别、记录、跟踪、管理。配置管理计划流程图图1配置管理计划流程图配置管理计划流程说明由项目经理和配置管理员共同确定本项目配置管理的软硬件资源，如下：确定CCB成员名单，根据项目不同规模和重要程度，CCB成员建议可以包括分管副总、研发项目总监、部门经理、项目经理以及其他受变更影响的人员代表（必要时可包括测试人员等）。确定本项目配置管理的软件工具和硬件设备，包括配置管理服务器、构建服务器、软件开发工具、配置管理工具、构建工具等的具体名称和版本以及需遵循的开发、编码规范（确定配置管理的软硬件资源可参考本规范以及《配置管理工作指南》相关章节内容）。依据《项目管理计划》，由配置管理员与项目经理共同识别主要配置项、配置库目录及权限分配、基线计划、分支合并策略等（具体内容可参考本规范相关章节内容），并体现在《配置管理计划》中。配置管理员与项目经理共同确定项目的变更策略、代码集成策略、项目构建策略以及版本发布策略（具体内容可参考本规范相关章节内容），并体现在《配置管理计划》中。配置管理员完成《配置管理计划》，以便于项目有计划的开展配置管理工作（配置管理计划相关模板详见公司主页规章制度下公布的最新模板）。《配置管理计划》评审活动由配置管理员发起，评审组由CCB成员组成（可同时发送项目组人员）。CCB对已制定的《配置管理计划》进行评审，以保证《配置管理计划》的完整、正确、可行；如审批未通过，配置管理员需按照评审意见重新修订《配置管理计划》，直至CCB评审通过。配置管理员将审批通过的《配置管理计划》纳入配置库进行管理，并发布给项目组相关人员。配置管理软硬件资源确定配置管理服务器公司所有项目的配置库必须在公司指定的配置管理服务器上，包括研发项目和实施项目。公司所有项目使用配置管理服务器必须与运营监管中心沟通确认。公司级配置管理计划模板中应明确列示配置管理服务器的基本信息，如配置管理服务器名称、操作系统、IP地址、内存容量、硬盘容量、管理员等。

公司目前允许使用的配置管理服务器如下表所示：服务器名访问地址主要用途配置库规划备注jqcmr32289版全称Subversion，研发项目，文档和代码vss\\ad01\开发辅助\VSS版本管理6.0C/无全称VisualSourceSafe，研发项目，文档和代码starteam\\ad01\开发辅助\StarTeamEnterprise2008配置管理、需求管理、任务管理等2008/2006研发项目，文档和代码项目管理平台Web访问基线建立流程图基线计划时间点到达或需要建立基线时，由项目经理提出基线建立申请。CCB对基线建立申请进行评审和批准，保证组成基线的配置项是完整的、正确的、一致的。配置管理员与项目经理沟通，参照《基线建立前检查Checklist》以及基线计划对提交的配置项审查其完整性、正确性、一致性，并完成《基线建立前检查Checklist》、《基线建立控制报告》，填写基线名称、版本、标识以及当前基线包含的所有主要配置项等信息（如果前期已建立基线，当前基线的配置项需要包含上一次基线的配置项）。配置管理员审查配置项时需注意检查主要配置项的评审记录、评审结论、变更影响等。比如需求规格说明书评审记录、功能评审记录、变更所影响的配置项是否正确变更并入库等等，如若评审结论不通过或影响的配置项没有变更或入库，则该基线不能建立并必须与项目经理沟通。CCB评审并批准基线建立申请后，由配置管理员执行建立基线的操作，基线命名要按照《配置管理计划》中规定的命名。配置管理员将《基线建立控制报告》发布给CCB、项目组成员并纳入配置库。基线命名规范计划性基线：“项目编号-阶段标识-YYYYMMDD”；事件性基线：“项目编号-阶段标识-事件英文缩写-YYYYMMDD”。基线名称标识符基线所包含的主要配置项建立时间产品定义基线项目编号-REQBaseline-YYYYMMDD需求说明书需求规格说明书项目管理计划品质保证计划配置管理计划测试计划风险/重大问题跟踪表各种报告和跟踪表产品设计与开发基线项目编号-DES+CODEBaseline-YYYYMMDD概要技术方案说明书总体设计说明书模块设计说明书数据库设计说明书测试用例源代码产品稳定基线项目编号-RELEBaseline-YYYYMMDD测试报告用户手册培训资料技术白皮书发布版本产品结项基线项目编号-ENDBaseline-YYYYMMDD项目总结报告提交工作产品清单分支合并管理版本控制系统的一个特性是能够把各种修改分离出来放在一个单独的开发线上，这条线被称为分支。分支经常被用来试验新的特性，而不会干扰主开发线，当新的特性足够稳定之后，开发分支就可合并到主干里。分支管理是软件版本控制的重要组成部分，运用分支使得并行开发的系统、同步更改多个并行版本的错误等成为可能。分支可用来维护独立的开发支线（通常只对代码做分支），使用分支进行项目组的开发可以提高项目组的开发速度，并减少对主干文件的误修改操作，否则主干版本可能会变得十分混乱，维护难度大大加大。尽管SVN没有做强制要求，但SVN版本目录建议创建Trunk、Branches、Tags三个目录。其中Branches是分支目录，存放并行开发的项目文档和代码；Tags是标签目录，存放所定义基线的项目文档和代码。分支建立分支建立时机建立分支是为了支持特定需求、完成新功能开发或解决某些重大bug，在项目立项、新增功能需求、解决某些重大bug等情况下允许建立分支。由配置管理员协助开发人员在配置库相应目录下建立分支。应当尽量避免建立多个层次的分支，即基于分支再创建分支。分支建立模式一般情况下，围绕代码进行分支管理的模式主要有两种：主干作为新功能开发，分支用作稳定版的发布；分支用作新功能开发，主干作为稳定版的发布。建立分支时，配置管理员需明确以下几点：分支目录结构；人员访问权限；此分支是否需提交相关项目文档。分支合并分支合并类型分支合并是将某个分支中修改的代码合并到另一个分支中。常见的分支合并有以下几种：分支合并到分支；分支合并到主干；主干合并到分支。分支合并前应临时去除相关分支所有人员的写权限，只保留被合并分支上合并人员的写权限。应当尽量避免一个分支合并多次。当一个分支完成特定任务后，应及时合并。合并完成后分支应设置为只读，不再允许对该分支进行修改。版本库发布模式新功能开发在主干上进行当新功能开发在主干上进行、临近发布阶段时，从主干建立分支，在分支上修订集成测试、系统测试所发现的BUG，在分支上进行发版；主干继续进行新功能开发。版本发布完成后，将分支合并到主干，分支设置为只读。新功能开发在分支上进行当新功能开发在分支上进行、开发结束、功能测试通过时，将分支合并到主干修订集成测试、系统测试所发现的BUG，在主干上进行发版；同时将分支设置为只读。此模式下的开发周期较灵活，各功能模块自主定义开发周期，分支上的开发临近末期则将分支合并至主干，越先合并的分支，在合并过程中解决的冲突越小。代码集成管理代码集成目标是使集成和集成测试过程处于受控状态。频繁的集成能够帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题的代价将会很大、并且很有可能导致项目延期或者失败。当产品/项目进入编码阶段后，不同开发人员在各自的个人工作空间下开始编码。为保证代码集成目标的实现、避免不同开发人员提交到代码库的代码产生冲突，必须明确约定从个人工作空间到代码库的代码集成策略：禁止使用有商业版权、未经授权的工具、软件或插件。同一个产品或项目的开发应统一个人工作空间，一般包括以下内容：操作系统、配置管理工具客户端或插件版本、开发工具及版本、数据库及版本、中间件及版本以及其他环境要求等。个人工作空间要求应由项目经理与配置管理员共同确定并体现在项目管理计划和配置管理计划中。个人工作空间目录应该尽可能的与服务器目录结构保持一致，禁止自行将多个文档目录或工程代码合并到一个目录或工程之中进行工作。工作时如需锁定或Checkout文件，在修改完成后应该马上解锁文件，禁止长期锁定或当产品/项目处于前期开发阶段时，开发人员根据项目组要求应该每天至少向配置库中提交一次代码、每天至少从配置库更新一次相关的代码到个人工作空间。开发人员向配置库提交代码前必须先在个人工作空间完成编译、构建、自测，保证代码可编译通过、没有错误，从而确保配置库的变更不会导致代码集成失败。当产品/项目处于后期版本稳定阶段时，对于产品版本稳定性要求较大的开发团队，为避免由于代码集成过程缺乏控制导致的代码混乱问题，必须制定严密的代码集成策略。跟产品/项目无关的文件一律不允许检入配置库，如编译产生的文件、缓存缩略图的文件Thumbs.db、从VSS中检出的配置文件vssver.scc等。源代码必须及时提交到配置库，不允许长时间lock或checkout代码而不执行unlock或checkin。lock或checkout到unlock或checkin的时间间隔不得超过2个星期。对于开发人员，修复失败的构建是优先级最高的事情。代码修改过程中，为防止代码被别人修改而引发冲突，可以考虑锁定机制。正式版本发布、升级或发布临时版本时，必须对源代码打基线。配置管理员与项目经理沟通确定代码集成策略后，将具体的流程在《配置管理计划》中做出约定，主要内容如下：代码集成策略内容包括：代码模块集成顺序、谁负责代码集成过程、代码集成前的一致性检查、代码提交要求等，参见《配置管理工作指南》代码集成部分的内容代码集成策略影响整个系统各个代码模块的编译顺序和目标代码的连接（受一些构建参数的影响），项目经理要根据代码集成策略确定构建脚本和相关构建参数，确保构建脚本及其配置参数符合代码集成策略要求，配置管理员要注意督促。源代码基线建立或第一次版本发布后，所有源代码的修改、提交必须填写修改注释（COMMENTS）或更新说明。产品/项目稳定后期，可设立专门的代码集成人员，开发人员将修改文件及更新说明（明确注明修改文件、修改原因等信息）发送给代码集成人员，由代码集成人员向代码库提交代码，并维护代码库更新说明列表。发布管理正式版本发布正式版本是指经测试后、可发布给客户正式使用的版本，包括程序包、更新脚本、用户文档等。对外发布的正式版本包中不得包含任何未经授权的产品或半产品，比如不得使用未经授权的商业软件工具构建程序包、创建文档、制作图片等，不得使用第三方获取的未经授权的图片等。各产品/项目正式发布的版本包必须存放在久其产品库中。久其产品库按照产品线/项目进行目录规划。久其产品库由组织级配置管理员在对应的目录上针对产品线或项目配置管理员开放读写权限，针对测试、实施、服务相关部门经理/负责人、助理开放读权限。如需访问久其产品库某产品，需经主管领导、分管副总审批后由组织级配置管理员设定；没有经过申请、审批的人员不设置任何权限。正式产品的发布必须提交发版说明或者更新说明。正式版本的命名一般遵循“产品/项目编号+正式版本号+内部版本号+八位数日期+随机号”。正式版本的发布由配置管理员采用电子邮件方式统一执行，发送范围视版本内容可以是全公司或部分人员。久其产品库要做到每年做一次完全备份，并且刻盘、永久归档。测试版本发布测试版本是指构建完成后仅用于内部测试验证、临时满足用户演示或售前交流等需要临时发布的版本，是非正式的产品版本，使用对象包括内部测试人员或外部客户（协助测试）。测试版本不能保证产品整体功能的正确性，是未经过功能测试、集成测试或性能测试的版本，不得用于正式生产环境。各产品/项目构建工作建议在久其统一的构建服务器、通用构建管理平台上执行。各产品/项目必须有一个唯一的标识，用于区分不同产品/项目的构建。测试版本的构建必须由配置管理员或指定的构建人员执行。构建产生的测试版本存放在构建服务器上，有相应授权的人员可以登录构建平台下载。测试版本的命名一般遵循“yyyy-mm-dd（hh-mm-ss）”的规则。一般情况下，测试版本保存半年之后可以删除、无须永久备份。临时版本发布临时版本是指为了满足用户少量个性化需求或修复部分小缺陷而发布的版本，这种版本一般可以不经过集成测试，但应经功能测试方可发布。为了做好版本管理、一般情况下应尽可能减少临时版本的发布。临时发布的版本包中同样不得包含任何未经授权的产品或半产品。因临时版本需要用于正式生产环境，所以临时版本同样必须存放在久其产品库中。临时版本存储的目录结构划分、权限设置等与产品/项目的正式版本一致。临时版本的命名一般遵循“产品/项目编号+正式版本号+内部版本号+八位数日期+随机号+用户方或者申请者姓名”。临时版本可视情况考虑永久归档或者在保存一年之后删除。变更管理变更控制为了确保重大变更经过评审、确认，保证变更所引起的其他配置项能够得到及时、一致的更新并及时入库，保证所有事件性变更有记录，我们需要加强变更控制。对于严重影响项目进度和成本的需求、设计、人员、计划等的变更必须经过申请、评审、审批方可执行，不允许擅自修改。修改处于“草稿”状态的配置项不算是“变更”，当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据申请执行变更的规则执行。发生变更时，项目经理必须及时通知配置管理员，延缓时间不能超过3天。配置管理员要跟踪变更执行进度，及时接收、入库变更产生或修改的配置项。对配置项的变更操作应以评审定稿为准、不仅仅以基线为准。即：配置项评审定稿入库后、未建立基线前如对该配置项进行修改，需按照变更流程执行。配置管理通过建立一个有序的变更控制过程要确保以下几点：变更影响分析：对每个配置项的变更所造成的影响（如：技术影响、成本影响、进度影响等）需进行分析。变更审批：对任何基线化的配置项的更改必须经过审批、并保留审批记录。变更执行与入库：得到审批的变更及其影响必须得以实施并得到进一步审批方可入库。变更流程图1变更控制流程图申请变更变更申请人向CCB提交变更申请（填写《配置项变更控制报告》的相关内容），需要重点说明“变更内容”和“变更原因”及其“该配置项变更对项目造成的影响”。典型的变更请求有：项目目标发生改变、增加或减少重大功能需求、技术攻关出现难题、资源调整等。评审变更申请CCB评审该申请，重点分析此变更对项目造成的影响。安排变更