2024年5月2日发(作者：)

文件编码

最新发布日期

文件密级

当前版本

配置管理工作指南

郑重声明：

XX软件股份有限公司版权所有。本文档中任何部分未经XX软件股份有限公司

书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播。

变更履历

版本

1.0

日期

变更位置

2.1.1、变

更履历

变更理由/变更内容

新建

根据研发项目管理流程问题巡检检查出的

问题进行更新：

1、更新2.1.1基线配置项参考列表

2、增加变更履历

根据新版《配置管理规范》和目前实际工

作进行调整，调整整体框架、将冗余的内

容进行删减、优化。

变更人

备注

1.1

2.0

全文

目 录

1

概述 ....................................................................... 4

1.1

角色与职责 .............................................................. 4

1.2

工作目标 ................................................................ 5

1.3

流程概述 ................................................................ 5

2

3

4

术语定义 ................................................................... 7

阅读对象 ................................................................... 7

制定配置管理计划 ........................................................... 7

4.1

配置管理软硬件资源确定 .................................................. 8

4.1.1

4.1.2

明确软硬件资源 ...................................................... 8

个人工作空间配置参数要求 ............................................ 8

4.2

配置项管理 .............................................................. 8

4.2.1

4.2.2

4.2.3

配置项识别 .......................................................... 8

配置项标识 ......................................................... 13

配置项入库管理 ..................................................... 13

4.3

配置库目录结构规划 ..................................................... 14

4.4

制定基线计划 ........................................................... 17

4.4.1

4.4.2

基线标识 ........................................................... 17

制定基线计划 ....................................................... 17

4.5

明确权限管理 ........................................................... 18

4.5.1

4.5.2

用户管理 ........................................................... 18

制定访问控制策略 ................................................... 19

4.6

明确分支版本策略 ....................................................... 21

4.6.1

4.6.2

4.6.3

5

分支合并类型 ....................................................... 21

明确分支版本策略 ................................................... 22

基于SVN的分支建立及合并方法 ....................................... 23

个人工作空间管理 .......................................................... 26

5.1

建立个人工作空间 ....................................................... 26

5.2

个人工作空间要求 ....................................................... 26

5.3

检查个人工作空间 ....................................................... 26

6

基线管理 .................................................................. 27

6.1

基线建立要求 ........................................................... 27

6.2

基线变更管理 ........................................................... 27

7

分支合并管理 .............................................................. 28

7.1

分支合并流程 ........................................................... 28

7.2

分支合并方案制定 ....................................................... 28

8

集成构建 .................................................................. 30

8.1

代码集成 ............................................................... 30

8.1.1

代码更新说明范围界定 ............................................... 31

8.1.2

代码更新说明填写 ................................................... 31

8.1.3

代码更新说明发布 ................................................... 31

8.2

准备构建环境 ........................................................... 32

8.3

构建测试版本 ........................................................... 32

9

发布管理 .................................................................. 32

9.1

正式版本发布 ........................................................... 33

9.2

测试版本发布 ........................................................... 33

9.3

临时版本发布 ........................................................... 34

9.4

产品版本号编码 ......................................................... 34

10

11

12

备份/还原管理 ........................................................... 35

记录配置管理活动......................................................... 35

参考及附录 .............................................................. 35

1 概述

本文的目的是描述配置管理的所有活动应如何开展，为配置管理活动提供指导。

1.1 角色与职责

对于任何一个管理流程来说，保证该流程正常运转的前提条件就是要有明确的角

色、职责和权限的定义，软件配置管理过程中主要涉及下列的角色和分工：

No. 角色 职责

负责指导和控制配置管理的各项具体活动的进行，为项目经理的决

变更控制委员策提供建议。具体职责如下：

1

会 1) 评审、批准项目计划等，评估、审批配置项的变更请求等。

ChangeControl 2) 批准配置管理策略，如访问控制、基线计划、集成构建、分支

Board，CCB 合并、版本发布等。

3) 根据配置管理报告决定相应的对策。

项目经理是整个软件研发活动的负责人，他根据软件配置控制委员

会的建议批准配置管理的各项活动并控制它们的进程。具体职责如

项目经理

下：

2 Project

Manager，PM

1) 制定和修改项目的组织结构和配置管理策略。

2) 批准、发布配置管理计划。

3) 决定项目各类基线和研发里程碑。

4) 审阅配置管理报告。

根据《配置管理计划》执行各项管理任务，具体职责如下：

1) 配置管理工具的日常管理与维护。

配置管理员2) 制定《配置管理计划》。

3

（Configurati3) 配置项日常管理与维护。

on Management 4) 执行版本控制和变更控制方案。

Officer，CMO） 5) 完成配置审计。

6) 对项目组成员进行配置管理规范、工具等培训。

7) 跟踪软件研发过程、识别存在的问题并拟就解决方案。

系统集成员

4

SystemIntegra

tion Officer，

SIO

系统集成员负责生成和管理项目的内部和外部发布版本，具体职责

如下：

1) 建立、维护构建环境，包括明确构建服务器、构建工具选型及

配置、明确发布服务器、发布位置及发布方法等。

2) 完成构建脚本或构建配置。

No. 角色 职责

3) 完成代码集成、版本构建。

4) 发布构建版本。

开发人员

5 （Developer，

DEV）

1.2 工作目标

根据确定的《配置管理计划》和相关规定，按照配置管理工具的使

用模型来完成开发任务。

通过实施配置管理来提高软件开发管理的水平，增强企业自身的竞争力，应对市

场的压力，解决以下软件开发中的常见问题：

1. 开发人员未经授权修改代码或文档。

2. 人员流动造成企业的软件核心技术泄密。

3. 无法重现历史版本，使维护工作十分困难。

4. “合版本”时，开发冻结，造成进度延误。

5. 软件系统复杂，编译速度慢，造成进度延误。

6. 因一些特性无法按期完成而影响整个项目的进度或导致整个项目失败。

7. 已修复的Bug 在新版本中出现。

8. 开发团队难于协同，可能会造成重复工作，并导致系统集成困难。

最终实现以下目标：

1. 控制工作产品的识别、提交、入库和存储，确保项目过程中所有工作产品纳

入统一数据库管理。

2. 建立基线概念，使版本与一系列内在一致的工作产品相关联，这里的工作产

品包括代码、文档、测试数据、构建的二进制文件，能够保证配置库中各历史版本的

完整复原。

3. 为开发团队建立一致的开发配置环境，开发配置环境包括开发工具、工作空

间、开发过程中引用的代码、文档、二进制文件。

4. 建立组织配置库的安全管理策略，确保配置库的建立、迁移、存储、复制、

发布、访问、删除都处于受控的信任环境下，配置库的访问应能保证合适人员能够访

问他应该访问数据、文档、代码，而且也只能访问他责任范围之内数据、文档和代码。

1.3 流程概述

项目经理制定《项目管理计划》后，配置管理员应与项目经理一起进行配置管理

活动的策划，形成《配置管理计划》，作为配置管理活动的基础。它的主要流程如下：

1. 项目经理和配置管理员共同确定本项目配置管理的软硬件资源。

2. 依据《项目管理计划》，配置管理员与项目经理共同识别主要配置项、规划配

置库目录结构、制定权限分配策略、确定基线计划等。

3. 配置管理员与项目经理共同确定项目的变更策略、分支合并策略、集成构建

策略以及版本发布策略等。

4. 配置管理员完成《配置管理计划》。

5. 《配置管理计划》评审活动由配置管理员发起，评审组由CCB成员组成。

6. CCB对已制定的《配置管理计划》进行评审，直至CCB评审通过。

7. 配置管理员将审批通过的《配置管理计划》纳入配置库进行管理，并发布给

项目组相关人员。以上各活动具体要求，可参考《配置管理规范》。

No. 术语 定义

配置管理是对项目生命周期过程中各阶段产品和最终产品演化和变

更的管理，是质量管理的重要组成部分。配置管理通过一系列技术、

方法和手段实现：

1 配置管理（CM）

 指导和监督对配置项的物理与功能特性的标识和归档工作。

 控制上述特性的变更，记录并报告变更的处理和实现状态，并

验证与需求的一致性。

CCB是一个虚拟小组，由项目监理小组、项目经理、资深项目成员、

2

变更控制委员

会（CCB）

配置管理员、品质保证工程师等组成，项目经理为CCB召集人；CCB

对配置管理各项活动拥有决策权（例如评审计划、评审变更请求等），

负责评估和审批配置项的变更、确保所有的变更都是经过审核的。

配置项

3 （Configurat

ion Item, CI）

配置项是指纳入配置管理范畴的工作成果的最小集合。例如一个文

档（如需求文档、设计文档、测试用例、用户文档等属于产品组成

部分的工作成果以及项目管理、组织支撑过程域产生的文档）或一

组构成独立功能单元的源代码文件都可以定义为一个配置项。

基线由一组稳定的特定版本的配置项组成，是进一步开发的基础。

4

基线基线中的配置项是被“冻结”的，不能被随意修改。基线通常在开

（Baseline） 发过程中的里程碑（Milestone）处建立，一般包括需求基线、设计

基线、开发基线、发版基线、结项基线等。

每个项目应配备一个配置管理员（可专职或由项目组某个成员兼

5

配置管理员

（CMO）

职），为该项目制定《配置管理计划》、创建和维护配置库、适时出

具配置管理各种报告如基线建立控制报告、配置项变更控制报告、

版本发布通知等。

2 术语定义

3 阅读对象

配置管理员、产品/项目经理

4 制定配置管理计划

《配置管理计划》的制定过程由明确配置管理软硬件环境、识别配置项、规划配

置库目录结构、制定权限分配策略、制定基线计划、明确分支版本策略、明确集成构

建策略、明确版本发布策略等一系列活动组成。每个活动的最终成果体现在《配置管

理计划》中，相关流程说明可查看《配置管理规范》第5章节内容。

4.1 配置管理软硬件资源确定

1. 配置管理员与项目经理沟通确定配置管理环境，包括软硬件资源、部署结构、

服务器端配置参数要求、个人工作空间配置参数要求等。

2. 确定使用何种配置管理工具、其部署情况、配置管理服务器的参数要求等。

3. 公司明确规定新立项目自2010年开始，全部使用jqcm配置管理服务器以及

SVN配置管理工具。有关服务器和工具的详细信息已列示在《配置管理计划（模板）》

中。

4.2 明确软硬件资源

 硬件资源

1. 明确配置管理服务器以及配置管理工具：配置管理服务器的软硬件配置、是

集中式管理还是分布式部署（一般情况下，公司配置管理服务器采用集中管理的方

式）；配置管理工具客户端软件或插件的版本。

2. 预估所需的磁盘容量：为保证选择的机器硬件可以在今后一段时间内（如，

五年内）满足可能的需求，需要预先估算配置管理服务器的使用情况、了解配置管理

工具对硬件的要求。

 软件资源

1. 确定CCB成员名单，根据项目不同规模和重要程度，CCB成员建议可以包括分

管副总、研发项目总监、部门经理、项目经理以及其他受变更影响的人员代表（必要

时可包括测试人员等）。

2. 确定本产品/项目研发人员需遵循的编码规范、界面规范或其他开发规范。

4.3 个人工作空间配置参数要求

1. 项目组在编码前需要使团队工作在统一的工作平台上。

2. 配置管理员需要与项目经理沟通确定使用的开发/测试平台、开发/测试机的

软硬件环境等，并最终记录在《配置管理计划》中。

3. 项目组成员应按照《配置管理计划》中约定的个人工作空间配置参数要求准

备开发、测试或文档编写等环境。

4.4 配置项管理

4.5 配置项识别

在制定项目管理计划时，项目经理需要首先识别配置项，并指定基线配置项、非

基线配置项。在执行项目配置管理时，需要重点控制基线配置项，在识别项目配置项

时，配置管理员需完成以下工作：

1. 配置管理员参照公司《配置项参考列表&配置库参考目录.xls》制定本项目配

置项列表。

2. 配置管理员与项目经理和项目主要成员确认项目配置项列表。

3. 配置管理员确认工作成果的内容，确定是否可以与现有配置项合并或者作为

新的配置项。

4. 配置管理员与项目经理确认，识别新的配置项。

5. 配置管理员识别出新配置项为基线类配置项或非基线类配置项。

 基线配置项参考列表

项目经理制定项目里程碑计划时，需要明确各里程碑产生的配置项。配置管理员

根据里程碑计划制定基线计划。基线配置项往往需要严格控制，并会对项目基线建立

产生影响。

基线配置项确定标准如下：

1. 重要的提交物。

2. 配置项易发生变化，需要进行版本控制。

3. 属于管理控制重点的配置项，如源代码。下表给出了基线配置项参考列表，

各项目可以根据实际情况确定相应的基线配置项。

表1 基线配置项参考列表

类型 配置项

项目管理计划

项目进度计划

项目周报

项目里程碑报告

评审报告/会议纪要

风险/重大问题跟踪表

项目管理

配置管理计划

基线建立控制报告

基线建立前检查Checklist

品质保证计划

项目路线图

项目总结报告

遗留问题跟踪表

提交工作产品清单

概要技术方案说明书

需求定义 需求说明书

需求规格说明书

技术研究报告

设计开发 设计说明书

数据库设计说明书

测试计划

测试用例

系统稳定 测试总结

功能/性能测试报告

发版说明

用户手册

产品化包装

培训资料

系统安装配置说明书

产品介绍PPT

配置项分类

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

基线类配置项

备注

类型 配置项

产品解决方案

产品实施指南

产品报价策略

技术白皮书

配置项分类

基线类配置项

基线类配置项

基线类配置项

基线类配置项

备注

 非基线配置项参考列表

项目非基线配置项区别于基线配置项，是指没有纳入基线计划的配置项。非基线

配置项一般不影响项目进展，不需要在基线建立时进行严格控制。下表给出了非基线

配置项参考列表，各项目可以根据项目实际情况确定相应的非基线配置项。

表2 非基线配置项参考列表

类型 配置项

项目立项报告、项目启动会

PPT等

配置管理相关文档

品质保证相关文档

项目汇报相关文档

项目管理

各种管理跟踪表

会议评审相关文档

培训相关文档

项目结项总结PPT等

电子邮件

…

调研准备

需求定义 调研资料

…

设计开发

源代码

其他设计类参考资料、文档

源代码、单元测试源代码

可执行文件

缺陷跟踪相关文档

维护记录相关文档

产品化包装

系统维护

……

用户培训资料、帮助等

系统维护相关文档

……

配置项分类

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

非基线类配置项

备注

系统稳定

在项目进展过程中，配置管理员需定期跟踪并维护项目配置项列表（体现在《配

置管理计划》中），需注意以下各项工作：

1. 配置管理员每周阅读项目周报、每月阅读项目月报，关注周报、月报中列出

的项目工作成果。

2. 配置管理员对照《配置管理计划》的配置项计划，识别出未纳入计划的配置

项清单。

3. 配置管理员就新配置项清单与项目经理和项目主要成员确认。

4. 将新识别的配置项清单更新到《配置管理计划》中（将新的基线配置项列入

基线配置项列表，将新的非基线配置项列入非基线配置项列表）。

5. 将新经过评审的基线配置项和正确的非基线配置项纳入配置库。

6. 基线配置项入库后如需修改请遵循变更流程。

4.6 配置项标识

标识的本质就是区分，在众多的配置项中合理、科学的命名是最好的区分方法。

所有配置项都应按照相关规定统一编号，按照相应的模板生成。

 配置项标识需要遵循以下原则：

1. 唯一性

2. 可追溯性

3. 与同类配置项不同的信息，应纳入标识：这是为了便于区分、查找

4. 同类配置项的标识方法统一

5. 容易记忆

 配置项标识需要遵循以下要求：

1. 所有纳入管理的配置项必须按照公司文档编码规范进行命名（不包含配置库

草稿目录下的草稿文件），配置项的命名要遵守“项目编号+项目名称+文档产品+可选

字段（主题/版本/人名/日期）”的命名原则，同时命名要求需体现在《配置管理计划》

中，详细内容请参见《文件编码及命名规范》。

2. 基线配置项必须符合文档规范，需使用公司最新发布的文档模板（若客户方

有特殊要求，需提前说明），各类最新项目文档模板可直接进入公司portal主页-规

章制度下获取。

3. 新建或修改基线配置项的文档内容时，必须同时填写相应的变更履历。

4.7 配置项入库管理

1. 配置项的存放目录应参考组织级配置库目录，由配置管理员在配置库中建立。

2. 配置项必须按照《配置管理计划》中配置库目录结构划分的要求纳入到正确

的目录中。

3. 配置项需及时、正确入库，配置管理员或项目经理/工作产品负责人根据项目

周报中的工作成果每周检查、并督促入库。

4. 配置项的首次入库时间不以基线建立时间为准，应以评审、定稿时间为准，

最多不得超过两周时间、并且必须在基线建立前；对配置项的修改或变更在评审、定

稿后同样应及时入库。

5. 配置项的正式发布必须在配置库的正式目录中，不得存放于工作草稿等目录

中。

6. 产品/项目进行过程中产生的各种需求、设计、测试、实施、评审、培训等以

及项目管理的最终文档、中间文档以及附带的图稿原件如时序图等，临时产生的各种

用于交流、讨论、备忘的记录、材料等，均应该完整、及时纳入配置库，由项目经理

负责检查落实，配置管理员定期督促。

7. 对于主要配置项，如需求规格说明书、项目管理计划等的变更，需要走“申

请-CCB审批-CM检出-变更-CCB审批-检入”的变更流程。

4.8 配置库目录结构规划

1. 公司所有项目配置库目录可参照组织级《配置项参考列表&配置库参考目录》

创建。

2. 整个配置库目录需要按《配置管理计划》中的配置库目录结构要求创建。

表3 配置项参考列表&配置库参考目录

一级目录

项目管理

二级目录

项目立项

三级目录

内容说明

项目立项申请、项目启动会PPT

（可选）、项目基本信息表等

项目计划

项目汇报

项目周报

其他报告

项目管理计划、项目进度计划

项目周报

项目里程碑报告、阶段性汇报

PPT（可选）等

管理跟踪 风险/重大问题跟踪表、项目备忘

大事记（可选）

配置管理 管理策略

基线建立

配置管理计划

基线建立控制报告、基线建立前

检查Checklist

变更管理 配置项变更控制报告（可选）、变

更控制重点监控配置项清单（可

选）、重点控制项变更检查表、产

品发布更新说明（产品型项目）

品质保证 管理策略

检查记录

品质保证计划

项目路线图、品质保证检查记录

（工作流程审计、工作产品检查、

工程规范检查）

会议评审 会议纪要、评审报告、会议签到

表（可选）、评审数据汇总表（可

选）等

培训 培训通知（可选）、培训材料（可

选）、培训签到表（可选）、培训

评估报告（可选）

电子邮件 与客户往来沟通确认的工作邮件

存档、项目组内部沟通确认的工

作邮件存档

项目结项 项目总结报告、项目结项总结会

PPT（可选）、提交工作产品清单、

可按事件

等建立子

目录

可按事件

等建立子

目录

可按主题

等建议子

目录

备注

一级目录 二级目录 三级目录 内容说明

遗留问题跟踪表

备注

其它

需求定义 需求调研

调研计划、调研提纲、调研报告&

访谈记录

需求草稿 从客户或其他途径获得的资料、

需求草稿

需求确认 产品可研论证报告（产品型）、产

品/项目愿景说明书、项目范围说

明书（普通）、需求说明书、需求

规格说明书、需求跟踪矩阵（可

选）

设计开发 设计草稿

设计确认

设计草稿文档

概要技术方案说明书、总体/模块

设计说明书、数据库设计说明书、

模块依赖关系表、技术研究报告

（可选）

系统稳定 管理策略

测试用例

测试计划

测试用例、测试点（可选）、性能

测试方案（可选）

测试报告 阶段测试总结（可选）、系统测试

报告、功能/性能测试报告（可

选）、用户验收测试报告（可选）

上线及试

运行

实施日志（普通）、实施配置报告

（普通）、问题跟踪一览表、项目

分工界面（可选）、项目验收备忘

录（普通）、用户验收证书（普通）

可选

版本发布 发版申请、发版计划、正式版产

品发布基线清单、产品发布更新

说明

产品化包用户文档 用户手册、帮助、系统安装配置

一级目录

装

二级目录 三级目录 内容说明

说明书、用户培训资料等

备注

产品包装 产品技术白皮书、产品解决方案、

产品宣传彩页、产品介绍PPT、

产品实施方案、产品咨询方案、

产品报价策略

系统维护 年度1 维护事件1

开发源代码

可选

年度2

源代码

4.9 制定基线计划

4.10 基线标识

1. 计划性基线：“项目编号-阶段标识 -YYYYMMDD”。

2. 事件性基线：“项目编号-阶段标识-事件英文缩写-YYYYMMDD”。

4.11 制定基线计划

基线分为计划性基线和事件性基线，计划性基线在《配置管理计划》中体现，事

件性基线由相关人员提出申请建立，不在《配置管理计划》中体现。

表4 基线参考列表

基线名称/标识符 包含的主要配置项

需求说明书

需求规格说明书

项目管理计划

产品定义基线：

项目编号-REQBaseline-YYYYMMDD

品质保证计划

配置管理计划

测试计划

风险/重大问题跟踪表

各种报告和跟踪表

概要技术方案说明书

产品设计与开发基线：

项目编号-DES+CODEBaseline- YYYYMMDD

总体/模块设计说明书

数据库设计说明书

测试用例

源代码

功能/性能测试报告

产品发版/稳定基线：

项目编号-RELEBaseline- YYYYMMDD

用户手册

培训资料

技术白皮书

发布版本

项目结项基线：

项目编号-ENDBaseline- YYYYMMDD

项目总结报告

提交工作产品清单

遗留问题跟踪表

建立时间

注：基线计划时间出现2周以上偏差或主要配置项变更时，需要走变更流程。

4.12 明确权限管理

4.13 用户管理

用户角色组主要有：配置管理员、CCB、项目经理、需求人员、设计人员、开发

人员、测试人员、实施人员、品质保证员等。各用户角色定义详见《配置管理规范》

9.1章节,对项目配置库中用户角色的管理，配置管理员需注意以下几点：

1. 项目配置库用户需要根据项目情况相应调整。

2. 一般情况下，项目配置库用户如需调整增加或删除，由项目经理提交邮件申

请，配置管理员收到邮件申请后，执行相应操作。特殊情况下，可由项目组成员提交

邮件申请，抄送项目经理及相关人员。

3. 配置管理员在收到邮件申请后，执行相应操作，并将用户分配到不同组里。

4. 配置管理员增加或删除用户后，需要邮件通知项目经理及相关人员。邮件通

知中需要附加配置库连接地址及简要操作说明。

4.14 制定访问控制策略

在建立配置库以前，项目经理需要给配置管理员提供明确的项目组各成员角色的

访问控制策略，配置管理员结合配置管理工具，衡量访问控制策略的合理性，与项目

经理确认后制定访问控制策略，并记录到《配置管理计划》中。

4.15 配置库资源与操作定义

不同角色用户对配置库操作主要有：

1. 项目配置库创建、维护、删除。

2. 项目成员及组的设置、维护。

3. 基线建立、维护。

4. 分支/合并。

5. 对文档、目录的读写访问。

6. 对源代码文件、源代码目录的读写访问等。由于不同配置管理工具对配置库

操作的控制粒度不同，在具体设置配置库操作权限时，需要结合配置管理工具的特性

进行设置。

表5 配置库操作列表

序号 资源 SVN操作定义

创建文件夹：Create Folder

删除文件夹：Delete

1 配置库 分支/建基线(打标签)：Branch/tag

合并：Merge

访问控制：设置用户组的权限

读(Read)：Checkout、Export、update

2 项目文件夹 写(Write)：Add、commit、Get/Release Lock、Rename、delete、

Copy to

读(Read)：Checkout、Export、update

3 项目文件 写(Write)：Add、commit、Get/Release Lock、Rename、delete、

Copy to

4 代码目录 读(Read)：Checkout、Export、update

写(Write)：Add、commit、Get/Release Lock、Rename、delete、

Copy to

4.16 角色划分策略

配置库角色主要有：配置管理员、项目经理、开发人员、测试人员、实施人员，

不同角色的职责不同。配置库授权控制参考列表如下：

表6 角色划分参考列表

序

号

配置

资源 配置库操作 管理

员

配置库创建、维护、

删除

1 配置库

用户及角色组的设

置、维护、授权控制

基线建立

分支/合并

2

文件/

文件夹

读写访问

读写访问

读写访问

完全

项目需求/设计测试CCB/实施/品

质保证人员 经理 /开发人员 人员

无 无 无 无

完全

完全

完全

完全

完全

完全

无

无

无

读写

读写

只读

无

无

无

读写

读写

只读

无

无

无

读写

无

读写

无

无

无

只读

无

只读

3 源代码

4 产品库

4.17 配置库操作权限参考

表7 配置库操作权限参考列表

编号

1

一级目录

项目管理

权限

项目经理、配置管理员可写，CCB、测试人员、QA人员

可读

项目经理、配置管理员、开发人员可写，CCB、测试人

员、QA人员可读

项目经理、配置管理员、开发人员可写，CCB、测试人

员、QA人员可读

项目经理、配置管理员、测试人员可写，CCB、开发人

员、QA人员可读

项目经理、配置管理员可写，CCB、开发人员、测试人

员、QA人员可读

项目经理、配置管理员可写，CCB、开发人员、测试人

员、QA人员可读

项目经理、配置管理员可写，CCB、开发人员、测试人

员、QA人员可读

项目经理、配置管理员、开发人员可写，CCB可读，测

试人员、QA人员无权限

说明

2 需求定义

3 设计开发

4 系统稳定

上线及试运

行

产品化包装

5

6

7 系统维护

8 源代码

4.18 明确分支版本策略

4.19 分支合并类型

在软件开发实践中，常常出现一些令人沮丧的事，如软件紧急更改提交集成失败、

发布错误版本、修复过的缺陷又莫名其妙地出现等等。主要的原因在于在实际开发中

没有应用软件配置管理或应用软件配置管理不当，选择并应用正确的分支模型，对避

免开发过程的混乱尤其重要。

常见的分支合并类型有以下几种：

 分支合并到分支；

 分支合并到主干；

 主干合并到分支。

1. 项目组根据项目情况不同，需事先约定所选择的合并类型，以便为后期可能

的分支合并做好准备，配置管理员将所选择的类型记录到《配置管理计划》中。

2. 分支合并前应临时去除相关分支所有人员的写权限，只保留被合并分支上合

并人员的读权限。

3. 应当尽量避免一个分支合并多次。当一个分支完成特定任务后，应及时合并。

4. 合并完成后分支应设置为只读，不再允许对该分支进行修改。

4.20 明确分支版本策略

选择正确的分支策略使版本正确发布、重构以前的版本或者重新回到以前的版本

等工作更加容易。采用分支模型使软件开发过程更加便捷、软件开发更加高效、软件

质量得到提高，并且可以减少软件开发中的错误和提高软件开发团队的整体效率。选

择适当的分支模型，应从以下几个方面考虑：

1. 支持连续不间断的集成，从而保持新开发过程的稳定的基准；

2. 提交应急版本（只包括所有必要的修复）进行测试和交付用户；

3. 包含有所有必要的修复而无其它更改的测试版本发布；

4. 使应急发布对新开发过程的影响最小化；

5. 根据项目需要，回退到以前的产品状态；

6. 支持多个共存版本，如不同平台或不同用户的备选版本。

关于代码管理的分支和发布策略，主要有两种模式：

1. 新功能开发在分支上进行，主干用于稳定版的发布。

2. 新功能开发在主干上进行，分支用于稳定版的发布。

4.21 主干稳定

当新功能开发在分支上进行、开发结束、功能测试通过时，将分支合并到主干修

订集成测试、系统测试所发现的BUG，在主干上进行发版；同时将分支设置为只读。

主干稳定策略与分支稳定策略刚好相反，主干上永远是稳定版本，可以随时发布。缺

陷修改和新功能的开发都在分支上进行，而且每个缺陷修改和新功能都有不同的开发

分支，是完全分离的，在分支上测试通过后才合并到主干，在主干上的每一次发布都

需要用标签标识。

优点：

1. 开发周期较灵活，各功能模块自主定义开发周期，每个分支的生命周期比较

短，唯一长期存在的就是主干，这样每次合并的风险比较小。

2. 每次发布的内容调整起来比较容易。

3. 如果某个新功能或缺陷修改在发布之前无法完成，就不会合并到主干，也不

会影响其他变更的发布。

缺点：

1. 如果某个开发分支因为功能比较复杂，或其他原因长期没有合并到主干，则

最后合并的时候很可能会出现冲突。为避免合并时产生冲突需要注意以下问题：

2. 如果有的分支确实因为特殊的需要必须长期存在，那就必须定期把主干的更

新往这个分支上合并。

3. 如果发布周期很长，各个发布分支之间还要定期的从前向后合并。

4. 测试在发布分支上进行，而发布在主干上进行，这就引入了合并出错的风险，

而主干上的程序是没有经过测试的。

4.22 分支稳定

当新功能开发在主干上进行、临近发布阶段时，从主干建立分支，在分支上修订

集成测试、系统测试所发现的BUG，在分支上进行发版；主干继续进行新功能开发。

版本发布完成后，将分支合并到主干，分支设置为只读。采用分支稳定策略情况下，

主分支中永远是最新的功能，当新功能开发到达某个里程碑后发布，从主干分支用于

该版本的缺陷修改及现有功能的完善。当稳定分支上的修改积累到一定程度就会进行

一次发布。

优点：

1. 这种发布方法非常适用于产品线的发布管理，以前的版本仍需要继续维护，

而新功能也不断地在增加。

2. 对于已经发布的产品，只有维护的补丁发布。而新发布的产品不仅包括了所

有的bug修改，还包括了新功能。

缺点：

1. 只能增加下一个发布里面计划集成进去的新特性，同时必须对主干上新功能

的增加进行控制，否则新版本的发布将出现严重延期。

2. 如果主干上的某个新功能，测试不通过，达不到里程碑的要求，新版本的发

布也会出现延期。

3. 缺陷修改必须在各个分支之间合并，各个长期存在的分支之间必须要周期性

的进行合并，否则很容易引发合并冲突。因此，采用这种分支策略可能碰到的最大问

题就是某个分支上的bug修改内容往其它分支merge的时候出现的冲突。而且一旦发

现一个bug，调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。

4.23 基于SVN的分支建立及合并方法

表8 SVN分支建立及合并方法参考列表

操作

新建分

支

SVN分支/合并操作 说明

1 Branch/tag（分支标方法一：当新建分支时，在工作副本右键点击

记） 要开分支的文件目录，选择“Branch/tag”功

能创建分支。

2 Copy to（复制到） 方法二：使用TSVN客户端浏览器，选择”Copy

to”功能将需要建立分支的文件夹”复制”到

branches目录下。

合并分

支

4.24 分支建立步骤

1. 由于SVN提供可以创建从主干向分支、分支向主干、分支向分支三种类型的

分支，首选需明确开分支的起始位置及结束位置。

2. 新建分支的操作方法有两种，如上表所属（表8），使用第一种方法需在工作

副本中进行，第二种方法通过SVN浏览器完成。

3. 选择分支文件所存放的目录路径，一般情况下，分支文件存放在branches目

录下，以上信息明确后即可开始创建分支。

4. 分支创建完成后，开发人员再次确定分支目录结构是否有需调整。

5. 分支创建完成后，配置管理员需明确配置库分支目录文件的权限分配策略，

明确相关人员角色并开放相关权限。

4.25 分支合并步骤

分支合并有三种常见类型：

1. 单分支合并

2. 多分支合并，且起始主干版本号相同

3. 多分支合并，且起始主干版本号不同

使用SVN进行合并操作时，提供了三种方法，区别是：

操作

1

SVN合并方法

合并一个版本范

围

合并

分支

3 合并两个不同的

树

 单分支合并

操作方法比较简单，同多分支合并操作步骤一中相同，参见多分支合并的步骤。

 多分支合并，且起始主干版本号相同（如下图）

2 复兴分支

特点说明

可任意选择分支的版本，主干不能选择版本，只能使

用最新版本。

无乱是主干和分支都不能任意选择版本，只能使用最

新版本。

无乱是主干和分支都可以任意选择版本，包括最新版

本。

Merge（合并） 选择所需要使用的合并类型进行合并。(合并步

骤参考本指南4.6.3.2章节)。

Trunk

Branch

分支A版本

101

新建分支A

经过N次修改

Branch

分支A版本

110

版本100

新建分支B

分支B版本

102

经过N次修改

分支B版本

115

合并到主干

合并到主干

合并需两步操作，并且操作在主干T 的工作副本内执行：

 主干T合并分支A

输入起始URL 和版本（如：主干T 的URL 、版本100）；

输入结束的URL 和版本（如：分支A的URL 、版本110）；

 合并分支A 后再继续合并分支B

输入起始URL 和版本（如：主干T 的URL 、版本100） ；

输入结束的URL 和版本 （如：分支B的URL 、版本115） ；

 多分支合并，且起始主干版本号不同（如下图）

Trunk

版本100

主干文件版本升级

Branch

新建分支A

Branch

经过N次修改

分支A版本

101

分支A版本

110

版本101

新建分支B

分支B版本

102

经过N次修改

分支B版本

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）；

输入结束的URL 和版本 （如：分支B的URL 、版本120）；

合并结束后，需将合并后的结果提交（commit）至服务器中。

5 个人工作空间管理

1. 为保证项目团队成员工作在统一的开发平台上，避免因个人工作空间不一致

导致程序错误，配置管理员需要在《配置管理计划》中约定项目团队的个人工作空间。

2. 配置管理员可以根据需要定期抽查项目成员的个人工作空间。

5.1 建立个人工作空间

1. 项目经理提醒开发人员根据个人工作空间要求准备开发环境。

2. 开发人员根据《配置管理计划》中规定的个人工作空间要求准备开发环境。

5.2 个人工作空间要求

开发人员在正常情况下的操作步骤应该是每天更新个人工作空间，获得最新版本

的代码，在此基础上再开始开发工作，个人工作空间要求如下：

1. 禁止使用有商业版权、未经授权的工具、软件或插件。

2. 个人工作空间目录应该尽可能的与服务器目录结构保持一致，禁止自行将多

个文档目录或工程代码合并到一个目录或工程之中进行工作。

3. 工作时如需锁定或Check out文件，在修改完成后应该马上解锁文件，禁止

长期锁定或

4. 当产品/项目处于前期开发阶段时，开发人员根据项目组要求应该每天至少向

配置库中提交一次代码、每天至少从配置库更新一次相关的代码到个人工作空间。

5. 开发人员向配置库提交代码前必须先在个人工作空间完成编译、构建、自测，

保证代码可编译通过、没有错误，从而确保配置库的变更不会导致代码集成失败。

6. 跟产品/项目无关的文件一律不允许检入配置库，如编译产生的文件、缓存缩

略图的文件、从VSS中检出的配置文件等。

7. 源代码必须及时提交到配置库，不允许长时间lock或check out代码而不执

行unlock或check in。lock或check out到unlock或check in的时间间隔不得超

过2个星期。

8. 对于开发人员，修复失败的构建是优先级最高的事情。

9. 代码修改过程中，为防止代码被别人修改而引发冲突，可以考虑锁定机制。

5.3 检查个人工作空间

1. 配置管理员可以制定个人工作空间检查计划，抽查项目组成员的个人工作空

间。

2. 配置管理员检查可以采取定期抽查的方式开展。

3. 检查个人工作空间的事项：

1) 目录结构是否一致、

2) 引用的第三方类库/组件是否符合统一的要求、

3) 是否有超出权限范围的代码，等等

6 基线管理

6.1 基线建立要求

配置管理员需要根据《配置管理计划》中制定的基线计划，跟踪项目进展，建立

基线。具体内容如下：

1. 根据基线计划时间点，在到达里程碑时间点时，配置管理员提醒项目经理需

要提交的主要配置项。

2. 配置管理员与项目经理沟通，参照《基线建立前检查Checklist》以及基线计

划对提交的配置项审查其完整性、正确性、一致性，并完成《基线建立前检查

Checklist》、《基线建立控制报告》，填写基线名称、版本、标识以及当前基线包含的

所有主要配置项等信息（如果前期已建立基线，当前基线的配置项需要包含上一次基

线的配置项）

3. 配置管理员检查《基线建立控制报告》中主要配置项的完整性，相关附件、

评审报告、会议纪要等是否已提交入库。

4. 检查通过后，执行打基线操作，并发送邮件通知项目组成员及其他干系人等，

需注意使用《配置管理计划》中规定的标签名。基线建立相关内容请参考《配置管理

规范》第10章节。

6.2 基线变更管理

对于周期较长的项目，如基线计划时间出现2周以上偏差时，需要走变更流程；

周期较短如一个月及以内的项目，如基线计划时间出现1周以上偏差时，需要走变更

流程。

1. 首先，项目经理、配置管理员、项目组成员等要对变更所引起的影响进行分

析，无问题后才可以申请此次变更。

2. 配置管理员填写《变更控制报告》相关内容，并发起评审，评审组成员主要

是CCB、项目经理等。

3. CCB评审并批准基线建立变更申请，如通过则执行下一步骤，如不通过则需进

行修改直至评审通过。

4. 项目经理协助配置管理员安排并执行本次变更，同时，配置管理员需调整《配

置管理计划》中有关基线计划的相关内容。

5. 配置管理员将调整后的计划重新安排评审，无问题后执行下一步骤，若未通

知，则需重新调整相关计划，直至评审通过。

6. 配置管理员将调整的文档及相关评审邮件或评审报告纳入配置库，同时发邮

件通知项目组成员。

项目组严格按照变更后的计划进行相关工作，配置管理员及时建立基线。有关变

更管理的流程，详见《配置管理规范》第14章节。

6.3 分支合并管理

分支合并是指将分支的修订合并到主干或者将主干的修订合并到分支。一般情况

下，主干被用来维护产品稳定、定期或不定期发布更新版本，分支被用来实现或试验

产品/项目影响范围较大或者实现周期较长的的新特性/功能。当分支上的新特性/功

能稳定后可进行分支合并操作。分支建立后应避免长时间的分支状态，应尽可能早的

完成合并。

6.4 分支合并流程

为了减少分支合并的风险和影响，合并过程应严格控制，合并前的准备工作可以

参考如下事项（以分支合并到主干为例）：

1. 项目经理制定、CCB评审分支合并方案，评估合并的风险和影响，指定合并负

责人，确定合并开始时间和结束时间。

2. 确保分支上所有文件均被正确、完整签入。

3. 通知并取消分支上所有人员的写权限，可保留读权限。

4. 尽可能保证主干上相关文件是最新的。

5. 开放合并负责人在主干上的写权限。

6. 合并之前在主干上打基线、标识合并前的状态，以防合并操作失败时能及时

回滚到合并前的状态、不影响主干的开发工作。

7. 合并之前在分支上打基线、标识该分支已开发结束或已发版。

8. 合并完成后在主干上打基线、标识合并后的状态。

9. 合并完成后安排测试，以确保合并没有问题。

6.5 分支合并方案制定

分支合并方案可以采用Word或Excel等形式，但一般情况下需要包含以下内容：

1. 确定所有发生了修订的功能模块和代码文件（这些是合并后测试的重点）。

2. 确定功能模块和代码文件的修订所影响的功能。

3. 确定合并方式：直接加入、手工合并、直接覆盖。

4. 确定合并负责人及合并开始时间和结束时间。

5. 确定合并后测试是完全合并后测试，或者部分功能合并完成后测试等。

6. 在合并方案中详细列出分支合并的流程及注意事项。

7. 合并方案中的修改功能模块、代码文件、影响功能、合并方式等可参考下表

列出。

表9 分支合并方案制定参考列表

功

序能

文件目录 文件名称 功能说明 影响功能

合并方

式

备注

号 模

块

srccomj

新

表

1 格

控

件

iuqiGrid

One

webjst

ableUtil

acrifri

nputdata

IfrWebDataPr

ocessor

继承于

WebDataProc

essor

修改了引入

errorPage.j

sp的路径

修改了显示

界面标题的

逻辑处理

加入了对合

并报表报表

分组的支持，

有界面参数

isIifr是否

等于1决定是

直接加

入

手工合

并

直接覆

盖

inputdata

2

数

2

据

录

入

chkresultpri

chooseFormul

功

序能

文件目录 文件名称 功能说明 影响功能

合并方

式

备注

号 模

块

否合并报表

模式

添加了一个

web/web-i

nf

支持合并报

表的

serverlet

8. 合并方案中合并负责人及合并开始时间和结束时间等可参考下表列出：

序号

1

合并功能模块 合并负责人 合并时间

10月8日- 10月9

日

10月8日- 10月9

日

3

4

计划任务

自定义录入

10月9日

10月9日

备注

公共代码、功能常量、表格组

件

2 单位多版本设置

注：分支合并方案评审通过后，由合并负责人在要求时间内根据分支合并流程执

行分支合并操作。

7 集成构建

7.1 代码集成

1. 当项目进入编码阶段后，不同开发人员在各自的个人工作空间下开始编码。

为保证代码集成目标的实现、避免不同开发人员提交到代码库的代码产生冲突，开发

人员需遵循《配置管理规范》中代码集成相关的约定。

2. 当项目进入稳定后期，项目可设立专门的代码集成人员（可由开发人员兼任）。

开发人员将修改文件及更新说明（明确注明修改文件名、路径、修改原因、提交人等

信息）发送给代码集成人员，代码集成人员根据《配置管理规范》中代码集成相关的

约定向代码库提交代码，并维护和发布代码更新说明。

3. 代码集成工作的重点在于掌握代码库的变动，只有严格记录开发人员的代码

集成过程，才能保证代码库的所有集成都是可控的。同时，测试人员根据这些集成记

录开展测试工作，从而保证项目版本的质量。

7.2 代码更新说明范围界定

1. 按更新内容不同，可以分为三类更新：新功能、功能改进、缺陷修改。

2. 新增功能是指需要新增数据库更新脚本的功能，一般需要首先完成需求规格

说明书、设计说明书，提交更新说明时需要注明需求来源并提交相关功能的需求规格

说明书、设计说明书入库。

3. 功能改进是指对现有功能的完善，提交更新说明时需要注明需求来源。

4. 缺陷修改是指对测试或实施提交缺陷的修改，一般只涉及较少量的代码修改，

提交更新说明时需要注明缺陷编号。

7.3 代码更新说明填写

当完成某个新增功能、功能改进或缺陷修改后，应填写代码更新说明。更新说明

填写字段说明如下：

字段

更新日期

更新类型

更新说明提交日期

三种类型的更新：新增功能、功能改进、缺陷修改

功能上更新内容，重点描述功能上的调整：

更新内容 如果是新增功能或功能改进，请简要描述新增功能。

如果是缺陷修改，请简要描述缺陷及修改后功能。

需求/缺陷编号

需求/缺陷描述

更新模块

更新功能

是否更新数据库

更新版本号

修改路径及文件

更新人

JIRA或问题跟踪表中的需求/缺陷编号

如果是新增功能或功能改进，请描述原始需求。

如果是缺陷修改，请描述缺陷产生原因及解决方法。

描述具体更新的模块。

描述具体更新的功能。

是否需要提交数据库更新脚本

注明更新到的版本号，例如更新到CI3.2：

当某个版本已提交测试时，需要注明更新文件路径并附上更新文

件。

更新说明提交人

说明

更新工作量（人时） 更新的累计人时

注：代码更新说明参考附件模板，可根据项目的需要自行增加或裁剪相关字段。

7.4 代码更新说明发布

代码集成人员维护代码更新说明后应及时发布更新说明，从而保证项目组成员如

测试人员及时获知、明确更新内容。根据项目不同情况，代码更新说明可使用Excel

表记录、纳入版本库管理或在Portal上设计表格进行登记，例如：CI、VA产品采用

portal列表的形式发布代码更新说明，参考下图。发布更新说明的方式在《配置管理

计划》中约定。

7.5 准备构建环境

公司提供通用构建管理平台用于公司所有产品、项目的自动构建。目前该平台系

统管理员为运营监管中心信息资产管理部、平台开发维护人员为软件研究院组件部。

项目经理可根据项目进展情况，联系平台系统管理员，在平台上增加项目的构建信息。

一般需要向平台系统管理员提供如下参考信息：

1. 特殊的配置要求，如JDK的版本

2. 构建脚本（Ant脚本或批处理脚本）

3. 构建代码访问路径

4. 构建账户信息

5. 配置管理员、集成构建人员

基于DNA开发的产品项目，产品项目经理可填写附件《DNA应用项目构建信息表

（项目标识）》。注：项目生命周期结束后，项目经理应及时告知平台系统管理员，删

除该项目的构建信息。

7.6 构建测试版本

代码集成人员完成集成工作后，通知构建人员构建测试版本。测试版本的构建可

根据测试人员的测试安排进行计划，可以采用每日构建或需要时构建等方式。配置管

理员与项目经理、测试人员沟通后在《配置管理计划》中约定构建测试版本的频率和

方式。

8 发布管理

根据产品项目的侧重点不同，发布管理的工作内容会有一定差异。通常情况下，

发布管理包含对内发布的测试版本、对外发布的正式版本和一些临时版本。测试版本

是指构建完成后仅用于内部测试验证、临时满足用户演示或售前交流等需要临时发布

的版本，是非正式的产品版本，使用对象包括内部测试人员或外部客户（协助测试）。

测试版本不能保证产品整体功能的正确性，是未经过功能测试、集成测试或性能测试

的版本，不得用于正式生产环境。正式版本是指经测试后、可发布给客户正式使用的

版本，一般包括程序包、更新脚本、用户文档等。临时版本是指为了满足用户少量个

性化需求或修复部分小缺陷而发布的版本，这种版本一般可以不经过集成测试，但应

经功能测试方可发布。无论是产品还是项目，应有专职的配置管理员。

8.1 正式版本发布

1. 测试人员对测试版本进行测试、验证。正式版本发布的基本标准：需求完成、

没有未关闭严重缺陷、包含的子项目全部测试通过、遗留缺陷不超过发现缺陷的50%

并经过确认。

2. 测试、验证通过后，测试负责人提交《测试报告》，且通知全产品项目组。

3. CCB和项目经理对《测试报告》进行确认、确定是否可以正式发布。

4. 《测试报告》经确认后，测试负责人完成《发版说明》并提交到配置库相关

目录中。

5. 配置管理员将经测试通过的版本按照《配置管理规范》中发布管理的要求进

行处理并提交到久其产品库（ad01服务器），比如正确命名（一般遵循“产品/项目编

号+正式版本号+内部版本号+八位数日期+随机号”的命名规则）、检查版权情况等。

6. 配置管理员按照《配置管理计划》中基线计划及《配置管理规范》中基线管

理的要求对配置库进行基线审计、建立及发布等工作。

7. 配置管理员采用电子邮件方式向全公司发送正式版本发布通知，并附带《发

版说明》。

8. 正式版本发布后，由配置管理员进行版本发布登记。

9. 一般情况下，产品在第一次正式发版后、会持续发布小版本或补丁版（可统

称为维护版本）。发布维护版本时应明确需求冻结点，到达冻结点原则上不接受新需

求，以保证维护版本能够顺利发布。

8.2 测试版本发布

测试版本的发布一般在编码结束后进行，其发布时间、方式、位置、流程、频率、

人员等应根据项目实际情况在《配置管理计划》中对具体细节进行规定。

1. 发布时间：一般首次发布均在编码结束、构建成功后，以后可以制定任务计

划执行自动构建如每日构建或者按照发布频率执行手动构建。

2. 发布方式：可通过久其通用构建平台构建出可测试的版本，一般不建议自行

开发构建平台。

3. 发布位置：一般只存储在构建服务器上，通过任务计划或手动方式定期进行

清理，不可存放到久其产品库中（ad01服务器上）。

4. 发布流程：手动构建时一般由配置管理员或指定的构建人员登录构建平台，

构建成功后通知测试人员取用构建版本进行测试；自动构建时，由指定的测试人员直

接到发布位置获取成功构建的版本进行测试。

5. 发布频率：可以规定为自动构建或按需手动构建。

6. 发布人员：一般为配置管理员或指定的构建人员。

7. 版本命名：一般遵循“yyyy-mm-dd（hh-mm-ss）”的命名规则。

8. 其他事项：项目经理应每天关注构建情况，优先解决构建中出现的问题。

8.3 临时版本发布

1. 临时版本申请人员提交申请及需求，并按照各产品项目的要求获得审批。

2. 开发人员根据审批的需求对代码进行修订、确保本地编译通过、提交代码集

成人员。

3. 代码集成人员将修订后的代码提交到代码库、通知构建人员。

4. 构建人员执行手动构建，得到可提交测试的版本。

5. 测试人员对测试版本进行功能测试、验证。

6. 测试、验证通过后，测试负责人提交《测试总结》（阶段性）。

7. CCB和项目经理对《测试总结》进行确认、确定是否可以发布到正式生产环境。

8. 《测试总结》经确认后，配置管理员将经测试通过的临时版本按照《配置管

理规范》中发布管理的要求进行处理并提交到久其产品库（ad01服务器），比如正确

命名（一般遵循“产品/项目编号+正式版本号+内部版本号+八位数日期+随机号+用户

方或者申请者姓名”的命名规则）、检查版权情况等。

9. 配置管理员采用电子邮件方式向临时版本申请人员发送临时版本发布通知。

10. 临时版本发布后，由配置管理员进行版本发布登记。

8.4 产品版本号编码

产品版本号可由三部分组成：大版本号、次版本号和小版本号，三部分之间以英

文半角的“.”隔开。产品版本号编码为：大版本号.次版本号. 小版本号。

说明：产品版本号第一部分即大版本号一般从1开始递增；第二、第三部分即次

版本号、小版本号是大于或等于 0 的整数。

版本号递增原则：

 当产品进行了局部修改或bug修正时，大版本号和次版本号都不变，小版本

号加1；

 当产品在原有的基础上增加了部分功能时，大版本号不变，次版本号加1，小

版本号复位为0；

 当产品进行了重大修改或局部修正累积较多、而导致产品整体发生全局变化

时，大版本号加1，次版本号和小版本号复位为0。

注：

1） 大版本号、次版本号和小版本号定义、规则和确定由各产品线、项目自行

确定。

2） 正式发布和临时发布的产品版本号应体现在发布的产品包中，以

版本文件记录或体现在可安装程序的“属性-版本”中。

3） 产品如需立项时，项目编号和项目名称中只保留大版本号和次版本号，即

产品一般不对小版本号的升级单独立项。

9 备份/还原管理

1. 配置库的备份/还原操作由组织级配置管理员负责执行操作。

2. 使用的配置管理工具不同，配置库的备份还原工作会有一定的差异。

3. 组织级配置管理员应详细记录执行备份或还原操作的具体步骤，形成独立的

文档。

4. 有关配置管理备份/还原的策略、要求和操作方式参见《配置管理规范》以及

《配置库备份还原指南》。

10 记录配置管理活动

1. 配置管理员应记录执行的配置管理活动，可体现在工作日志中，包括项目编

号、项目名称、配置管理活动内容、工作量。

2. 项目经理应将配置管理员的配置管理活动记录到项目周报中。

3. 配置管理员可对配置管理活动进行简单的分析，以提高配置管理工作质量和

工作效率。

11 参考及附录

参考1 《配置管理规范》

参考2 《配置项参考列表&配置库参考目录》

参考3 《配置库备份还原指南》