03配置管理工作指南.docx

《03配置管理工作指南.docx》由会员分享，可在线阅读，更多相关《03配置管理工作指南.docx（37页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、文件编码文件密级最新发布日期当前版本配置管理工作指南郑重声明：XX软件股份有限公司版权所有。本文档中任何部分未经XX软件股份有限公司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播。1 .配置管理员参照公司配置项参考列表&配置库参考目录.xls制定本项目配置项列表。2 .配置管理员与项目经理和项目主要成员确认项目配置项列表。3 .配置管理员确认工作成果的内容，确定是否可以与现有配置项合并或者作为 新的配置项。4 .配置管理员与项目经理确认，识别新的配置项。5 .配置管理员识别出新配置项为基线类配置项或非基线类配置项。 基线配置项参考列表项目经理制定项目里程碑计划时，需要

2、明确各里程碑产生的配置项。配置管理员 根据里程碑计划制定基线计划。基线配置项往往需要严格控制，并会对项目基线建立 产生影响。基线配置项确定标准如下：1 .重要的提交物。2 .配置项易发生变化，需要进行版本控制。3 .属于管理控制重点的配置项，如源代码。下表给出了基线配置项参考列表， 各项目可以根据实际情况确定相应的基线配置项。类型配置项配置项分类备注项目管理项目管理计划基线类配置项项目进度计划基线类配置项项目周报基线类配置项项目里程碑报告基线类配置项评审报告/会议纪要基线类配置项风险/重大问题跟踪表基线类配置项配置管理计划基线类配置项基线建立控制报告基线类配置项基线建立前检查Check I i

3、 st基线类配置项品质保证计划基线类配置项项目路线图基线类配置项项目总结报告基线类配置项遗留问题跟踪表基线类配置项提交工作产品清单基线类配置项需求定义概要技术方案说明书基线类配置项需求说明书基线类配置项需求规格说明书基线类配置项设计开发技术研究报告基线类配置项设计说明书基线类配置项数据库设计说明书基线类配置项系统稳定测试计划基线类配置项测试用例基线类配置项测试总结基线类配置项功能/性能测试报告基线类配置项发版说明基线类配置项产品化包装用户手册基线类配置项培训资料基线类配置项系统安装配置说明书基线类配置项产品介绍PPT基线类配置项类型配置项配置项分类备注产品解决方案基线类配置项产品实施指南基线类

4、配置项产品报价策略基线类配置项技术白皮书基线类配置项非基线配置项参考列表项目非基线配置项区别于基线配置项，是指没有纳入基线计划的配置项。非基线 配置项一般不影响项目进展，不需要在基线建立时进行严格控制。下表给出了非基线 配置项参考列表，各项目可以根据项目实际情况确定相应的非基线配置项。类型配置项配置项分类备注项目管理项目立项报告、项目启动会PPT等非基线类配置项配置管理相关文档非基线类配置项品质保证相关文档非基线类配置项项目汇报相关文档非基线类配置项各种管理跟踪表非基线类配置项会议评审相关文档非基线类配置项培训相关文档非基线类配置项项目结项总结PPT等非基线类配置项电子邮件非基线类配置项 非基

5、线类配置项需求定义调研准备非基线类配置项调研资料非基线类配置项 非基线类配置项设计开发其他设计类参考资料、文档非基线类配置项源代码源代码、单元测试源代码非基线类配置项可执行文件非基线类配置项系统稳定缺陷跟踪相关文档非基线类配置项维护记录相关文档非基线类配置项产品化包装用户培训资料、帮助等非基线类配置项系统维护系统维护相关文档非基线类配置项非基线类配置项在项目进展过程中，配置管理员需定期跟踪并维护项目配置项列表（体现在配 置管理计划中），需注意以下各项工作：1 .配置管理员每周阅读项目周报、每月阅读项目月报，关注周报、月报中列出 的项目工作成果。2 .配置管理员对照配置管理计划的配置项计划，识别

6、出未纳入计划的配置 项清单。3 .配置管理员就新配置项清单与项目经理和项目主要成员确认。4 .将新识别的配置项清单更新到配置管理计划中（将新的基线配置项列入基线配置项列表，将新的非基线配置项列入非基线配置项列表）。5 .将新经过评审的基线配置项和正确的非基线配置项纳入配置库。6 .基线配置项入库后如需修改请遵循变更流程。4. 6配置项标识标识的本质就是区分，在众多的配置项中合理、科学的命名是最好的区分方法。 所有配置项都应按照相关规定统一编号，按照相应的模板生成。配置项标识需要遵循以下原则：1 .唯一性2 .可追溯性3 .与同类配置项不同的信息，应纳入标识：这是为了便于区分、查找4 .同类配置

7、项的标识方法统一5 .容易记忆配置项标识需要遵循以下要求：1 .所有纳入管理的配置项必须按照公司文档编码规范进行命名（不包含配置库 草稿目录下的草稿文件），配置项的命名要遵守“项目编号+项目名称+文档产品+可选 字段（主题/版本/人名/日期）”的命名原则，同时命名要求需体现在配置管理计划 中，详细内容请参见文件编码及命名规范。2 .基线配置项必须符合文档规范，需使用公司最新发布的文档模板（若客户方 有特殊要求，需提前说明），各类最新项目文档模板可直接进入公司portal主页-规 章制度下获取。3 .新建或修改基线配置项的文档内容时，必须同时填写相应的变更履历。4 .7配置项入库管理1 .配置项

8、的存放目录应参考组织级配置库目录，由配置管理员在配置库中建立。2 .配置项必须按照配置管理计划中配置库目录结构划分的要求纳入到正确 的目录中。3 .配置项需及时、正确入库，配置管理员或项目经理/工作产品负责人根据项目 周报中的工作成果每周检查、并督促入库。4 .配置项的首次入库时间不以基线建立时间为准，应以评审、定稿时间为准， 最多不得超过两周时间、并且必须在基线建立前；对配置项的修改或变更在评审、定 稿后同样应及时入库。5 .配置项的正式发布必须在配置库的正式目录中，不得存放于工作草稿等目录中。6 .产品/项目进行过程中产生的各种需求、设计、测试、实施、评审、培训等以 及项目管理的最终文档、

9、中间文档以及附带的图稿原件如时序图等，临时产生的各种 用于交流、讨论、备忘的记录、材料等，均应该完整、及时纳入配置库，由项目经理 负责检查落实，配置管理员定期督促。7 .对于主要配置项，如需求规格说明书、项目管理计划等的变更，需要走“申 请-CCB审批-CM检出-变更-CCB审批-检入的变更流程。8 .8配置库目录结构规划1 .公司所有项目配置库目录可参照组织级配置项参考列表&配置库参考目录 创建。2 .整个配置库目录需要按配置管理计划中的配置库目录结构要求创建。一级目录二级目录三级目录内容说明备注项目管理项目立项项目立项申请、项目启动会PPT（可选）、项目基本信息表等项目计划项目管理计划、项

10、目进度计划项目汇报项目周报项目周报其他报告项目里程碑报告、阶段性汇报PPT （可选）等管理跟踪风险/重大问题跟踪表、项目备忘 大事记（可选）配置管理管理策略配置管理计划基线建立基线建立控制报告、基线建立前检查 Check 1 i st变更管理配置项变更控制报告（可选）、变 更控制重点监控配置项清单（可 选）、重点控制项变更检查表、产 品发布更新说明（产品型项目）品质保证管理策略品质保证计划检查记录项目路线图、品质保证检查记录 （工作流程审计、工作产品检查、 工程规范检查）会议评审会议纪要、评审报告、会议签到 表（可选）、评审数据汇总表（可 选）等可按事件等建立子目录培训培训通知（可选）、培训材

11、料（可 选）、培训签到表（可选）、培训 评估报告（可选）可按事件等建立子目录电子邮件与客户往来沟通确认的工作邮件 存档、项目组内部沟通确认的工 作邮件存档可按主题等建议子目录项目结项项目总结报告、项目结项总结会PPT （可选）、提交工作产品清单、一级目录二级目录三级目录内容说明备注遗留问题跟踪表其它需求定义需求调研调研计划、调研提纲、调研报告& 访谈记录需求草稿从客户或其他途径获得的资料、 需求草稿需求确认产品可研论证报告（产品型）、产 品/项目愿景说明书、项目范围说 明书（普通）、需求说明书、需求 规格说明书、需求跟踪矩阵（可 选）设计开发设计草稿设计草稿文档设计确认概要技术方案说明书、总体

12、/模块 设计说明书、数据库设计说明书、 模块依赖关系表、技术研究报告 （可选）系统稳定管理策略测试计划测试用例测试用例、测试点（可选）、性能 测试方案（可选）测试报告阶段测试总结（可选）、系统测试 报告、功能/性能测试报告（可 选）、用户验收测试报告（可选）上线及试运行实施日志（普通）、实施配置报告 （普通）、问题跟踪一览表、项目 分工界面（可选）、项目验收备忘 录（普通）、用户脸收证书（普通）可选版本发布发版申请、发版计划、正式版产 品发布基线清单、产品发布更新 说明产品化包用户文档用户手册、帮助、系统安装配置一级目录二级目录三级目录内容说明备注装说明书、用户培训资料等产品包装产品技术白皮书

13、、产品解决方案、 产品宣传彩页、产品介绍PPT、 产品实施方案、产品咨询方案、 产品报价策略系统维护年度1维护事件1可选年度2源代码开发源代码4.9 制定基线计划基线标识1.1 划性基线：“项目编号-阶段标识-YYYYMMDD”。1.2 件性基线：“项目编号-阶段标识-事件英文缩写-YYYYMMDD”。4.11 制定基线计划基线分为计划性基线和事件性基线，计划性基线在配置管理计划中体现，事件性基线由相关人员提出申请建立，不在配置管理计划中体现。表4基线参考列表注：基线计划时间出现2周以上偏差或主要配置项变更时，需要走变更流程。基线名称/标识符包含的主要配置项建立时间产品定义基线：项目编号-RE

14、QBasel ine-YYYYMMDD需求说明书需求规格说明书 项目管理计划 品质保证计划 配置管理计划测试计划 风险/重大问题跟踪表 各种报告和跟踪表产品设计与开发基线：项目编号-DES+CODEBasel ine- YYYYMMDD概要技术方案说明书 总体/模块设计说明书 数据库设计说明书 测试用例 源代码产品发版/稳定基线：项目编号-RELEBasel ine- YYYYMMDD功能/性能测试报告用户手册培训资料技术白皮书发布版本项目结项基线：项目编号-ENDBasel ine- YYYYMMDD项目总结报告 提交工作产品清单 遗留问题跟踪表4.12 明确权限管理用户管理用户角色组主要有

15、：配置管理员、CCB、项目经理、需求人员、设计人员、开发 人员、测试人员、实施人员、品质保证员等。各用户角色定义详见配置管理规范 9. 1章节，对项目配置库中用户角色的管理，配置管理员需注意以下几点：1 .项目配置库用户需要根据项目情况相应调整。2 . 一般情况下，项目配置库用户如需调整增加或删除，由项目经理提交邮件申 请，配置管理员收到邮件申请后，执行相应操作。特殊情况下，可由项目组成员提交变更履历版本日期变更位置变更理由/变更内容变更人备注1.0新建1.12. 1.1.变 更履历根据研发项目管理流程问题巡检检查出的 问题进行更新：1、更新基线配置项参考列表2、增加变更履历2.0全文根据新版

16、配置管理规范和目前实际工 作进行调整，调整整体框架、将冗余的内 容进行删减、优化。邮件申请，抄送项目经理及相关人员。3 .配置管理员在收到邮件申请后，执行相应操作，并将用户分配到不同组里。4 .配置管理员增加或删除用户后，需要邮件通知项目经理及相关人员。邮件通 知中需要附加配置库连接地址及简要操作说明。5 . 14制定访问控制策略在建立配置库以前，项目经理需要给配置管理员提供明确的项目组各成员角色的 访问控制策略，配置管理员结合配置管理工具，衡量访问控制策略的合理性，与项目 经理确认后制定访问控制策略，并记录到配置管理计划中。6 .15配置库资源与操作定义不同角色用户对配置库操作主要有：1 .

17、项目配置库创建、维护、删除。2 .项目成员及组的设置、维护。3 .基线建立、维护。4 .分支/合并。5 .对文档、目录的读写访问。6 .对源代码文件、源代码目录的读写访问等。由于不同配置管理工具对配置库 操作的控制粒度不同，在具体设置配置库操作权限时，需要结合配置管理工具的特性 进行设置。表5配置库操作列表序号资源SVN操作定义1配置库创建文件夹：Create FoIder删除文件夹：Delete分支/建基线（打标签）:Branch/tag合并：Merge访问控制：设置用户组的权限2项目文件夹读（Read）: Checkout Export、update写（Write）: Add comm i

18、 t Get/Release Lock Rename de IeteCopy to3项目文件读（Read）: Checkout Export、update写（Write）: Add comm i t Get/Release Lock Rename delete、Copy to4代码目录读（Read）: Checkout、Export、update写（Write）: Add、comm i t Get/Release Lock Rename de IeteCopy to7 .16角色划分策略配置库角色主要有：配置管理员、项目经理、开发人员、测试人员、实施人员, 不同角色的职责不同。配置库授权控制参

19、考列表如下：表6角色划分参考列表4.17配置库操作权限参考序号资源配置库操作配置管理员项目经理需求/设计/开发人员测试人员CCB/实施/品 质保证人员1配置库配置库创建、维护、 删除完全无无无无用户及角色组的设置、维护、授权控制完全无无无无基线建立完全无无无无分支/合并完全无无无无2文件/文件夹读写访问完全读写读写读写只读3源代码读写访问完全读写读写无无4产品库读写访问完全只读只读读写只读表7配置库操作权限参考列表编号一级目录权限说明1项目管理项目经理、配置管理员可写，CCB、测试人员、QA人员 可读2需求定义项目经理、配置管理员、开发人员可写，CCB、测试人 员、QA人员可读3设计开发项目经

20、理、配置管理员、开发人员可写，CCB、测试人 员、QA人员可读4系统稳定项目经理、配置管理员、测试人员可写，CCB、开发人 员、QA人员可读5上线及试运 行项目经理、配置管理员可写，CCB、开发人员、测试人 员、QA人员可读6产品化包装项目经理、配置管理员可写，CCB、开发人员、测试人 员、QA人员可读7系统维护项目经理、配置管理员可写，CCB、开发人员、测试人 员、QA人员可读8源代码项目经理、配置管理员、开发人员可写，CCB可读，测 试人员、QA人员无权限4.18明确分支版本策略4.19分支合并类型在软件开发实践中，常常出现一些令人沮丧的事，如软件紧急更改提交集成失败、 发布错误版本、修复

21、过的缺陷又莫名其妙地出现等等。主要的原因在于在实际开发中 没有应用软件配置管理或应用软件配置管理不当，选择并应用正确的分支模型，对避 免开发过程的混乱尤其重要。常见的分支合并类型有以下几种： 分支合并到分支；分支合并到主干； 主干合并到分支。1 .项目组根据项目情况不同，需事先约定所选择的合并类型，以便为后期可能 的分支合并做好准备，配置管理员将所选择的类型记录到配置管理计划中。2 .分支合并前应临时去除相关分支所有人员的写权限，只保留被合并分支上合并人员的读权限。3 .应当尽量避免一个分支合并多次。当一个分支完成特定任务后，应及时合并。4 .合并完成后分支应设置为只读，不再允许对该分支进行修

22、改。5 . 20明确分支版本策略选择正确的分支策略使版本正确发布、重构以前的版本或者重新回到以前的版本 等工作更加容易。采用分支模型使软件开发过程更加便捷、软件开发更加高效、软件 质量得到提高，并且可以减少软件开发中的错误和提高软件开发团队的整体效率。选 择适当的分支模型，应从以下几个方面考虑：1 .支持连续不间断的集成，从而保持新开发过程的稳定的基准；.提交应急版本（只包括所有必要的修复）进行测试和交付用户；2 .包含有所有必要的修复而无其它更改的测试版本发布；.使应急发布对新开发过程的影响最小化；3 .根据项目需要，回退到以前的产品状态；.支持多个共存版本，如不同平台或不同用户的备选版本。

23、关于代码管理的分支和发布策略，主要有两种模式：1 .新功能开发在分支上进行，主干用于稳定版的发布。2 .新功能开发在主干上进行，分支用于稳定版的发布。3 .21主干稳定当新功能开发在分支上进行、开发结束、功能测试通过时，将分支合并到主干修 订集成测试、系统测试所发现的BUG,在主干上进行发版；同时将分支设置为只读。 主干稳定策略与分支稳定策略刚好相反，主干上永远是稳定版本，可以随时发布。缺 陷修改和新功能的开发都在分支上进行，而且每个缺陷修改和新功能都有不同的开发 分支，是完全分离的，在分支上测试通过后才合并到主干，在主干上的每一次发布都 需要用标签标识。优点：,1 .开发周期较灵活，各功能模

24、块自主定义开发周期，每个分支的生命周期比较 短，唯一长期存在的就是主干，这样每次合并的风险比较小。2 .每次发布的内容调整起来比较容易。3 .如果某个新功能或缺陷修改在发布之前无法完成，就不会合并到主干，也不 会影响其他变更的发布。缺点：1 .如果某个开发分支因为功能比较复杂，或其他原因长期没有合并到主干，则最后合并的时候很可能会出现冲突。为避免合并时产生冲突需要注意以下问题:2 .如果有的分支确实因为特殊的需要必须长期存在，那就必须定期把主干的更新往这个分支上合并。3 .如果发布周期很长，各个发布分支之间还要定期的从前向后合并。4 .测试在发布分支上进行，而发布在主干上进行，这就引入了合并出

25、错的风险, 而主干上的程序是没有经过测试的。5 . 22分支稳定当新功能开发在主干上进行、临近发布阶段时，从主干建立分支，在分支上修订 集成测试、系统测试所发现的BUG,在分支上进行发版；主干继续进行新功能开发。 版本发布完成后，将分支合并到主干，分支设置为只读。采用分支稳定策略情况下， 主分支中永远是最新的功能，当新功能开发到达某个里程碑后发布，从主干分支用于 该版本的缺陷修改及现有功能的完善。当稳定分支上的修改积累到一定程度就会进行 一欠发布。优点：1 .这种发布方法非常适用于产品线的发布管理，以前的版本仍需要继续维护， 而新功能也不断地在增加。2 .对于已经发布的产品，只有维护的补丁发布

26、。而新发布的产品不仅包括了所 有的bug修改，还包括了新功能。缺点：.1 .只能增加下一个发布里面计划集成进去的新特性，同时必须对主干上新功能 的增加进行控制，否则新版本的发布将出现严重延期。2 .如果主干上的某个新功能，测试不通过，达不到里程碑的要求，新版本的发 布也会出现延期。3 .缺陷修改必须在各个分支之间合并，各个长期存在的分支之间必须要周期性 的进行合并，否则很容易引发合并冲突。因此，采用这种分支策略可能碰到的最大问 题就是某个分支上的bug修改内容往其它分支merge的时候出现的冲突。而且一旦发 现一个bug,调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。4 .

27、 23基于SVN的分支建立及合并方法表8 SVN分支建立及合并方法参考列表操作SVN分支/合并操作说明新建分 支1Branch/tag （分支标记）方法一：当新建分支时，在工作副本右键点击 要开分支的文件目录，选择“Branch/tag”功 能创建分支。24分支建立步骤2Copy to （复制到）方法二：使用TSVN客户端浏览器，选择 Copy to”功能将需要建立分支的文件夹“复制”到 branches目录下。合并分 支Merge （合并）选择所需要使用的合并类型进行合并。（合并步 骤参考本指南章节）。1 .由于SVN提供可以创建从主干向分支、分支向主干、分支向分支三种类型的 分支，首选需明

28、确开分支的起始位置及结束位置。2 .新建分支的操作方法有两种，如上表所属（表8）,使用第一种方法需在工作 副本中进行，第二种方法通过SVN浏览器完成。3 .选择分支文件所存放的目录路径，一般情况下，分支文件存放在branches目 录下，以上信息明确后即可开始创建分支。4 .分支创建完成后，开发人员再次确定分支目录结构是否有需调整。5 .分支创建完成后，配置管理员需明确配置库分支目录文件的权限分配策略， 明确相关人员角色并开放相关权限。4. 25分支合并步骤分支合并有三种常见类型：1 .单分支合并.多分支合并，且起始主干版本号相同2 .多分支合并，且起始主干版本号不同使用SVN进行合并操作时，

29、提供了三种方法，区别是：操作SVN合并方法特点说明合并分支1合并一个版本范围可任意选择分支的版本，主干不能选择版本，只能使 用最新版本。2复兴分支无乱是主干和分支都不能任意选择版本，只能使用最 新版本。3合并两个不同的树无乱是主干和分支都可以任意选择版本，包括最新版 本。单分支合并操作方法比较简单，同多分支合并操作步骤一中相同，参见多分支合并的步骤。多分支合并，且起始主干版本号相同（如下图）TrunkTrunkBranchBranch合并需两步操作，并且操作在主干T的工作副本内执行： 主干T合并分支A输入起始URL和版本（如：主干T的URL、版本100）；输入结束的URL和版本（如：分支A的U

30、RL、版本110）; 合并分支A后再继续合并分支B输入起始URL和版本（如：主干T的URL、版本100）;输入结束的URL和版本 （如：分支B的URL、版本115）; 多分支合并，且起始主干版本号不同（如下图）合并需三步操作：分支A更新主干版本至最新版本，在分支A的工作副本内执行输入起始URL和版本（如：主干T的URL、版本100）;输入结束的URL和版本（如：主干T的URL、版本102）;合并分支A输入起始URL和版本（如：主干T的URL、版本102）；输入结束的URL和版本 （如：分支A的URL、版本121）；合并分支A后再继续合并分支B输入起始URL和版本（如：主干T的URL、版本102

31、）；输入结束的URL和版本 （如：分支B的URL、版本120）；合并结束后，需将合并后的结果提交（commit）至服务器中。5个人工作空间管理1 .为保证项目团队成员工作在统一的开发平台上，避免因个人工作空间不一致 导致程序错误，配置管理员需要在配置管理计划中约定项目团队的个人工作空间。2 .配置管理员可以根据需要定期抽查项目成员的个人工作空间。5.1建立个人工作空间1 .项目经理提醒开发人员根据个人工作空间要求准备开发环境。2 .开发人员根据配置管理计划中规定的个人工作空间要求准备开发环境。3 .2个人工作空间要求开发人员在正常情况下的操作步骤应该是每天更新个人工作空间，获得最新版本 的代码

32、，在此基础上再开始开发工作，个人工作空间要求如下：1 .禁止使用有商业版权、未经授权的工具、软件或插件。2 .个人工作空间目录应该尽可能的与服务器目录结构保持一致，禁止自行将多 个文档目录或工程代码合并到一个目录或工程之中进行工作。3 .工作时如需锁定或Check out文件，在修改完成后应该马上解锁文件，禁止 长期锁定或4 .当产品/项目处于前期开发阶段时，开发人员根据项目组要求应该每天至少向 配置库中提交一次代码、每天至少从配置库更新一次相关的代码到个人工作空间。5 .开发人员向配置库提交代码前必须先在个人工作空间完成编译、构建、自测， 保证代码可编译通过、没有错误，从而确保配置库的变更不

33、会导致代码集成失败。6 .跟产品/项目无关的文件一律不允许检入配置库，如编译产生的文件、缓存缩 略图的文件Thumbs, db、从VSS中检出的配置文件vssver. see等。7 .源代码必须及时提交到配置库，不允许长时间lock或check out代码而不执 行unIock或check ino Iock或check out到unIock或check in的时间间隔不得超 过2个星期。8 .对于开发人员，修复失败的构建是优先级最高的事情。9 .代码修改过程中，为防止代码被别人修改而引发冲突，可以考虑锁定机制。10 3检查个人工作空间1 .配置管理员可以制定个人工作空间检查计划，抽查项目组成员

34、的个人工作空间。2 .配置管理员检查可以采取定期抽查的方式开展。3 .检查个人工作空间的事项：4 ）目录结构是否一致、5 ）引用的第三方类库/组件是否符合统一的要求、6 ）是否有超出权限范围的代码，等等7 基线管理8 .1基线建立要求配置管理员需要根据配置管理计划中制定的基线计划，跟踪项目进展，建立 基线。具体内容如下：1 .根据基线计划时间点，在到达里程碑时间点时，配置管理员提醒项目经理需 要提交的主要配置项。2 .配置管理员与项目经理沟通，参照基线建立前检查Checklist以及基线计 划对提交的配置项审查其完整性、正确性、一致性，并完成基线建立前检查 Checklist、基线建立控制报告

35、，填写基线名称、版本、标识以及当前基线包含的 所有主要配置项等信息（如果前期已建立基线，当前基线的配置项需要包含上一次基 线的配置项）3 .配置管理员检查基线建立控制报告中主要配置项的完整性，相关附件、 评审报告、会议纪要等是否已提交入库。4 .检查通过后，执行打基线操作，并发送邮件通知项目组成员及其他干系人等， 需注意使用配置管理计划中规定的标签名。基线建立相关内容请参考配置管理 规范第10章节。5 .2基线变更管理对于周期较长的项目，如基线计划时间出现2周以上偏差时，需要走变更流程； 周期较短如一个月及以内的项目，如基线计划时间出现1周以上偏差时，需要走变更 流程。1 .首先，项目经理、配

36、置管理员、项目组成员等要对变更所引起的影响进行分 析，无问题后才可以申请此次变更。2 .配置管理员填写变更控制报告相关内容，并发起评审，评审组成员主要 是CCB、项目经理等。3 . CCB评审并批准基线建立变更申请，如通过则执行下一步骤，如不通过则需进行修改直至评审通过。4 .项目经理协助配置管理员安排并执行本次变更，同时，配置管理员需调整配 置管理计划中有关基线计划的相关内容。5 .配置管理员将调整后的计划重新安排评审，无问题后执行下一步骤，若未通 知，则需重新调整相关计划，直至评审通过。6 .配置管理员将调整的文档及相关评审邮件或评审报告纳入配置库，同时发邮 件通知项目组成员。项目组严格按

37、照变更后的计划进行相关工作，配置管理员及时建立基线。有关变 更管理的流程，详见配置管理规范第14章节。7 .3分支合并管理分支合并是指将分支的修订合并到主干或者将主干的修订合并到分支。一般情况 下，主干被用来维护产品稳定、定期或不定期发布更新版本，分支被用来实现或试验 产品/项目影响范围较大或者实现周期较长的的新特性/功能。当分支上的新特性/功 能稳定后可进行分支合并操作。分支建立后应避免长时间的分支状态，应尽可能早的 完成合并。8 .4分支合并流程为了减少分支合并的风险和影响，合并过程应严格控制，合并前的准备工作可以 参考如下事项（以分支合并到主干为例）：1 .项目经理制定、CCB评审分支合

38、并方案，评估合并的风险和影响，指定合并负 责人，确定合并开始时间和结束时间。2 .确保分支上所有文件均被正确、完整签入。3 .通知并取消分支上所有人员的写权限，可保留读权限。4 .尽可能保证主干上相关文件是最新的。5 .开放合并负责人在主干上的写权限。6 .合并之前在主干上打基线、标识合并前的状态，以防合并操作失败时能及时 回滚到合并前的状态、不影响主干的开发工作。7 .合并之前在分支上打基线、标识该分支已开发结束或已发版。8 .合并完成后在主干上打基线、标识合并后的状态。9 .合并完成后安排测试，以确保合并没有问题。10 5分支合并方案制定分支合并方案可以采用Word或Excel等形式，但一

39、般情况下需要包含以下内容:1 .确定所有发生了修订的功能模块和代码文件（这些是合并后测试的重点）。2 .确定功能模块和代码文件的修订所影响的功能。1 概述41.1 角色与职责41.2 工作目标51.3 流程概述5术语定义72 阅读对象7制定配置管理计划74. 1 配置管理软硬件资源确定84. 1. 1明确软硬件资源84. 1.2个人工作空间配置参数要求84.2配置项管理84. 2. 1配置项识别84. 2.2配置项标识134. 2.3配置项入库管理134.3配置库目录结构规划144.4制定基线计划174. 4. 1基线标识174. 4.2制定基线计划174.5明确权限管理184.5. 1用户管

40、理18制定访问控制策略194.6明确分支版本策略214. 6. 1分支合并类型214. 6.2明确分支版本策略224. 6.3基于SVN的分支建立及合并方法235个人工作空间管理265. 1建立个人工作空间261.2 个人工作空间要求261.3 检查个人工作空间26基线管理276 . 1基线建立要求277 .2基线变更管理27分支合并管理287 . 1分支合并流程288 .2分支合并方案制定283 .确定合并方式：直接加入、手工合并、直接覆盖。4 .确定合并负责人及合并开始时间和结束时间。5 .确定合并后测试是完全合并后测试，或者部分功能合并完成后测试等。6 .在合并方案中详细列出分支合并的流

41、程及注意事项。7 .合并方案中的修改功能模块、代码文件、影响功能、合并方式等可参考下表 列出。表9 分支合并方案制定参考列表功序号能模文件目录文件名称功能说明影响功能合并方 式备注块新表 格 控 件srccomj iuqiGr id One直接加入1webjstab 1 ellt i 1手工合 并acrifri nputdata1frWebDataProcessor继承于WebDataProcessor直接覆盖数 据 录 入i nputdata2chkresu1tpr i nt. jsp修改了引入 errorPage. j sp的路径2chooseFormu1 aType. jsp修改了显示

42、界面标题的 逻辑处理加入了对合并报表报表groupTab. jsp分组的支持，有界面参数i s 1 i f r是否等于1决定是序号功 能 模 块文件目录文件名称功能说明影响功能合并方式备注否合并报表模式web/web-infweb.xml添加了一个 支持合并报 表的server Iet8.合并方案中合并负责人及合并开始时间和结束时间等可参考下表列出:序号合并功能模块合并负责人合并时间备注1公共代码、功能常量、表格组 件10月8日 10月9日2单位多版本设置10月8日 10月9日3计划任务10月9日4自定义录入10月9日注：分支合并方案评审通过后，由合并负责人在要求时间内根据分支合并流程执 行分支合并操作。7集成构建代码集成1 .当项目进入编码