研发配置与基线管理要落地，可以按“识别受控资产—搭建配置库—建立基线—控制变更—审计检查”的顺序推进。本文聚焦研发过程中需要受控的资产组合，给出每一步的做法、角色分工和记录模板，并说明需求版本演进、交付制品管理分别由相邻主题承接。ONES可作为承载配置项登记、基线冻结与变更记录的研发管理工具之一。
要点总览（TL;DR）
- 先按“多人修改、影响交付、需要回溯”三条标准识别配置项，产出带负责人和受控级别的配置项清单，并由项目经理审批生效。
- 配置库按“项目或产品—资产类型—配置项”三层组织，命名区分草稿、评审中、已基线三种状态，权限按资产负责人、配置管理员、其他成员划分。
- 基线按需求、设计、测试、发布四类设置建立时点，冻结前需配置项登记完整、评审通过、状态更新，审批后分配唯一基线标识供后续引用。
- 基线内配置项修改须走“申请—评审—实施—基线更新—关闭”流程，变更单与基线版本号对应，旧基线保留可查。
- 用配置项清单完整性、基线审批留痕、变更与基线版本一致、审计问题闭环四项做验收，重点补清单过期、基线无审批、变更未回写三类缺口。
先划清受控范围：哪些研发资产要纳入配置管理
配置管理的第一步是确定受控对象。判断标准是：该资产是否会被多人修改、是否影响版本交付、是否需要回溯历史状态。满足其中两条以上，通常应纳入配置项管理。普通文档如会议纪要、临时草稿、个人笔记，修改后不影响交付物一致性，可以不纳入。
配置项与普通文档的区别在于受控方式：配置项有唯一标识、有明确负责人、有版本记录、变更需要走流程；普通文档按日常协作方式管理即可。识别时按资产类型逐类梳理，避免遗漏。
| 资产类别 | 典型配置项 | 受控级别建议 |
|---|---|---|
| 需求资产 | 需求规格说明、需求跟踪矩阵 | 高，纳入需求基线 |
| 设计资产 | 架构设计、接口定义、数据库设计 | 高，纳入设计基线 |
| 代码资产 | 源代码、分支策略文件、代码评审记录 | 高，随发布基线冻结 |
| 测试资产 | 测试计划、测试用例、测试报告 | 中高，随发布基线冻结 |
| 构建与部署脚本 | 构建配置、部署脚本、环境配置说明 | 高，与代码同库管理 |
| 过程记录 | 评审记录、变更记录、问题清单 | 中，按项目归档 |
需要划清边界的两类内容：需求版本演进与需求变更流程归需求变更与版本管理主题处理；交付制品的打包、分发与制品库管理归研发交付物与制品管理主题处理。本文只处理这些资产作为配置项被登记、冻结和变更控制的部分。
识别完成后产出一份配置项清单，字段至少包括：配置项名称、类型、负责人、存储位置、受控级别、关联基线。清单由配置管理员汇总，各资产负责人确认，项目经理审批后生效。清单不是一次性的，项目阶段切换或资产新增时应更新。
搭配置库：目录结构、命名与访问权限怎么定
配置库解决“资产放在哪、怎么找到、谁能改”的问题。推荐按“项目或产品—资产类型—配置项”三层组织目录，项目层区分在研版本与已发布版本，资产类型层与配置项清单的分类保持一致，便于对照检查。
目录结构示例：
产品A/
版本V1.2/
需求/
设计/
代码/
测试/
构建部署/
过程记录/
版本V1.1-已发布/
命名规则要覆盖文件与目录两层。建议采用“配置项类型缩写-项目代号-版本号-日期”的格式，例如“REQ-A-V1.2-20240610”。版本标识区分草稿、评审中、已基线三种状态，状态变化时更新标识，避免用同一文件名反复覆盖。
权限按角色划分：资产负责人对本人负责的配置项有读写权限；配置管理员有目录维护和基线冻结权限；其他成员默认只读，需要修改时提交变更申请。提交规范包括提交说明必填、关联变更单号、禁止直接覆盖已基线文件。
配置库与代码仓库、文档库的衔接方式是：代码仓库作为代码类配置项的实际存储，配置库中登记仓库地址、分支与标签对应关系；文档库承载需求、设计等文档类配置项，配置库记录文档链接与版本号。配置库本身承担索引和状态记录职责，不要求把所有文件物理集中到一处。
定基线：基线类型、建立时点与审批怎么做
基线是一组配置项在特定时点被冻结的状态，后续修改必须走变更流程。常见基线类型与建立时点如下：
| 基线类型 | 建立时点 | 冻结范围 | 审批角色 |
|---|---|---|---|
| 需求基线 | 需求评审通过后 | 需求规格、跟踪矩阵 | 项目经理、需求负责人 |
| 设计基线 | 设计评审通过后 | 架构、接口、数据库设计 | 技术负责人、项目经理 |
| 测试基线 | 测试用例评审通过后 | 测试计划、测试用例 | 测试负责人 |
| 发布基线 | 版本发布前 | 代码标签、构建脚本、测试报告、发布说明 | 项目经理、配置管理员 |
建立基线的前置条件有三项：冻结范围内的配置项已全部登记且负责人确认；相关评审已通过并有记录；配置项状态标识已更新为“待基线”。三项齐备后，配置管理员发起基线建立申请，审批人核对冻结范围与评审记录，确认无误后批准。
审批记录采用基线清单加审批记录表的形式。基线清单列出基线名称、类型、包含的配置项及版本号、建立日期、审批人；审批记录表记录申请时间、审批意见、批准时间。基线建立后分配唯一基线标识，例如“BL-产品A-V1.2-发布”，后续变更申请、测试报告、发布说明均引用该标识，形成引用链。
控变更：基线变更的申请、评审与状态记录
基线冻结后，任何对基线内配置项的修改都要先申请。变更申请要素包括：变更内容描述、影响的配置项及当前版本、变更理由、提出人与提出时间、期望完成时间。申请提交给配置管理员登记，分配变更单号。
评审由变更评审人组织，评审角色根据影响范围确定：影响需求的变更需需求负责人参与，影响接口的变更需技术负责人参与，影响发布范围的变更需项目经理参与。评审结论分为三类：批准、有条件批准（附补充条件）、驳回。结论与理由写入评审记录。
变更实施时，资产负责人在配置库中修改对应配置项，更新版本标识，并在变更单中回写实际修改内容与完成时间。基线更新动作由配置管理员执行：将变更后的配置项版本纳入基线，生成新的基线版本号，旧基线保留可查。变更状态记录覆盖“申请—评审—实施—基线更新—关闭”全过程，每个状态变更记录操作人与时间，形成可追溯链。
变更申请与评审记录模板字段：变更单号、关联基线标识、变更内容、影响配置项、变更理由、评审人、评审结论、实施人、完成时间、基线更新版本、关闭状态。
角色与交付物分工表
配置管理能否持续运行，取决于角色职责是否清晰。以下分工表按环节列出各角色的动作与交付物。
| 角色 | 识别环节 | 建库环节 | 建基线环节 | 变更环节 | 审计环节 |
|---|---|---|---|---|---|
| 配置管理员 | 汇总配置项清单 | 维护目录结构与命名规范 | 发起基线建立、执行冻结 | 登记变更单、更新基线 | 组织配置审计、出具报告 |
| 资产负责人 | 确认本人负责的配置项 | 按规范提交与命名 | 确认冻结范围内容完整 | 实施变更、回写记录 | 配合核对资产状态 |
| 变更评审人 | — | — | 参与基线审批 | 评审变更、给出结论 | 复核变更闭环情况 |
| 项目经理 | 审批配置项清单 | 确认权限规则 | 批准基线建立 | 审批影响范围的变更 | 审阅审计报告、推动问题闭环 |
交付物归属与更新频率：配置项清单由配置管理员维护，项目阶段切换时更新；配置库目录与命名规范在项目启动时确定，调整时版本化；基线清单与审批记录在每次基线建立时新增；变更记录随变更实时更新；配置审计报告按季度或版本节点出具。各交付物存放在配置库“过程记录”目录下，与对应基线标识关联。
走一遍示例：一个版本从配置项到基线的完整过程
以下为演示情景，用于说明流程如何串联，不代表真实项目数据。
某产品团队启动V1.2版本开发。配置管理员组织识别，产出配置项清单共42项，覆盖需求规格、接口设计、源代码模块、测试用例、构建脚本五类，每项指定负责人。项目经理审批后清单生效。
配置管理员按“产品A/版本V1.2/资产类型”建立目录，发布命名规范，设置权限：资产负责人可写本人目录，其他成员只读。代码类配置项在配置库登记仓库地址与分支对应关系，文档类配置项记录文档链接。
需求评审通过后，配置管理员发起需求基线建立申请，冻结需求规格与跟踪矩阵共8项，项目经理与需求负责人审批，分配基线标识“BL-A-V1.2-需求”。设计评审通过后以同样方式建立设计基线。版本发布前，配置管理员汇总代码标签、构建脚本、测试报告与发布说明，建立发布基线“BL-A-V1.2-发布”。
发布基线建立两周后，测试发现接口参数需要调整。资产负责人提交变更申请，影响配置项为接口设计文档与两个代码模块，变更评审人组织技术负责人评审，结论为批准。资产负责人修改配置项并更新版本标识，配置管理员将新版本纳入基线，生成“BL-A-V1.2-发布-Rev1”，旧基线保留。变更单记录从申请到关闭的全部状态。
版本结束后，配置管理员组织审计，核对配置项清单与实际存储一致、三条基线均有审批记录、变更单全部闭环，形成审计报告提交项目经理。整个过程留下的记录包括配置项清单、目录规范、基线清单与审批记录、变更单、审计报告，均可通过基线标识相互引用。
完成检查：配置与基线管理是否到位的核对项
判断机制是否可运行，可以按以下清单逐项核对，每项给出可观察的完成标志。
- 配置项清单完整性：清单覆盖需求、设计、代码、测试、构建脚本五类资产，每项有负责人和存储位置，负责人已确认。完成标志是清单经项目经理审批且有确认记录。
- 配置库规范执行：目录结构与命名规范已发布，抽查十个配置项，名称与存放位置符合规范。完成标志是抽查无例外或例外有说明。
- 基线建立留痕：每条基线有清单、有审批记录、有唯一标识，冻结范围与评审记录对应。完成标志是基线清单与审批记录可一一对应。
- 变更记录与基线版本一致：抽查变更单，变更后的配置项版本已纳入基线，旧基线仍可查。完成标志是变更单状态为关闭且基线版本号已更新。
- 配置审计频次与问题闭环：审计按季度或版本节点执行，报告中的问题有责任人和关闭时间。完成标志是上期问题全部关闭或有延期说明。
常见缺口有三类：清单过期，项目新增资产未登记，导致审计时找不到负责人；基线无审批，冻结动作由个人直接执行，后续无法证明冻结范围经过确认；变更未回写，配置项改了但变更单未更新、基线未升版，追溯链断裂。核对时发现上述情况，应回到对应环节补记录，并在下次审计中复查。
常见问题
配置项清单建好后，项目中途新增资产怎么处理？
清单需要随项目推进更新，不必等到阶段结束再补。建议把新增资产的登记动作挂在两个时点上：一是资产首次提交到配置库时，由资产负责人向配置管理员报备；二是每次基线建立前，配置管理员核对冻结范围内是否有未登记资产。
新增配置项沿用原清单字段补充名称、类型、负责人、存储位置、受控级别和关联基线，由配置管理员汇总、项目经理确认后更新清单版本。审计时若发现清单与实际存储不一致，先补登记再复查，避免追溯链在新增资产处断开。
小团队人手有限，能不能简化基线和变更流程？
可以按风险调整颗粒度，但几个关键记录建议保留。基线类型可以合并，例如把需求基线与设计基线合并为“开发基线”，在评审通过后一次冻结；变更评审可以由项目经理和技术负责人两人完成，不必设独立评审委员会。
需要保留的是：基线冻结范围有清单、审批有记录、变更单能对应到基线版本。这三项决定了后续能否回答“这个版本当时冻结了什么、改过什么”。简化的是参与人数和会议形式，记录本身不建议省略。
配置库和代码仓库是什么关系，需要把代码再复制一份到配置库吗？
不需要物理复制。代码仓库继续作为代码类配置项的实际存储，配置库承担索引和状态记录职责：登记仓库地址、分支与标签的对应关系，以及该代码版本属于哪条基线。
这样做的目的是让配置项清单、基线清单能指向代码的实际位置，审计时按登记信息核对分支标签是否存在、是否与基线一致。文档类配置项同理，配置库记录文档链接与版本号即可，文件本身留在文档库中。
基线建立后发现问题，是走变更还是直接重建基线？
取决于问题性质。如果冻结范围内的配置项内容需要修改，走变更流程，变更批准后更新配置项版本并生成新的基线版本号，旧基线保留。如果是冻结范围本身选错了，例如漏纳了应受控的配置项，可以由配置管理员发起基线范围调整，补充清单并重新审批，同样保留原基线记录。
两种方式都要求留下审批记录。直接覆盖原基线会让后续无法说明当时冻结了什么，审计时也难以判断变更是否经过评审。
配置审计多久做一次，由谁来做比较合适？
常见做法是按季度或按版本节点执行，版本节奏快的团队可以每个发布基线建立后做一次专项核对。审计由配置管理员组织，资产负责人配合提供资产状态，变更评审人复核变更闭环情况，项目经理审阅报告并推动问题关闭。
审计内容聚焦四项：清单与实际存储是否一致、基线是否有审批记录、变更单是否全部关闭且基线已升版、上期问题是否闭环。报告中的问题要写明责任人和关闭时间，下次审计先复查上期遗留项。
