研发配置管理要解决的是研发资产“谁改了、改了什么、当前哪一版算数”的问题。做法是把需求、设计、代码、构建脚本、环境配置和测试资产识别为配置项，放进受控库，按基线固定组合，并让变更统一走申请、评审、批准、更新、发布流程。本文按配置项识别、库与权限、基线建立、变更与偏离、状态记录与审计、角色分工的顺序给出可执行步骤，并用一个端到端示例说明各环节如何衔接。
要点总览（TL;DR）
- 配置项识别看三条：多人修改、影响下游、需要回溯时点；需求版本和交付制品纳入受控，但拆分排序与仓库分发分别归相邻主题。
- 配置库分工作区、受控库、基线库三层，入库需评审，基线库只读，修改必须走变更流程。
- 基线按功能、分配、产品三类选择建立时点，建前做完整性检查，冻结后唯一变更入口是配置变更申请。
- 变更走申请、影响分析、分级评审、实施验证、基线更新与通知；偏离登记有效期和关闭条件，到期回归或转正式变更。
- 用配置状态记录和功能/物理配置审计证明受控，审计问题登记、整改、复查关闭，机制按季度或大版本复评。
先划清配置项范围：哪些研发资产要纳入受控
配置项识别的判断标准是：该资产是否会被多人修改、是否影响多个下游环节、是否需要回溯某一时点的状态。满足其中一条，就应纳入受控范围；只供个人参考、不进入交付或验证链路的草稿，可以留在个人工作区，不登记为配置项。
配置项与普通文档的边界在于是否被引用。被需求、设计、测试用例或发布说明引用的文档，应登记为配置项并分配唯一标识；仅在会议中传阅的记录不必纳入。需求版本属于配置项，但需求条目的拆分、优先级排序和变更影响评估属于需求管理主题，本文只处理其受控与基线组合。交付制品同样属于配置项，但制品仓库的存储策略、签名与分发归交付物与制品管理，本文只规定制品在哪个基线中被固定。
按资产类型分类，便于后续设权限和建基线：
| 资产类型 | 典型内容 | 受控要点 |
|---|---|---|
| 需求 | 需求规格、用户故事、验收标准 | 版本可追溯，与测试用例建立关联 |
| 设计 | 架构说明、接口定义、数据模型 | 与需求版本对应，变更需评审 |
| 代码 | 源代码、分支、合并记录 | 提交关联变更单，禁止直接改基线分支 |
| 构建脚本 | 编译脚本、流水线配置、依赖清单 | 与代码同版本受控，可复现构建 |
| 环境配置 | 部署参数、中间件配置、密钥引用 | 区分环境，敏感值单独管理 |
| 测试资产 | 测试用例、测试数据、自动化脚本 | 与需求和缺陷关联，随基线更新 |
命名与唯一标识规则建议采用“项目代号-资产类型-模块-序号-版本”的结构，例如 PRJ-REQ-ORDER-012-v1.2。规则要写进配置管理计划，明确类型代码表、序号是否连续、版本号何时递增。同一资产改名时保留原标识作为别名，避免历史记录断链。
识别清单的模板字段包括：配置项标识、名称、类型、负责人、所属模块、关联需求或变更单、存放位置、当前版本、状态、纳入日期。清单由配置管理员起草，项目经理、开发和测试负责人共同评审，确认无遗漏、无重复、命名一致后签字生效。评审输出是受控的配置项清单，作为后续入库和建基线的依据。
配置库与权限怎么分层：受控库、基线库与工作区
配置库分三层，职责各不相同。工作区是个人或小组的编辑空间，允许频繁修改，不要求审批；受控库存放已通过评审、可以进入下一环节的配置项，入库即意味着该版本被正式承认；基线库保存被批准冻结的配置项组合，只读，任何改动必须通过变更流程。三层之间是单向流动为主：工作区到受控库需入库评审，受控库到基线库需基线批准。
入库条件应写清楚：资产完成自检、通过对应评审、命名符合规则、关联的需求或变更单已登记。出库或检出规则是：从受控库取出修改时锁定该版本，形成新工作副本，修改完成后以新版本入库，原版本保留。禁止在受控库或基线库直接编辑。
角色权限按最小必要原则划分：
| 角色 | 工作区 | 受控库 | 基线库 |
|---|---|---|---|
| 配置管理员 | 读写 | 入库审核、版本管理 | 建基线、冻结、解冻 |
| 开发 | 读写 | 提交入库申请 | 只读 |
| 测试 | 读写 | 提交测试资产入库 | 只读 |
| 评审人 | 只读 | 评审、批准入库 | 只读 |
| 项目经理 | 只读 | 查看状态 | 批准基线 |
版本号约定建议采用主版本.次版本.修订号：不兼容的结构调整升主版本，新增内容升次版本，纠错升修订号。状态标记至少包括草稿、评审中、已入库、已基线、已废弃。状态变化要记录操作人和时间，作为配置状态记录的一部分。
基线怎么建：类型、时点与建立步骤
常见基线类型有三种。功能基线在需求评审通过、需求范围确认时建立，固定“要做成什么样”；分配基线在系统设计完成、需求分配到各模块或团队时建立，固定“由谁做哪部分”；产品基线在发布前建立，固定“交付什么”。项目规模小时可以合并功能基线与分配基线，但产品基线建议单独保留。
建基线前的完整性检查包括：纳入范围的配置项是否全部入库、版本是否最新且已评审、配置项之间的关联是否完整（需求到设计到测试）、构建脚本能否复现当前版本、遗留问题和已知缺陷是否登记。检查不通过时，先补齐再建基线，避免把未完成状态冻结成正式版本。
建立步骤为：配置管理员发起基线申请并附检查结果；项目经理或配置控制委员会批准；系统冻结纳入的配置项版本，生成基线标识和清单；发布基线通知，告知各角色当前有效版本。完成标志是基线清单可查、版本锁定、通知已送达。
基线冻结后的变更入口只有一个：配置变更流程。任何人需要修改基线内配置项，先提交变更申请，经评审批准后解冻或建立新版本，再按新基线发布。绕过流程直接修改的，在配置审计中应被识别为偏离。
变更与偏离怎么走：申请、评审、批准到更新
变更申请单的必填字段包括：变更编号、申请人、申请日期、涉及配置项及当前版本、变更原因、变更内容描述、影响范围初判、期望完成时间、关联需求或缺陷。字段不全的申请退回补充，避免评审时信息缺失。
影响分析要覆盖三类对象：关联配置项（改了需求是否要改设计和测试用例）、受影响基线（哪些已冻结基线需要更新）、测试资产（回归范围是否需要扩大）。分析结论写入申请单，作为评审依据。
评审与批准按影响分级授权：影响单个模块且不涉及接口的，由模块负责人和测试负责人评审；影响跨模块接口或已发布基线的，提交配置控制委员会；影响产品基线的，需项目经理批准。评审结论分为批准、有条件批准、驳回，有条件批准要写明附加条件和验证方式。
变更实施后，开发在受控库提交新版本，测试完成验证并记录结果，配置管理员更新配置项状态和基线清单，发布变更通知。通知内容包含新版本号、生效范围、旧版本处理方式。
偏离是临时例外，指在限定时间内允许某配置项暂不满足基线要求。偏离登记要写明偏离对象、原因、影响、有效期、责任人、关闭条件。有效期到期或关闭条件满足时，必须回归基线或转为正式变更，未关闭的偏离在配置审计中列为问题。
配置状态记录与配置审计：怎么证明受控
配置状态记录回答“现在是什么状态、怎么变成这个状态的”。应包含的字段有：配置项标识、当前版本、状态、所在库、最近变更单号、基线归属、责任人、更新时间。更新频率建议与变更节奏一致：每次入库、建基线、变更关闭时同步更新，至少每周核对一次完整性。
配置审计分两类。功能配置审计检查配置项是否满足需求：需求是否都有对应设计和测试、验收标准是否覆盖、基线内容是否与需求范围一致。物理配置审计检查实际存放与记录是否一致：版本号是否匹配、基线清单与实际冻结内容是否相符、是否存在未登记的修改。
审计发现问题的处置流程是：登记问题、指定责任人、限期整改、复查关闭。复查要确认问题根因是否消除，而不只是补了记录。审计证据的留存方式包括审计计划、检查表、问题清单、整改记录和复查结论，按项目归档，保存期限与项目或产品生命周期一致。
在工具层面，配置项登记、版本状态和基线清单如果分散在文档和表格中，状态更新容易滞后。ONES 可以用工作项承载需求、任务和缺陷，用文档管理设计与测试资产，并通过版本和状态字段记录配置项当前状态；基线冻结和变更评审可以在同一工作项流程中留下审批记录，使配置状态记录与审计证据来自同一处操作痕迹。是否采用工具承载，取决于团队已有的协作平台和审计要求。
角色分工与交付物：谁负责哪一步
配置管理员负责配置项清单维护、库结构管理、基线建立操作、状态记录更新和审计组织；项目经理负责批准基线和重大变更、协调资源；开发负责按规则提交入库、执行变更实施；测试负责测试资产入库、变更验证；评审人负责入库评审和变更评审。职责要写进配置管理计划，避免出现“清单有人建、没人维护”的情况。
配置控制委员会的设置条件是：项目涉及多个团队、基线需要跨团队协调、或变更影响已发布产品。议事范围包括基线批准、重大变更审批、偏离的例外批准。小团队可以不设委员会，由项目经理加配置管理员两人完成审批，但审批记录仍要保留。
| 环节 | 责任人 | 交付物 | 交接对象 |
|---|---|---|---|
| 配置项识别 | 配置管理员 | 配置项清单 | 项目经理、开发、测试 |
| 入库评审 | 评审人 | 入库评审记录 | 配置管理员 |
| 基线建立 | 配置管理员 | 基线清单与批准记录 | 全体角色 |
| 变更审批 | 评审人/委员会 | 变更申请单与评审结论 | 开发、测试 |
| 状态记录 | 配置管理员 | 配置状态记录表 | 项目经理 |
| 配置审计 | 配置管理员 | 审计检查表与问题清单 | 项目经理、责任人 |
小团队精简分工时，配置管理员可由项目经理或资深开发兼任，评审人由同组另一名成员担任，但提交人与评审人不能是同一人。精简的是人数，不是记录：清单、基线、变更单和审计结论仍要留痕。
一个完整示例：从需求变更到新基线发布
以下为演示情景。某订单模块已建立产品基线 B1.0，包含需求 REQ-ORDER-012 v1.2、对应设计、代码分支 release-1.0 和测试用例集。业务提出增加“部分退款”能力。
开发提交变更申请 CR-021，填写涉及需求 REQ-ORDER-012、影响设计和退款相关测试用例、期望两周完成。影响分析结论是：需修改需求至 v1.3、新增接口设计、扩充回归用例，B1.0 基线需在验证后更新为 B1.1。评审由模块负责人和测试负责人完成，因涉及已发布基线，项目经理批准。
批准后，配置管理员解冻相关配置项，开发在受控库提交需求 v1.3 和设计新版本，测试更新用例并执行回归，结果记录在变更单。验证通过后，配置管理员建立 B1.1 基线，更新状态记录中的版本和基线归属，发布通知说明 B1.0 停止新增变更、B1.1 生效。
审计阶段，物理配置审计核对 B1.1 清单与实际冻结内容一致，功能配置审计确认新需求有对应设计和测试覆盖。变更单、评审记录、验证结果和基线清单共同构成这次变更的完整证据链。
完成检查：配置管理机制是否可运行
机制是否落地，可以用以下检查项逐条核对，每项都要有可查的记录，而不是口头确认。
- 配置项清单完整性：清单覆盖需求、设计、代码、构建脚本、环境配置和测试资产；抽查十个配置项，命名与标识规则一致，无重复登记。
- 库与权限：工作区、受控库、基线库职责清晰；抽查一次入库，有评审记录；基线库无直接修改记录。
- 基线与变更可追溯：任取一个基线，能查到纳入的配置项版本和批准记录；任取一个变更，能查到申请、评审、实施、验证和基线更新记录。
- 偏离管理：未关闭偏离有责任人和有效期，到期偏离已回归或转为变更。
- 审计执行：最近一个周期内完成过功能配置审计和物理配置审计，问题清单中的问题已复查关闭。
- 机制维护：配置管理计划有责任人和复评周期，建议每季度或每个大版本结束后复评一次，根据团队变化调整配置项范围和审批层级。
检查中发现的问题按配置审计问题处置，登记、整改、复查。复评的输出是更新后的配置管理计划和配置项清单，使机制随项目推进保持可运行。
常见问题
配置项清单建好后，日常由谁维护、多久核对一次？
配置项清单由配置管理员维护，开发和测试负责在新增或修改资产时提交入库申请，项目经理在基线建立和变更审批时确认清单范围。核对频率建议与变更节奏对齐：每次入库、建基线、变更关闭时同步更新，至少每周做一次完整性抽查，重点看新增配置项是否登记、命名是否一致、状态是否与实际存放位置相符。清单变更本身也应留下记录，注明变更人、时间和原因。
小团队没有专职配置管理员，流程可以精简到什么程度？
小团队可以由项目经理或资深开发兼任配置管理员，评审人由同组另一名成员担任，提交人与评审人分开即可。可以合并功能基线与分配基线，变更审批由项目经理加配置管理员两人完成，不设配置控制委员会。精简的是人数和审批层级，清单、基线记录、变更单和审计结论仍要保留，否则后续无法证明受控状态。团队扩大或涉及跨团队基线时，再补设委员会和分级授权。
基线冻结后，发现一个紧急缺陷必须马上修，能不能先改再补变更单？
不建议先改后补。基线库只读，直接修改会在物理配置审计中被识别为未登记修改，证据链断裂。紧急情况下可以走简化变更：先提交变更申请并注明紧急原因，由项目经理或授权评审人做快速评审，批准后解冻相关配置项、建立新版本，验证通过后更新基线并补全记录。如果确实需要临时例外，按偏离登记，写明有效期和关闭条件，到期前回归基线或转为正式变更。
配置审计多久做一次，审计发现的问题怎么防止反复出现？
审计频率按项目节奏定，建议每个大版本发布前做一次完整审计，周期内至少做一次抽查。功能配置审计看需求是否有对应设计和测试覆盖，物理配置审计看实际冻结内容与基线清单是否一致。问题处置不能只补记录，复查时要确认根因是否消除：如果是命名规则不清导致重复登记，就更新规则并同步清单；如果是审批记录缺失，就明确该环节的责任人和留痕方式。复查结论归档，作为下次审计的输入。
需求版本管理和配置管理是什么关系，会不会重复建两套记录？
需求版本是配置项的一种，配置管理负责把它纳入受控库、分配唯一标识、按基线固定组合，并让变更走统一流程。需求条目的拆分、优先级排序和变更影响评估属于需求管理主题，由需求管理流程处理。两套记录可以共用同一份配置项标识和版本号，配置状态记录引用需求变更单号即可，不需要重复登记。边界写进配置管理计划，明确哪些字段由需求管理维护、哪些由配置管理维护，避免两边各记一套。
