配置管理方案：提升软件生命周期管理的安全性与团队协作效率

1 概要

在软件开发过程中，配置管理扮演着至关重要的角色。一个健全的配置管理方案不仅能确保软件的安全性和稳定性，还能显著提升团队协作效率。本文将详细介绍如何通过软件配置管理获得可追溯性和可重现性这两种基本能力，进而提升软件整个生命周期的管理水平。

1.1 目的

可追溯性：

可追溯性是指能够准确追踪软件的每一次变更，确保任何人在获得授权的前提下，都能找到软件的任何变更历史。具体来说，对于任何一次软件变更，我们都能准确地回答5W1H，即：

• 谁（Who）：谁执行了这次变更？

• 什么时间（When）：变更发生在什么时间？

• 做了什么（What）：变更的具体内容是什么？

• 为什么（Why）：为什么要进行这次变更？

• 如何做的（How）：变更是如何实施的？

可追溯性不仅有助于信息安全管理，还能在出现问题时迅速定位原因，减少故障排查时间。

可重现性：

可重现性是指能够重现从过去到现在之间任意时间点的软件状态。这意味着，任何人在获得授权的前提下，都能通过配置管理系统恢复到过去的某个软件版本，或者基于某个版本进行新的开发。可重现性不仅是信息安全管理的重要支撑，更是各角色提升协作效率的关键手段。它确保了团队成员之间的无缝衔接，避免了因版本不一致而导致的沟通障碍和工作重复。

1.2 范围

本流程适用于公司各类软件项目，包括但不限于大型复杂系统、小型应用程序等。根据项目特性和规模，本流程可灵活裁剪以适应不同需求。

1.3 术语和缩略语

术语/缩略语	英文	描述
软件配置管理	Software Configuration Management, SCM	SCM是一种技术和管理手段，用于标识、组织和控制软件及其开发过程中的变更，确保软件产品的演化过程被准确记录，并在整个生命周期中提供精确的产品配置。
配置	Configuration	配置是指构成软件产品功能或物理属性的所有明确说明的要素，包括但不限于产品特性、相关文档、软件版本、变更记录、运行支持数据等。与硬件配置相比，软件配置包含更多内容且更具易变性。
配置项	Configuration Item, CI	CI是指纳入配置管理范畴的任何工作成果，它们是软件系统的组成部分，可单独进行设计、实施和测试。纯软件的CI称为软件配置项（Computer Software Configuration Items, CSCIs）。CI包括产品需求文档、设计文档、源代码、测试用例以及项目管理文档等。
基线	Baseline	基线是CI或一组CI在特定时间点上通过正式评审后进入的一种稳定状态，标志着这些配置项达到了一个相对稳定的版本，并成为后续开发的基础和参考点。基线具有名称、标识符、版本和日期等属性，且其内的配置项被严格控制，不允许随意修改，除非遵循严格的变更控制流程。基线分为Release（面向客户交付）和Build（内部开发使用）两种类型。

2 组织与人员

角色	职责	权利
项目经理（PM）	与配置控制委员会（CCB）紧密合作，共同确定项目的起始基线和关键开发里程碑； 全面接受并推动执行项目配置管理计划，确保其有效实施； 定期审阅配置控制委员会（CCB）提交的报告，以了解配置管理状态并做出相应决策。	有权提出对配置管理计划的修改建议，以适应项目变化需求。 可就配置管理的优化和改进提出建议，促进项目管理效率提升。
配置控制委员会（CCB）	制定和定期审查项目配置管理策略，确保其符合项目目标和组织标准。	审批并发布项目配置管理计划，确保其权威性和有效性。 负责基线的设立、更改及审核所有变更请求，确保变更过程受控且符合规范。 基于配置管理员（CMO）的报告，决定并采取必要的应对措施，以维护项目配置的稳定性和一致性。
配置管理员（ CMO）	编制详尽的配置管理计划，明确各项管理流程和责任分工。 执行配置项管理方案，确保所有配置项得到正确标识、存储和追踪。 实施版本控制和变更控制策略，管理配置项的版本演进和变更历史。 定期编制配置状态报告，向CCB和相关利益方通报配置管理情况。	有权向CCB报告配置管理流程中的任何不符合项或问题，提出改进建议。
程序库管理员（PL）	负责配置库的建立和维护，包括物理和逻辑结构的设计、权限分配等。 管理配置管理工具的日常运行，确保其稳定性和可用性。 执行配置库的日常操作，包括备份、恢复、审计等，保障配置项的安全和完整。	负责配置项在库中的管理和维护，确保配置项的正确性和时效性。 有权对开发人员进行配置管理工具使用的培训和指导。
开发人员（Developer）	遵循配置管理计划和相关规定，及时提交配置项和基线供审核和入库。 负责软件集成工作，确保各模块或组件能够顺利集成并生成正确的版本。	有权按照软件配置管理工具的使用规范完成开发任务，确保开发过程的高效和准确。
测试人员（Tester）	根据配置管理计划和相关要求，提交测试配置项和测试基线，确保测试环境的准确性和一致性。	负责对软件变更进行严格的测试验证，确保变更的正确性和稳定性。
质量保证员（ QA）	负责对配置管理流程进行独立审核，确保所有活动均符合既定规范和标准。 提交审核报告，指出存在的问题和改进建议。	有权要求相关责任人纠正配置审核中发现的不符合项，确保配置管理的有效性和合规性。

3 实施细则

序号	工作内容	工作产品	执行人员	辅助人员
1	识别项目配置项	配置计划	CMO	PM
2	定义基线	配置计划	CMO、PM
3	制定与审核配置计划	配置计划	CMO、PM	PM、QA
4	建立配置库	配置库	CMO	PM
5	配置库的使用	配置库	项目组成员	CMO
6	变更控制	变更申请表、基线报告、变更跟踪表	变更申请人	CCB
7	配置状态及报告	基线报告	CMO	QA
8	配置审查	项目周进度表	QA	CMO
9	产品内部验收发布	项目质量报表 版本发布申请表	CMO、PM	QA、BI

3.1 CCB的成立与运作

3.1.1 成立时机

项目进入设计阶段并明确开发需求后（需求评审通过），项目经理应立即组织成立配置控制委员会（CCB）。

3.1.2 成员构成

CCB成员应确保涵盖项目关键角色，成员数量保持奇数，通常在3至7人之间，具体包括：

• 项目经理（PM）

• 客户代表（产品）

• 主要开发人员代表

• 测试负责人

• 配置管理员（CMO）

• 质量保证员（QA）

3.1.3 决策机制

CCB决策应基于成员间的充分讨论和共识。在无法达成一致意见时，优先考虑顾客代表的意见；若仍无法决定，则采取多数票决原则，投票结果超过半数即为通过。

3.2 识别配置项

CCB成立后，应尽快组织会议，结合项目开发计划，明确各阶段里程碑和开发策略。CMO负责整理并确定项目基线和配置项列表，作为《配置管理计划》编制的基础。

3.2.1配置项范围

配置项应全面覆盖项目生命周期中的各类重要元素，包括但不限于：

• 技术文档：

里程碑节点	交付件	描述
需求调研	需求调研文档	需求调研后的总结文档
方案设计	产品设计方案	产品设计方案：干系人拉齐系统共识，确定系统建设目标，范围；根据方案给客户报价及建设周期
项目立项	项目可行性分析文档
	项目立项文档
需求分析	需求范围
	界面原型	客户评审过的原型文档
	UI设计图	客户评审过的设计文档
	需求规格说明书
系统研发	项目开发计划
	架构设计文档	系统涉及的技术论证及需要遵循的规则
	数据库设计文档
	接口文档
系统测试	测试计划
	测试用例
	质量报告
系统发布	客户验收表
	项目发布申请表
培训实施	用户手册
	培训实施文档

• 程序代码：包括源代码、中间产物、最终发布产品（安装包）等。

基础操作系统

Ubuntu 18.04 LTS

标准软件

mysql5.6，redis6.x，jdk8，Node.js，nginx，Git，Gradle，gitlib，jenkins，sonarqube，docker，harbor，ansible，Nacos，Zuul，Eureka

应用层

Spring Boot，Spring Cloud

• 过程类：工作日志、周计划小结、会议纪要等。

• 参考资料：业务资料、标准等。

3.3 制定配置管理计划

《配置管理计划》的编制工作通常由CMO在项目设计阶段开始后进行，但也可以根据项目合同或特定需求，在项目或项目阶段的初期即开始编制。

3.3.1 计划内容

《配置管理计划》应详尽阐述以下内容：

• 项目对配置管理的具体要求。

• 配置管理活动的责任人、组织结构及其职责划分。

• 计划执行的具体配置管理活动及其时间安排。

• 拟采用的方法、工具和流程。

• 基线管理策略，包括基线设立、变更控制流程等。

3.3.2 审批流程

《配置管理计划》编制完成后，需提交给CCB进行审批。CCB应仔细审查计划的合理性和可行性，确保其符合项目需求和组织标准。审批通过后，计划正式生效，作为项目配置管理工作的指导文件。

3.4 标识配置项

• 标识开发过程中纳入配置管理的配置项，为每个配置项指定唯一的标识号。具体参看附录A：标识规则。

• 对已形成基线的配置项做修改后，在纳入基线前，配置工程师应重新给予标识。

3.5 定义基线

1. 基线是一组经过正式评审并且达成一致的工作产品，且已经分配了唯一标识号，是后续工作的基础。对基线的更改必须遵循变更控制。

2. 建立基线的三大原因是：重现性、可追踪性和报告。

3. 基线分成两类：

• 产品基线：作为一个产品发布。

• 里程碑基线：开发过程中重要阶段工作成果。主要里程碑基线（也可以按迭代建立）建立时机如下：

（1）计划基线：项目立项后建立。

（2）需求基线（包括业务需求和软件需求）：需求交底后建立。

（3）设计基线（包括概要设计和详细设计）：设计经过评审后建立。

（4）系统测试基线：系统测试通过建立基线。

（6）产品基线：产品验收通过。

4.配置工程师和开发组长根据实际情况选择基线包含的配置项，配置工程师定义项目基线报告。

3.6 建立配置库（共享唯一受信源）

3.6.1 配置库分类

配置库被明确划分为两类，以支持不同类型资源的有效管理：

1. 需求仓库：保存有关产品的所有版本需求描述和验收条件，并且能够记录每一次团队对需求达成共识后的版本变更记录。

2. 文档库（Document Library）：由配置管理员（CMO）负责管理，利用GIT系统集中存储和管理除程序代码外的所有文档资料，包括设计文档、测试报告、用户手册及图片等，对于界面原型及设计文件便于研发查看，由配置管理员（CMO）从git上下载下来上传到蓝湖配置库。

3. 程序库（Program Library）：由PM负责，采用GIT版本控制系统对程序代码进行版本管理和控制，确保代码的安全性和可追溯性。（将数据库scheme纳入版本控制）

4. 软件包仓库：自动保存部署流水线生产加工出来的软件包，满足后续环节的快速取用。根据其中不同内容的使用方式，可以分成3个子类型，分别是临时产物仓库、正式发布包仓库和外部软件私服仓库。

3.6.2 配置库建立

CCB成立后，PM应立即着手组织建立配置库，确保所有项目配置项均有统一、安全的管理环境。PM对基线文档库拥有完全操作权限，其他成员需通过CMO授权访问。

3.6.2.1 文档库

文档库的结构与权限 详见附表B：文档库的结构和权限表，并为每个操作员分配权限。

3.6.2.2 程序库

程序库的结构与权限 详见分支管理规范：程序库的结构和权限表，并为每个操作员分配权限。

3.6.2.3 版本迁移与基线管理

CMO需根据项目开发阶段定制版本选取规则，确保开发活动的顺利进行。在变更发生时，及时推进基线，保证项目的稳定性和可追溯性。

3.6.3 权限分配

PM,CMO负责为每个项目成员分配配置库操作权限，确保权限分配合理且符合项目需求。一般情况下，项目成员拥有添加、检出/检入、下载等权限，但无删除权限。PM/CMO拥有最高权限，负责整体权限管理和监督。

3.7 配置变更控制

3.7.1 变更提出

• 外部：来自项目客户提交需求变更，必须以书面形式提交，填写《变更申请表》，写明变更的原因，变更内容和要求。业务负责接收顾客发出的变更申请。并与客户沟通清楚变更内容，其它部门任何人员接到客户的变更通知时，须转业务助理，进行处理。

• 内部：来自公司内的或项目组的变更，以及项目组成员都有权利提出变更意见。包括软件需求的变更、设计变更、代码变更、测试变更：须填写《配置项变更表》。

3.7.2 变更评估

将《变更申请表》、《配置项变更表》发送给项目经理（或者其他授权人员），由项目经理负责对变更进行评估。变更评估要分析每个变更对系统功能、接口、成本、进度以及约定需求的影响和对软件安全性、可靠性、可维护性、可移植性和性能的影响。

变更评估产生的文档应描述若实施变更必须变更的配置项、文档和资源；变更评估文档在完成变更评估后发送给CMO。CMO收到评估后的《变更申请表》或《配置项变更表》后，更新《变更日志》。

3.7.4 变更审核

CCB对提交的变更申请进行审核，并根据变更评估确定变更的影响级别；审核可能的结果有三种：接受变更、拒绝变更、需要进一步分析变更信息。

批准的变更，由PM指定开发人员进行下一步的实施变更工作；对于拒绝的变更，将拒绝变更的原因发送给发起者，并保存《变更申请表》或《配置项变更表》，更新变更记录，关闭变更活动；需要进一步分析变更信息，由评估分析人员进一步分析。

CMO负责整理会议记录，填写《变更申请表》或《配置项变更表》中相应审核项；更新变更记录，如果是接受变更，还需将要变更的配置项状态改为修改中；将变更文档分发给相关人员。

类型	业务内容	提出人	审核（或讨论）	批准人	知会	记录表单
外部变更	变更对成本、进度没影响，项目组内部可协调解决	客户	开发责任人 需求分析师 测试工程师	项目经理	项目组相关人员,CMO,QA、客户	《变更申请表》 《变更日志》
	变更影响产品发布日期7天及以下，成本可控（参考值：5人/天）	客户	CCB	技术研发中心经理 CCB	项目组相关人员,CMO,QA、 技术研发中心经理、客户	《变更申请表》 《变更日志》
	变更影响产品发布日期7天以上或成本不可控	客户	CCB	技术研发中心经理 公司领导	项目组相关人员,CMO,QA、产品经理、 质量经理、技术研发中心经理、公司领导、客户	《变更申请表》 《变更日志》
内部变更	文档变更，内部业务缺陷变更等，变更对成本、进度没影响，项目组内部可协调解决	变更提出者	开发责任人 需求分析师 测试工程师	项目经理	项目组相关人员,CMO,QA	《变更日志》
	项目组内部无法协调解决，发布超期或成本不可控或方案不可控	变更提出者	CCB	技术研发中心经理	项目组相关人员,CMO,QA、 技术研发中心经理	《配置项变更表》 《变更日志》

3.7.4 变更实施

变更被批准后，PM负责安排实施变更负责人，由变更负责人开始实施变更的内容；项目管理部门要对变更的实施进行跟踪。

对于开发计划、配置管理计划发生变更的，项目组人员要按照变更过的开发计划、配置管理计划提交配置项。

3.7.5 变更确认

变更后的程序提交后必需经过测试组进行回归测试，以确保变更没有引入新bug，不会引起程序变更的文档（如计划性文档则不需经过测试）。通过测试，QA需对变更进行审核，审核的范围一般涉及以下方面：

• 测试记录；

• 变更日志；

• 文件的命名；

• 版本的编号。

QA审核后，开发人员才能生成新的版本，由PM通知CMO更新到基线库中。应该重新标识所有被影响的配置项及版本。生成新版本后，修改变更状态为"正式发布"，关闭变更。

3.8 配置状态报告

1. 形成基线时，CMO填写基线报告，内容包括：配置项名称、版本号、完成时间、批准人等。

2. 基线变更时，CMO填写根据PM提交的软件开发变更单和小型变更跟踪表，在整个变更过程中，跟踪变更请求的状态，基线变更情况记录在基线报告中。

3. CMO及时将基线报告发布给项目相关人员。

4. 每周CMO汇总各项目配置基线变更状态及配置计划执行规范性情况。

3.9 配置审核

3.9.1 配置审核的类别

• 功能配置审核（FCA）：审核软件功能是否与需求一致，并符合基线文档要求；通常包括流程、报告和设计文档等。

• 物理配置审核（PCA）：审核要交付的组成项是否存在，是否包含所有必需的项目，如代码、资源、文档、安装说明等等。

3.9.2 配置审核执行的时机

• 软件产品交付或是软件产品正式发行前；

• 软件开发阶段工作结束后；

• 在产品维护工作中，定期地进行。

3.9.3 不符合项管理的闭环与跟踪

对配置审核中发现的不合格现象，CMO进行记录，并填写《不合格项报告》，交由相关部门限期进行纠正，直到不合格项得到合格纠正后，才能发布新版本。

审查要点如下：

• 审查基线的完整性。

• 检查配置记录是否正确反映了配置项的配置情况。

• 审查配置管理系统中配置项的结构完整性。

• 审查配置管理系统中配置项的完备性和正确性，以配置计划中说明的需求和所批准的变更请求的处置为基础来衡量。

• 验证是否符合适用的配置管理规程。

• 对审查后提出的各项行动进行跟踪，直到结束。

附录A：标识规则

1 标识项

配置项标识属性包括：名称、编号、版本、作者、日期等。

2 版本号约定

目前采用GNU 风格的版本号命名格式 :

主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]，字母表示：V<A>.<B>.<C>.<D>

示例 : 1.2.1, 2.0, 5.0.0 build-13124

外部发布用V<A>.<B>.<C>，<D> 只用做内部编译

编码	说明	升级情况（条件）
<A>	两位整数，代表发布主版本号，一般从1开始编号；当为一位数时，如V1.0	市场或客户需要。 开发平台、体系结构作变更。 产品功能50％以上作调整。
<B>	两位整数，一般从0开始编号，代表发布的次版本号。如V1.0	市场或客户需要。 产品功能50％以下作调整（工作量较大50人天以上）。
<C>	两位整数，一般从0开始依次递增，代表每次修改后发布的版本号；如V3.2.17表示3.2版的第17次升级。	产品日常维护需要。 产品错误修改。 功能优化、功能增加（工作量较小50人天以下）。
<D>	三位整数，一般从1开始依次递增，代表每次编译的版本号；如V3.2.17.1表示3.2.17版的第1次编译。	编译器在编译过程中自动生成

3 配置项命名约定

说明：对于下表中不存在的文档名称可由PM命名，但需提交品管部认可。

• 技术类文档：项目名称_文件名称_版本号，如周报系统_详细设计说明书_V1.0.001。

• 评审类表单：某个审核对象_表单名称_提交时间(yymmdd)，如详细设计说明书_评审报告_050525。

• 过程类标识规则: 表单名称+提交时间(yymmdd) 如：不符合提醒与处理单050425。如果是EXCLE表，且每周更新，不用加提交时间，如项目周计划小结、风险管理表、度量汇总表。

• 会议纪要：项目例会（主题1、主题2）20051213，会议纪要（主题1、主题2）20051213，括号中主题的字数控制在6个字以内。

• 源代码标识规则: 按编码规范执行。

• 安装包标识规则：子系统名称_版本号，如计划模块V1.0

• 封版产品标识：产品名称_发布版本号_发布时间(yymmdd)。如周报系统_V1.0_050525。

附录B：文档库的结构和权限表

一级目录	二级目录	存放内容	入库阶段	权限
01预立项类		合同、立项报告、投标文件、可行性分析报告、评审记录、会议纪要、方案设计文档、调研报告	立项阶段	产品经理有RCA权限，其他所有成员都有R权限
02文档类	01需求	需求规格说明书、界面原型、UI设计图、评审记录	需求阶段	所有成员都有RCA
	02 规划	项目详细计划、配置计划、质量计划等各阶段计划	策划阶段	所有成员都有RCA
	03 设计	架构设计、概要设计说明书、数据库结构设计、评审记录等	设计阶段	所有成员都有R，设计人员有RCA
	04 测试	测试计划、测试用例、测试报告、测试数据、评审报告等	测试阶段	所有成员都有RCA
	05产品化	用户手册、帮助、产品介绍、演示动画、技术手册、培训手册、培训PPT等各类产品化资料、评审报告	实时	所有成员都有RCA
	06沟通与交流	会议纪要、项目周计划小结、项目成立文件等	实时	所有成员都有RCA
	07QA活动	度量表、不符合提醒与处理单、软件开发变更单、配置库权限控制表	实时	所有成员都有RCA
03代码类	01源代码	源代码、README、关键代码审核记录	编码阶段	设计人员R，相应系统或模块编码工程师具有RCA
	02安装包	安装程序、数据库脚本、安装文件清单	测试阶段	所有成员都有RCA
	03目标代码	目标代码、集成部件		所有成员都有RCA
04参考类	具体可按类型分	指南和规范、外来文档等等	实时	所有成员都有RCA

1. 分别用R、C、D、A来表示SCMS中的四级权限读，写，删除，创建子目录。

   1. 读（R）：允许查看文件

   2. 写（C）：可以使用Check Out，Check In，撤消 Check Out等修改文件内容

   3. 删除（D）：可以在项目中增加、删除、重命名文件或者给文件设置标签

   4. 创建子目录（A）：具有创建子目录的操作。

2. 所有配置项电子版本需要与纸质保持一致，如技术文档的封面的撰写人、撰写日期等要写完整，评审报告的确认、验证等栏目要写完整。