1、文件编码文件密级 最新发布日期当前版本 配置管理工作指南郑重声明：XX软件股份有限公司版权所有。本文档中任何部分未经XX软件股份有限公司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播。变更履历版本日期变更位置变更理由/变更内容变更人备注1.0新建1.12.1.1、变更履历根据研发项目管理流程问题巡检检查出的问题进行更新：1、更新2.1.1基线配置项参考列表2、增加变更履历 2.0全文根据新版配置管理规范和目前实际工作进行调整，调整整体框架、将冗余的内容进行删减、优化。 目 录1概述41.1角色与职责41.2工作目标51.3流程概述52术语定义63阅读对象64制定配置管
2、理计划64.1配置管理软硬件资源确定74.1.1明确软硬件资源74.1.2个人工作空间配置参数要求74.2配置项管理74.2.1配置项识别74.2.2配置项标识104.2.3配置项入库管理104.3配置库目录结构规划104.4制定基线计划124.4.1基线标识124.4.2制定基线计划124.5明确权限管理134.5.1用户管理134.5.2制定访问控制策略134.6明确分支版本策略154.6.1分支合并类型154.6.2明确分支版本策略164.6.3基于SVN的分支建立及合并方法175个人工作空间管理195.1建立个人工作空间195.2个人工作空间要求205.3检查个人工作空间206基线管理
3、206.1基线建立要求206.2基线变更管理217分支合并管理217.1分支合并流程217.2分支合并方案制定228集成构建238.1代码集成238.1.1代码更新说明范围界定238.1.2代码更新说明填写238.1.3代码更新说明发布248.2准备构建环境248.3构建测试版本259发布管理259.1正式版本发布259.2测试版本发布269.3临时版本发布269.4产品版本号编码2610备份/还原管理2711记录配置管理活动2712参考及附录271 概述本文的目的是描述配置管理的所有活动应如何开展，为配置管理活动提供指导。1.1 角色与职责对于任何一个管理流程来说，保证该流程正常运转的前提条
4、件就是要有明确的角色、职责和权限的定义，软件配置管理过程中主要涉及下列的角色和分工：No.角色职责1变更控制委员会ChangeControl Board，CCB负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。具体职责如下：1) 评审、批准项目计划等，评估、审批配置项的变更请求等。2) 批准配置管理策略，如访问控制、基线计划、集成构建、分支合并、版本发布等。3) 根据配置管理报告决定相应的对策。2项目经理Project Manager，PM项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。具体职责如下：1) 制定和修改
5、项目的组织结构和配置管理策略。2) 批准、发布配置管理计划。3) 决定项目各类基线和研发里程碑。4) 审阅配置管理报告。3配置管理员（Configuration Management Officer，CMO）根据配置管理计划执行各项管理任务，具体职责如下：1) 配置管理工具的日常管理与维护。2) 制定配置管理计划。3) 配置项日常管理与维护。4) 执行版本控制和变更控制方案。5) 完成配置审计。6) 对项目组成员进行配置管理规范、工具等培训。7) 跟踪软件研发过程、识别存在的问题并拟就解决方案。4系统集成员SystemIntegration Officer，SIO系统集成员负责生成和管理项目的
6、内部和外部发布版本，具体职责如下：1) 建立、维护构建环境，包括明确构建服务器、构建工具选型及配置、明确发布服务器、发布位置及发布方法等。2) 完成构建脚本或构建配置。3) 完成代码集成、版本构建。4) 发布构建版本。5开发人员（Developer，DEV）根据确定的配置管理计划和相关规定，按照配置管理工具的使用模型来完成开发任务。1.2 工作目标通过实施配置管理来提高软件开发管理的水平，增强企业自身的竞争力，应对市场的压力，解决以下软件开发中的常见问题： 1. 开发人员未经授权修改代码或文档。2. 人员流动造成企业的软件核心技术泄密。3. 无法重现历史版本，使维护工作十分困难。 4. “合版
7、本”时，开发冻结，造成进度延误。 5. 软件系统复杂，编译速度慢，造成进度延误。 6. 因一些特性无法按期完成而影响整个项目的进度或导致整个项目失败。7. 已修复的Bug 在新版本中出现。8. 开发团队难于协同，可能会造成重复工作，并导致系统集成困难。最终实现以下目标：1. 控制工作产品的识别、提交、入库和存储，确保项目过程中所有工作产品纳入统一数据库管理。2. 建立基线概念，使版本与一系列内在一致的工作产品相关联，这里的工作产品包括代码、文档、测试数据、构建的二进制文件，能够保证配置库中各历史版本的完整复原。3. 为开发团队建立一致的开发配置环境，开发配置环境包括开发工具、工作空间、开发过程
8、中引用的代码、文档、二进制文件。4. 建立组织配置库的安全管理策略，确保配置库的建立、迁移、存储、复制、发布、访问、删除都处于受控的信任环境下，配置库的访问应能保证合适人员能够访问他应该访问数据、文档、代码，而且也只能访问他责任范围之内数据、文档和代码。1.3 流程概述项目经理制定项目管理计划后，配置管理员应与项目经理一起进行配置管理活动的策划，形成配置管理计划，作为配置管理活动的基础。它的主要流程如下：1. 项目经理和配置管理员共同确定本项目配置管理的软硬件资源。2. 依据项目管理计划，配置管理员与项目经理共同识别主要配置项、规划配置库目录结构、制定权限分配策略、确定基线计划等。3. 配置管
9、理员与项目经理共同确定项目的变更策略、分支合并策略、集成构建策略以及版本发布策略等。4. 配置管理员完成配置管理计划。5. 配置管理计划评审活动由配置管理员发起，评审组由CCB成员组成。6. CCB对已制定的配置管理计划进行评审，直至CCB评审通过。7. 配置管理员将审批通过的配置管理计划纳入配置库进行管理，并发布给项目组相关人员。以上各活动具体要求，可参考配置管理规范。No.术语定义1配置管理（CM）配置管理是对项目生命周期过程中各阶段产品和最终产品演化和变更的管理，是质量管理的重要组成部分。配置管理通过一系列技术、方法和手段实现：l 指导和监督对配置项的物理与功能特性的标识和归档工作。l
10、控制上述特性的变更，记录并报告变更的处理和实现状态，并验证与需求的一致性。2变更控制委员会（CCB）CCB是一个虚拟小组，由项目监理小组、项目经理、资深项目成员、配置管理员、品质保证工程师等组成，项目经理为CCB召集人；CCB对配置管理各项活动拥有决策权（例如评审计划、评审变更请求等），负责评估和审批配置项的变更、确保所有的变更都是经过审核的。3配置项（Configuration Item, CI）配置项是指纳入配置管理范畴的工作成果的最小集合。例如一个文档（如需求文档、设计文档、测试用例、用户文档等属于产品组成部分的工作成果以及项目管理、组织支撑过程域产生的文档）或一组构成独立功能单元的源代
11、码文件都可以定义为一个配置项。4基线（Baseline）基线由一组稳定的特定版本的配置项组成，是进一步开发的基础。基线中的配置项是被“冻结”的，不能被随意修改。基线通常在开发过程中的里程碑（Milestone）处建立，一般包括需求基线、设计基线、开发基线、发版基线、结项基线等。5配置管理员（CMO）每个项目应配备一个配置管理员（可专职或由项目组某个成员兼职），为该项目制定配置管理计划、创建和维护配置库、适时出具配置管理各种报告如基线建立控制报告、配置项变更控制报告、版本发布通知等。2 术语定义3 阅读对象配置管理员、产品/项目经理4 制定配置管理计划配置管理计划的制定过程由明确配置管理软硬件环
12、境、识别配置项、规划配置库目录结构、制定权限分配策略、制定基线计划、明确分支版本策略、明确集成构建策略、明确版本发布策略等一系列活动组成。每个活动的最终成果体现在配置管理计划中，相关流程说明可查看配置管理规范第5章节内容。4.1 配置管理软硬件资源确定1. 配置管理员与项目经理沟通确定配置管理环境，包括软硬件资源、部署结构、服务器端配置参数要求、个人工作空间配置参数要求等。2. 确定使用何种配置管理工具、其部署情况、配置管理服务器的参数要求等。3. 公司明确规定新立项目自2010年开始，全部使用jqcm配置管理服务器以及SVN配置管理工具。有关服务器和工具的详细信息已列示在配置管理计划（模板）
13、中。4.2 明确软硬件资源l 硬件资源1. 明确配置管理服务器以及配置管理工具：配置管理服务器的软硬件配置、是集中式管理还是分布式部署（一般情况下，公司配置管理服务器采用集中管理的方式）；配置管理工具客户端软件或插件的版本。2. 预估所需的磁盘容量：为保证选择的机器硬件可以在今后一段时间内（如，五年内）满足可能的需求，需要预先估算配置管理服务器的使用情况、了解配置管理工具对硬件的要求。l 软件资源1. 确定CCB成员名单，根据项目不同规模和重要程度，CCB成员建议可以包括分管副总、研发项目总监、部门经理、项目经理以及其他受变更影响的人员代表（必要时可包括测试人员等）。2. 确定本产品/项目研发
14、人员需遵循的编码规范、界面规范或其他开发规范。4.3 个人工作空间配置参数要求1. 项目组在编码前需要使团队工作在统一的工作平台上。2. 配置管理员需要与项目经理沟通确定使用的开发/测试平台、开发/测试机的软硬件环境等，并最终记录在配置管理计划中。3. 项目组成员应按照配置管理计划中约定的个人工作空间配置参数要求准备开发、测试或文档编写等环境。4.4 配置项管理4.5 配置项识别在制定项目管理计划时，项目经理需要首先识别配置项，并指定基线配置项、非基线配置项。在执行项目配置管理时，需要重点控制基线配置项，在识别项目配置项时，配置管理员需完成以下工作：1. 配置管理员参照公司配置项参考列表&配置
15、库参考目录.xls制定本项目配置项列表。2. 配置管理员与项目经理和项目主要成员确认项目配置项列表。3. 配置管理员确认工作成果的内容，确定是否可以与现有配置项合并或者作为新的配置项。4. 配置管理员与项目经理确认，识别新的配置项。5. 配置管理员识别出新配置项为基线类配置项或非基线类配置项。l 基线配置项参考列表项目经理制定项目里程碑计划时，需要明确各里程碑产生的配置项。配置管理员根据里程碑计划制定基线计划。基线配置项往往需要严格控制，并会对项目基线建立产生影响。基线配置项确定标准如下：1. 重要的提交物。2. 配置项易发生变化，需要进行版本控制。3. 属于管理控制重点的配置项，如源代码。下
16、表给出了基线配置项参考列表，各项目可以根据实际情况确定相应的基线配置项。表1 基线配置项参考列表类型配置项配置项分类备注项目管理项目管理计划基线类配置项项目进度计划基线类配置项项目周报基线类配置项项目里程碑报告基线类配置项评审报告/会议纪要基线类配置项风险/重大问题跟踪表基线类配置项配置管理计划基线类配置项基线建立控制报告基线类配置项基线建立前检查Checklist基线类配置项品质保证计划基线类配置项项目路线图基线类配置项项目总结报告基线类配置项遗留问题跟踪表基线类配置项提交工作产品清单基线类配置项需求定义概要技术方案说明书基线类配置项需求说明书基线类配置项需求规格说明书基线类配置项设计开发技
17、术研究报告基线类配置项设计说明书基线类配置项数据库设计说明书基线类配置项系统稳定测试计划基线类配置项测试用例基线类配置项测试总结基线类配置项功能/性能测试报告基线类配置项发版说明基线类配置项产品化包装用户手册基线类配置项培训资料基线类配置项系统安装配置说明书基线类配置项产品介绍PPT基线类配置项产品解决方案基线类配置项产品实施指南基线类配置项产品报价策略基线类配置项技术白皮书基线类配置项l 非基线配置项参考列表项目非基线配置项区别于基线配置项，是指没有纳入基线计划的配置项。非基线配置项一般不影响项目进展，不需要在基线建立时进行严格控制。下表给出了非基线配置项参考列表，各项目可以根据项目实际情况
18、确定相应的非基线配置项。表2 非基线配置项参考列表类型配置项配置项分类备注项目管理项目立项报告、项目启动会PPT等非基线类配置项配置管理相关文档非基线类配置项品质保证相关文档非基线类配置项项目汇报相关文档非基线类配置项各种管理跟踪表非基线类配置项会议评审相关文档非基线类配置项培训相关文档非基线类配置项项目结项总结PPT等非基线类配置项电子邮件非基线类配置项非基线类配置项需求定义调研准备非基线类配置项调研资料非基线类配置项非基线类配置项设计开发其他设计类参考资料、文档非基线类配置项源代码源代码、单元测试源代码非基线类配置项可执行文件非基线类配置项系统稳定缺陷跟踪相关文档非基线类配置项维护记录相关
19、文档非基线类配置项产品化包装用户培训资料、帮助等非基线类配置项系统维护系统维护相关文档非基线类配置项非基线类配置项 在项目进展过程中，配置管理员需定期跟踪并维护项目配置项列表（体现在配置管理计划中），需注意以下各项工作：1. 配置管理员每周阅读项目周报、每月阅读项目月报，关注周报、月报中列出的项目工作成果。2. 配置管理员对照配置管理计划的配置项计划，识别出未纳入计划的配置项清单。3. 配置管理员就新配置项清单与项目经理和项目主要成员确认。4. 将新识别的配置项清单更新到配置管理计划中（将新的基线配置项列入基线配置项列表，将新的非基线配置项列入非基线配置项列表）。5. 将新经过评审的基线配置项
20、和正确的非基线配置项纳入配置库。6. 基线配置项入库后如需修改请遵循变更流程。4.6 配置项标识标识的本质就是区分，在众多的配置项中合理、科学的命名是最好的区分方法。所有配置项都应按照相关规定统一编号，按照相应的模板生成。l 配置项标识需要遵循以下原则：1. 唯一性2. 可追溯性3. 与同类配置项不同的信息，应纳入标识：这是为了便于区分、查找4. 同类配置项的标识方法统一5. 容易记忆l 配置项标识需要遵循以下要求：1. 所有纳入管理的配置项必须按照公司文档编码规范进行命名（不包含配置库草稿目录下的草稿文件），配置项的命名要遵守“项目编号+项目名称+文档产品+可选字段（主题/版本/人名/日期）
21、”的命名原则，同时命名要求需体现在配置管理计划中，详细内容请参见文件编码及命名规范。2. 基线配置项必须符合文档规范，需使用公司最新发布的文档模板（若客户方有特殊要求，需提前说明），各类最新项目文档模板可直接进入公司portal主页-规章制度下获取。3. 新建或修改基线配置项的文档内容时，必须同时填写相应的变更履历。4.7 配置项入库管理1. 配置项的存放目录应参考组织级配置库目录，由配置管理员在配置库中建立。2. 配置项必须按照配置管理计划中配置库目录结构划分的要求纳入到正确的目录中。3. 配置项需及时、正确入库，配置管理员或项目经理/工作产品负责人根据项目周报中的工作成果每周检查、并督促入
22、库。4. 配置项的首次入库时间不以基线建立时间为准，应以评审、定稿时间为准，最多不得超过两周时间、并且必须在基线建立前；对配置项的修改或变更在评审、定稿后同样应及时入库。5. 配置项的正式发布必须在配置库的正式目录中，不得存放于工作草稿等目录中。6. 产品/项目进行过程中产生的各种需求、设计、测试、实施、评审、培训等以及项目管理的最终文档、中间文档以及附带的图稿原件如时序图等，临时产生的各种用于交流、讨论、备忘的记录、材料等，均应该完整、及时纳入配置库，由项目经理负责检查落实，配置管理员定期督促。7. 对于主要配置项，如需求规格说明书、项目管理计划等的变更，需要走“申请-CCB审批-CM检出-
23、变更-CCB审批-检入”的变更流程。4.8 配置库目录结构规划1. 公司所有项目配置库目录可参照组织级配置项参考列表&配置库参考目录创建。2. 整个配置库目录需要按配置管理计划中的配置库目录结构要求创建。表3 配置项参考列表&配置库参考目录一级目录二级目录三级目录内容说明备注项目管理项目立项项目立项申请、项目启动会PPT（可选）、项目基本信息表等项目计划项目管理计划、项目进度计划项目汇报项目周报项目周报其他报告项目里程碑报告、阶段性汇报PPT（可选）等管理跟踪风险/重大问题跟踪表、项目备忘大事记（可选）配置管理管理策略配置管理计划基线建立基线建立控制报告、基线建立前检查Checklist变更管
24、理配置项变更控制报告（可选）、变更控制重点监控配置项清单（可选）、重点控制项变更检查表、产品发布更新说明（产品型项目）品质保证管理策略品质保证计划检查记录项目路线图、品质保证检查记录（工作流程审计、工作产品检查、工程规范检查）会议评审会议纪要、评审报告、会议签到表（可选）、评审数据汇总表（可选）等可按事件等建立子目录培训培训通知（可选）、培训材料（可选）、培训签到表（可选）、培训评估报告（可选）可按事件等建立子目录电子邮件与客户往来沟通确认的工作邮件存档、项目组内部沟通确认的工作邮件存档可按主题等建议子目录项目结项项目总结报告、项目结项总结会PPT（可选）、提交工作产品清单、遗留问题跟踪表其它
25、需求定义需求调研调研计划、调研提纲、调研报告&访谈记录需求草稿从客户或其他途径获得的资料、需求草稿需求确认产品可研论证报告（产品型）、产品/项目愿景说明书、项目范围说明书（普通）、需求说明书、需求规格说明书、需求跟踪矩阵（可选）设计开发设计草稿设计草稿文档设计确认概要技术方案说明书、总体/模块设计说明书、数据库设计说明书、模块依赖关系表、技术研究报告（可选）系统稳定管理策略测试计划测试用例测试用例、测试点（可选）、性能测试方案（可选）测试报告阶段测试总结（可选）、系统测试报告、功能/性能测试报告（可选）、用户验收测试报告（可选）上线及试运行实施日志（普通）、实施配置报告（普通）、问题跟踪一览表
26、、项目分工界面（可选）、项目验收备忘录（普通）、用户验收证书（普通）可选版本发布发版申请、发版计划、正式版产品发布基线清单、产品发布更新说明产品化包装用户文档用户手册、帮助、系统安装配置说明书、用户培训资料等产品包装产品技术白皮书、产品解决方案、产品宣传彩页、产品介绍PPT、产品实施方案、产品咨询方案、产品报价策略系统维护年度1维护事件1可选年度2源代码开发源代码4.9 制定基线计划4.10 基线标识1. 计划性基线：“项目编号-阶段标识 -YYYYMMDD”。2. 事件性基线：“项目编号-阶段标识-事件英文缩写-YYYYMMDD”。4.11 制定基线计划基线分为计划性基线和事件性基线，计划性
27、基线在配置管理计划中体现，事件性基线由相关人员提出申请建立，不在配置管理计划中体现。表4 基线参考列表基线名称/标识符包含的主要配置项建立时间产品定义基线：项目编号-REQBaseline-YYYYMMDD需求说明书需求规格说明书项目管理计划品质保证计划配置管理计划测试计划风险/重大问题跟踪表各种报告和跟踪表产品设计与开发基线：项目编号-DES+CODEBaseline- YYYYMMDD概要技术方案说明书总体/模块设计说明书数据库设计说明书测试用例源代码产品发版/稳定基线：项目编号-RELEBaseline- YYYYMMDD功能/性能测试报告用户手册培训资料技术白皮书发布版本项目结项基线：
28、项目编号-ENDBaseline- YYYYMMDD项目总结报告提交工作产品清单遗留问题跟踪表注：基线计划时间出现2周以上偏差或主要配置项变更时，需要走变更流程。4.12 明确权限管理4.13 用户管理用户角色组主要有：配置管理员、CCB、项目经理、需求人员、设计人员、开发人员、测试人员、实施人员、品质保证员等。各用户角色定义详见配置管理规范9.1章节,对项目配置库中用户角色的管理，配置管理员需注意以下几点：1. 项目配置库用户需要根据项目情况相应调整。2. 一般情况下，项目配置库用户如需调整增加或删除，由项目经理提交邮件申请，配置管理员收到邮件申请后，执行相应操作。特殊情况下，可由项目组成员
29、提交邮件申请，抄送项目经理及相关人员。3. 配置管理员在收到邮件申请后，执行相应操作，并将用户分配到不同组里。4. 配置管理员增加或删除用户后，需要邮件通知项目经理及相关人员。邮件通知中需要附加配置库连接地址及简要操作说明。4.14 制定访问控制策略在建立配置库以前，项目经理需要给配置管理员提供明确的项目组各成员角色的访问控制策略，配置管理员结合配置管理工具，衡量访问控制策略的合理性，与项目经理确认后制定访问控制策略，并记录到配置管理计划中。4.15 配置库资源与操作定义不同角色用户对配置库操作主要有：1. 项目配置库创建、维护、删除。2. 项目成员及组的设置、维护。3. 基线建立、维护。4.
30、 分支/合并。5. 对文档、目录的读写访问。6. 对源代码文件、源代码目录的读写访问等。由于不同配置管理工具对配置库操作的控制粒度不同，在具体设置配置库操作权限时，需要结合配置管理工具的特性进行设置。表5 配置库操作列表序号资源SVN操作定义1配置库创建文件夹：Create Folder删除文件夹：Delete分支/建基线(打标签)：Branch/tag合并：Merge访问控制：设置用户组的权限2项目文件夹读(Read)：Checkout、Export、update写(Write)：Add、commit、Get/Release Lock、Rename、delete、Copy to3项目文件读(
31、Read)：Checkout、Export、update写(Write)：Add、commit、Get/Release Lock、Rename、delete、Copy to4代码目录读(Read)：Checkout、Export、update写(Write)：Add、commit、Get/Release Lock、Rename、delete、Copy to4.16 角色划分策略配置库角色主要有：配置管理员、项目经理、开发人员、测试人员、实施人员，不同角色的职责不同。配置库授权控制参考列表如下：表6 角色划分参考列表序号资源配置库操作配置管理员项目经理需求/设计/开发人员测试人员CCB/实施/品
32、质保证人员1配置库配置库创建、维护、删除完全无无无无用户及角色组的设置、维护、授权控制完全无无无无基线建立完全无无无无分支/合并完全无无无无2文件/文件夹读写访问完全读写读写读写只读3源代码读写访问完全读写读写无无4产品库读写访问完全只读只读读写只读4.17 配置库操作权限参考表7 配置库操作权限参考列表编号一级目录权限说明1项目管理项目经理、配置管理员可写，CCB、测试人员、QA人员可读2需求定义项目经理、配置管理员、开发人员可写，CCB、测试人员、QA人员可读3设计开发项目经理、配置管理员、开发人员可写，CCB、测试人员、QA人员可读4系统稳定项目经理、配置管理员、测试人员可写，CCB、开
33、发人员、QA人员可读5上线及试运行项目经理、配置管理员可写，CCB、开发人员、测试人员、QA人员可读6产品化包装项目经理、配置管理员可写，CCB、开发人员、测试人员、QA人员可读7系统维护项目经理、配置管理员可写，CCB、开发人员、测试人员、QA人员可读8源代码项目经理、配置管理员、开发人员可写，CCB可读，测试人员、QA人员无权限4.18 明确分支版本策略4.19 分支合并类型在软件开发实践中，常常出现一些令人沮丧的事，如软件紧急更改提交集成失败、发布错误版本、修复过的缺陷又莫名其妙地出现等等。主要的原因在于在实际开发中没有应用软件配置管理或应用软件配置管理不当，选择并应用正确的分支模型，对
34、避免开发过程的混乱尤其重要。 常见的分支合并类型有以下几种：l 分支合并到分支；l 分支合并到主干；l 主干合并到分支。1. 项目组根据项目情况不同，需事先约定所选择的合并类型，以便为后期可能的分支合并做好准备，配置管理员将所选择的类型记录到配置管理计划中。2. 分支合并前应临时去除相关分支所有人员的写权限，只保留被合并分支上合并人员的读权限。3. 应当尽量避免一个分支合并多次。当一个分支完成特定任务后，应及时合并。4. 合并完成后分支应设置为只读，不再允许对该分支进行修改。4.20 明确分支版本策略选择正确的分支策略使版本正确发布、重构以前的版本或者重新回到以前的版本等工作更加容易。采用分支
35、模型使软件开发过程更加便捷、软件开发更加高效、软件质量得到提高，并且可以减少软件开发中的错误和提高软件开发团队的整体效率。选择适当的分支模型，应从以下几个方面考虑：1. 支持连续不间断的集成，从而保持新开发过程的稳定的基准；2. 提交应急版本（只包括所有必要的修复）进行测试和交付用户； 3. 包含有所有必要的修复而无其它更改的测试版本发布；4. 使应急发布对新开发过程的影响最小化；5. 根据项目需要，回退到以前的产品状态；6. 支持多个共存版本，如不同平台或不同用户的备选版本。关于代码管理的分支和发布策略，主要有两种模式：1. 新功能开发在分支上进行，主干用于稳定版的发布。2. 新功能开发在主
36、干上进行，分支用于稳定版的发布。4.21 主干稳定当新功能开发在分支上进行、开发结束、功能测试通过时，将分支合并到主干修订集成测试、系统测试所发现的BUG，在主干上进行发版；同时将分支设置为只读。主干稳定策略与分支稳定策略刚好相反，主干上永远是稳定版本，可以随时发布。缺陷修改和新功能的开发都在分支上进行，而且每个缺陷修改和新功能都有不同的开发分支，是完全分离的，在分支上测试通过后才合并到主干，在主干上的每一次发布都需要用标签标识。优点：1. 开发周期较灵活，各功能模块自主定义开发周期，每个分支的生命周期比较短，唯一长期存在的就是主干，这样每次合并的风险比较小。2. 每次发布的内容调整起来比较容
37、易。3. 如果某个新功能或缺陷修改在发布之前无法完成，就不会合并到主干，也不会影响其他变更的发布。缺点：1. 如果某个开发分支因为功能比较复杂，或其他原因长期没有合并到主干，则最后合并的时候很可能会出现冲突。为避免合并时产生冲突需要注意以下问题：2. 如果有的分支确实因为特殊的需要必须长期存在，那就必须定期把主干的更新往这个分支上合并。3. 如果发布周期很长，各个发布分支之间还要定期的从前向后合并。4. 测试在发布分支上进行，而发布在主干上进行，这就引入了合并出错的风险，而主干上的程序是没有经过测试的。4.22 分支稳定当新功能开发在主干上进行、临近发布阶段时，从主干建立分支，在分支上修订集成
38、测试、系统测试所发现的BUG，在分支上进行发版；主干继续进行新功能开发。版本发布完成后，将分支合并到主干，分支设置为只读。采用分支稳定策略情况下，主分支中永远是最新的功能，当新功能开发到达某个里程碑后发布，从主干分支用于该版本的缺陷修改及现有功能的完善。当稳定分支上的修改积累到一定程度就会进行一次发布。 优点：1. 这种发布方法非常适用于产品线的发布管理，以前的版本仍需要继续维护，而新功能也不断地在增加。2. 对于已经发布的产品，只有维护的补丁发布。而新发布的产品不仅包括了所有的bug修改，还包括了新功能。缺点：1. 只能增加下一个发布里面计划集成进去的新特性，同时必须对主干上新功能的增加进行
39、控制，否则新版本的发布将出现严重延期。2. 如果主干上的某个新功能，测试不通过，达不到里程碑的要求，新版本的发布也会出现延期。3. 缺陷修改必须在各个分支之间合并，各个长期存在的分支之间必须要周期性的进行合并，否则很容易引发合并冲突。因此，采用这种分支策略可能碰到的最大问题就是某个分支上的bug修改内容往其它分支merge的时候出现的冲突。而且一旦发现一个bug，调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。4.23 基于SVN的分支建立及合并方法表8 SVN分支建立及合并方法参考列表操作SVN分支/合并操作说明新建分支1Branch/tag（分支标记）方法一：当新建分支时
40、，在工作副本右键点击要开分支的文件目录，选择“Branch/tag”功能创建分支。2Copy to（复制到）方法二：使用TSVN客户端浏览器，选择”Copy to”功能将需要建立分支的文件夹”复制”到branches目录下。合并分支Merge（合并）选择所需要使用的合并类型进行合并。(合并步骤参考本指南4.6.3.2章节)。4.24 分支建立步骤1. 由于SVN提供可以创建从主干向分支、分支向主干、分支向分支三种类型的分支，首选需明确开分支的起始位置及结束位置。2. 新建分支的操作方法有两种，如上表所属（表8），使用第一种方法需在工作副本中进行，第二种方法通过SVN浏览器完成。3. 选择分支文
41、件所存放的目录路径，一般情况下，分支文件存放在branches目录下，以上信息明确后即可开始创建分支。4. 分支创建完成后，开发人员再次确定分支目录结构是否有需调整。5. 分支创建完成后，配置管理员需明确配置库分支目录文件的权限分配策略，明确相关人员角色并开放相关权限。4.25 分支合并步骤分支合并有三种常见类型：1. 单分支合并2. 多分支合并，且起始主干版本号相同3. 多分支合并，且起始主干版本号不同使用SVN进行合并操作时，提供了三种方法，区别是：操作SVN合并方法特点说明合并分支1合并一个版本范围可任意选择分支的版本，主干不能选择版本，只能使用最新版本。2复兴分支无乱是主干和分支都不能
42、任意选择版本，只能使用最新版本。3合并两个不同的树无乱是主干和分支都可以任意选择版本，包括最新版本。l 单分支合并操作方法比较简单，同多分支合并操作步骤一中相同，参见多分支合并的步骤。l 多分支合并，且起始主干版本号相同（如下图）合并需两步操作，并且操作在主干T 的工作副本内执行： l 主干T合并分支A 输入起始URL 和版本（如：主干T 的URL 、版本100）；输入结束的URL 和版本（如：分支A的URL 、版本110）； l 合并分支A 后再继续合并分支B 输入起始URL 和版本（如：主干T 的URL 、版本100） ；输入结束的URL 和版本 （如：分支B的URL 、版本115） ；l 多分支合并，且起始主干版本号不同（如下图）合并需三步操作： l 分支A 更新主干版本至最新版本，在分支A 的工作副本内执行输入起始URL 和版本（如：主干T 的URL 、版本100）；输入结束的URL 和版本（如：主干T 的URL 、版本102）； l 合并分支A 输入起始URL 和版本（如：主干T 的U
