基线发布记录模板需要覆盖一次基线发布从范围确定到发布确认的完整事实。建议用一张主表承载基线标识、类型、受控范围、纳入配置项数量、建立与发布时间、责任人、审批结论、发布说明、验证与回退信息，再配一张纳入配置项清单和一张发布前检查清单，三张表用同一个基线编号关联。标识、范围、版本、时间、责任人、审批结论作为必填项，关联需求、风险备注、回退方案等按项目受控程度选填。
要点总览（TL;DR）
- 基线发布记录模板由一张主表加两张配套表组成：主表记录一次基线发布的事实，纳入配置项清单记录逐条明细，发布前检查清单记录核对动作，三张表用同一基线编号关联。
- 主表字段包括基线编号、名称、类型、受控范围、纳入配置项数量与清单引用、建立与发布时间、发布人、审批角色与结论、发布说明、变更依据、验证结果、回退信息和备注。
- 标识、范围、版本、时间、责任人、审批结论为必填；变更依据、验证结果、回退信息、关联需求、风险备注按项目受控程度选填，涉及对外交付或生产发布时建议转为必填。
- 填写时区分建立时间与发布时间，审批角色与审批结论分开记录，配置项版本号与存放位置要能定位到具体文件或条目。
- 模板自身需要版本与变更记录，新增字段经评审后生效，历史记录按基线编号归档并保留原模板版本号。
可复制空白模板：基线发布记录主表
主表记录一次基线发布的结果性事实，一行对应一次发布。填写时先确定基线编号，再补齐范围、版本、时间和审批信息。下表可直接复制到文档或表格工具中使用。
| 字段 | 填写内容 |
|---|---|
| 基线编号 | |
| 基线名称 | |
| 基线类型 | |
| 受控范围 | |
| 纳入配置项数量 | |
| 配置项清单引用 | |
| 建立时间 | |
| 发布时间 | |
| 发布人 | |
| 审批角色 | |
| 审批结论 | |
| 发布说明 | |
| 变更依据 | |
| 验证结果 | |
| 回退信息 | |
| 备注 |
主表不逐条列出配置项，只记录数量和清单引用；配置项明细放入配套清单，避免主表随配置项增多而失控。审批角色与审批结论分开记录，便于区分“谁审的”和“审的结果”。验证结果与回退信息放在同一张表内，发布后出现问题时可以直接从记录中找到处理依据。
配套空白表：纳入配置项清单与发布前检查清单
主表承载发布事实，两张配套表承载明细和核对动作。三张表共用基线编号，检索时以编号为入口即可还原一次发布的完整记录。
纳入配置项清单
| 基线编号 | 配置项名称 | 配置项类型 | 版本号 | 存放位置 | 责任人 | 备注 |
|---|---|---|---|---|---|---|
发布前检查清单
| 基线编号 | 检查项 | 检查人 | 结论 | 证据位置 | 检查时间 |
|---|---|---|---|---|---|
配置项清单的每一行对应一个受控对象，版本号与存放位置必须能定位到具体文件或条目。检查清单的检查项按项目实际发布要求设置，常见项包括配置项版本核对、审批完成情况、构建或打包结果确认、回退方案可用性确认。结论栏填写通过、不通过或有条件通过，证据位置填写对应的评审记录、测试报告或构建产物地址。
字段说明：每个字段记录什么、怎么填
同一份模板会被配置管理员、项目经理、审批人和发布执行人共同使用，字段口径需要提前约定，避免同一字段出现多种填法。
标识与名称
基线编号建议采用“项目代号-基线类型缩写-序号”的结构，例如某项目首次功能基线可记为“PRJ-FBL-001”，编号一经使用不再复用。基线名称写业务可读的名称，说明这次基线对应的版本主题或交付阶段，名称可以调整，编号保持不变。
类型与受控范围
基线类型按项目配置管理约定填写，常见分类包括功能基线、分配基线、产品基线，也可按阶段划分为需求基线、设计基线、发布基线。受控范围写明本次基线覆盖哪些配置项类别和边界，例如“覆盖需求文档与接口设计文档，不含测试用例”。范围写清楚，后续判断某个变更是否影响基线才有依据。
配置项版本号
版本号记录配置项在纳入基线时的确定版本，填写规则与项目版本命名保持一致，例如“V1.2”或“1.2.0”。同一配置项在清单中只出现一次，后续变更通过新版本和新基线记录体现，不在原记录上覆盖修改。
时间字段
建立时间指基线内容冻结、配置项版本确定的时间；发布时间指审批完成、基线正式对外生效的时间。两个时间可能相同，也可能相隔数天，分别记录可以还原发布过程。时间格式统一到日，需要精确到时刻的项目可统一到分钟。
审批角色与结论
审批角色填写实际承担审批职责的岗位或角色，如配置管理员、项目经理、质量负责人，多人审批时逐条列出。审批结论填写同意、不同意或有条件同意，有条件同意需在备注中写明附加条件。审批结论为空时，该记录不视为完成发布。
发布说明与变更依据
发布说明用几句话写清本次基线包含什么、相对上一基线的主要变化。变更依据填写触发本次发布的变更单号、评审记录或需求变更编号，使发布动作可以追溯到具体决策。没有变更依据的首次基线，填写项目立项或阶段评审的对应记录。
记录流转中的工具承载
模板填写完成后，记录还需要经过审批、发布和归档才能成为可查的受控记录。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯。模板本身可以放入 ONES Wiki 的页面模板库，一键创建制式化文档，页面版本可随时查看与回滚，适合把主表和两张配套表固化为同一套模板反复使用。审批节点和交付物模板也可以沉淀为可复用资产，具体流程配置按项目实际管理要求确定。
必填与选填：按受控程度划分字段等级
字段等级取决于项目受控程度。受控要求高的项目，选填字段也可能转为必填；受控要求较低的项目，可在保留核心事实的前提下裁剪。
| 字段 | 等级 | 理由与适用情形 |
|---|---|---|
| 基线编号 | 必填 | 唯一标识，关联三张表和后续检索的基础 |
| 基线名称 | 必填 | 业务识别入口，便于非配置管理人员理解 |
| 基线类型 | 必填 | 决定受控规则和审批要求 |
| 受控范围 | 必填 | 界定基线边界，影响变更判断 |
| 纳入配置项数量与清单引用 | 必填 | 证明基线内容完整，可回溯到明细 |
| 建立时间 | 必填 | 确定版本冻结时点 |
| 发布时间 | 必填 | 确定基线生效时点 |
| 发布人 | 必填 | 明确执行责任 |
| 审批角色与审批结论 | 必填 | 发布有效性的直接依据 |
| 发布说明 | 必填 | 说明本次发布内容，支撑后续查阅 |
| 变更依据 | 选填 | 首次基线可填立项记录；常规发布建议填写 |
| 验证结果 | 选填 | 受控程度高的项目转为必填 |
| 回退信息 | 选填 | 涉及生产发布或对外交付时建议必填 |
| 关联需求 | 选填 | 需要做需求追溯时填写 |
| 风险备注 | 选填 | 存在已知风险或遗留问题时填写 |
裁剪原则可以按三条执行：涉及对外交付、生产环境或合规审查的基线，验证结果和回退信息转为必填；仅内部阶段冻结的基线，可保留核心字段并简化检查清单；字段缺失时在备注中写明缺失原因和补录计划，不留空白直接发布。审批结论缺失的记录不进入受控库，待补齐后再归档。
填写示例：一次基线发布的完整记录
以下示例为演示情景，用于说明字段之间的对应关系，项目名称和数据均为示意。
主表示例
| 字段 | 填写内容 |
|---|---|
| 基线编号 | PRJ-FBL-003 |
| 基线名称 | 订单模块二期功能基线 |
| 基线类型 | 功能基线 |
| 受控范围 | 订单模块需求文档、接口设计文档、核心服务代码，不含测试用例 |
| 纳入配置项数量 | 12 |
| 配置项清单引用 | PRJ-FBL-003-清单 |
| 建立时间 | 2025-03-10 |
| 发布时间 | 2025-03-12 |
| 发布人 | 配置管理员 李某 |
| 审批角色 | 项目经理、质量负责人 |
| 审批结论 | 同意 |
| 发布说明 | 完成订单拆单与优惠计算需求冻结，接口设计同步更新 |
| 变更依据 | 变更单 CR-0217、需求评审记录 RV-0088 |
| 验证结果 | 配置项版本核对通过，接口文档评审通过 |
| 回退信息 | 回退至 PRJ-FBL-002，回退步骤见配置库说明 |
纳入配置项清单示例
| 基线编号 | 配置项名称 | 类型 | 版本号 | 存放位置 | 责任人 |
|---|---|---|---|---|---|
| PRJ-FBL-003 | 订单模块需求规格 | 需求文档 | V2.1 | 配置库/需求/订单 | 产品 王某 |
| PRJ-FBL-003 | 订单接口设计说明 | 设计文档 | V1.4 | 配置库/设计/订单 | 架构 赵某 |
| PRJ-FBL-003 | 订单核心服务代码 | 代码 | 1.3.0 | 代码库/tag/order-1.3.0 | 开发 陈某 |
发布前检查清单示例
| 基线编号 | 检查项 | 检查人 | 结论 | 证据位置 |
|---|---|---|---|---|
| PRJ-FBL-003 | 配置项版本与清单一致 | 配置管理员 李某 | 通过 | PRJ-FBL-003-清单 |
| PRJ-FBL-003 | 需求与设计评审完成 | 质量 周某 | 通过 | 评审记录 RV-0088 |
| PRJ-FBL-003 | 回退方案可用 | 配置管理员 李某 | 通过 | 配置库回退说明 |
示例中主表的配置项数量为12，清单只展示其中3条，实际使用时清单行数与数量字段保持一致。主表的变更依据对应检查清单中的评审记录编号，回退信息对应回退方案检查项，字段之间可以互相印证。
调整与维护方法：模板随项目演进怎么改
模板本身也是受控对象，需要版本和变更记录，否则不同项目拿到的模板会逐渐分叉，记录无法横向比较。
模板版本与变更记录
| 模板版本 | 变更内容 | 变更原因 | 评审人 | 生效日期 |
|---|---|---|---|---|
| V1.0 | 初始版本，含主表与两张配套表 | 项目启动建立配置管理规范 | ||
| V1.1 | 新增“回退信息”字段 | 生产发布需要回退依据 | ||
新增字段的评审与生效
新增字段先由配置管理员提出，说明字段用途、填写角色和与现有字段的关系，经项目经理或质量负责人评审后发布新模板版本。新版本生效后，新建立的基线使用新模板，已归档记录保持原样，需要补充信息时以附注方式追加，不直接改写历史记录。
历史记录的归档与检索
历史记录按基线编号归档，主表、配置项清单和检查清单放在同一归档目录或以编号建立关联。检索入口以基线编号为主，辅以基线名称、发布时间和配置项名称。归档记录保留原模板版本号，便于判断字段口径差异。
与相邻管理对象的边界
基线发布记录只记录“哪些配置项在什么版本被冻结并发布”这一事实。需求版本的具体变更流程在需求变更管理中记录，交付制品的打包与分发在制品管理中记录，基线记录通过变更单号和制品标识引用它们，不重复承载其明细。边界清楚，模板字段才能保持稳定，记录也更容易被审计和追溯。
常见问题
基线发布记录和需求变更记录、交付制品记录怎么分工，避免重复填写？
基线发布记录只回答“哪些配置项在什么版本被冻结并发布”这一件事。需求版本的具体变更过程在需求变更管理中记录，交付制品的打包与分发在制品管理中记录。基线记录通过变更单号、评审记录编号和制品标识引用它们，不复制其明细。
这样分工后，基线主表保持稳定，字段不会随需求或制品管理流程调整而频繁变动，审计时也能沿着引用关系找到上游决策和下游交付。
项目受控要求不高，能不能只用主表、不做配置项清单和检查清单？
可以按项目受控程度裁剪，但建议保留配置项清单。主表只记录配置项数量和清单引用，没有清单就无法回溯基线里到底包含哪些文件、哪个版本，后续判断变更影响会缺少依据。
发布前检查清单在内部阶段冻结的场景可以简化，保留版本核对和审批完成两项即可；涉及对外交付或生产环境时，检查项应覆盖构建结果确认和回退方案可用性。
审批结论填了“有条件同意”，记录算完成发布吗？
有条件同意表示审批已通过但附带前提，记录可以进入发布流程，前提条件需要写入备注并明确责任人和完成时间。前提条件未落实前，基线不应标记为正式生效。
审批结论为空或为不同意时，该记录不视为完成发布，不进入受控库，待补齐审批后再归档。
历史基线记录需要补录字段时，直接改原记录还是另做说明？
已归档的记录保持原样，补充信息以附注方式追加，并注明补录人、补录时间和补录原因。直接改写历史记录会破坏记录与当时模板版本、审批结论的对应关系，审计时难以说明字段口径差异。
如果补充信息反映的是模板字段缺失，应走模板变更流程，在新版本模板中增加字段，新建立的基线使用新模板。
用文档工具管理基线记录，怎么保证三张表不会各自散落？
关键是让基线编号成为唯一入口：主表、配置项清单和检查清单都以基线编号命名或作为首列，归档时放在同一目录或以编号建立关联。检索时先按编号定位主表，再顺着编号找到两张配套表。
如果使用 ONES Wiki，可以把主表和两张配套表做成同一套页面模板，一键创建制式化文档，页面版本可随时查看与回滚，减少每次手工搭表带来的结构差异。
