发布记录要回答六个问题：这次发布了什么、依据是什么、谁批准、发到哪、结果如何、出问题怎么回退。围绕这六个问题，一份可用的记录至少保留版本标识与发布范围、发布内容清单、构建与制品标识、发布环境与时间窗口、审批与责任人、验证结果与已知问题、回退方案与回退点、发布后观察结论。字段按发布批次建档，并与需求、缺陷、变更单和制品建立关联，发布结束后补齐结果字段再关闭。
要点总览（TL;DR）
- 发布记录按“一次发布批次一份记录”建档，至少保留版本标识与发布范围、内容清单、构建与制品标识、环境与时间窗口、审批与责任人、验证结果与已知问题、回退方案与回退点、观察结论与关闭状态。
- 字段分三个时点填写：发布前锁定范围、登记制品与回退点；发布中记录实际执行时间、执行人和异常处置；发布后补齐验证结果与观察结论再关闭。
- 发布经理负责建档、汇总与关闭，开发提供变更内容与制品标识，测试提供验证结果与遗留项，运维提供环境与回退记录，审批人确认范围与风险接受。
- 内容清单只登记关联编号加简短说明，详细描述留在需求或缺陷本身；制品标识要能唯一定位到实际部署的那份产物。
- 归档前逐项核对关键字段，验证结论不明确、回退点制品不可用、审批记录缺失等情况应视为阻断，补齐后再关闭。
发布记录的核心字段清单
发布记录按“一次发布批次一份记录”组织，字段分为三类：标识类说明这是哪次发布，内容类说明发布里有什么，结果类说明发布是否成功、出了问题如何处理。下表给出可直接套用的字段清单。
| 字段 | 填写内容 | 必填/选填 | 填写角色 |
|---|---|---|---|
| 版本标识 | 版本号或发布名称，与制品、标签保持一致 | 必填 | 发布经理 |
| 发布批次 | 批次编号、发布类型（常规/紧急/补丁） | 必填 | 发布经理 |
| 发布范围 | 涉及的模块、服务、应用及影响的使用方 | 必填 | 发布经理 |
| 发布内容清单 | 本次包含的需求、缺陷修复、变更单的关联编号及一句话说明 | 必填 | 开发、发布经理汇总 |
| 构建号与制品标识 | 构建编号、制品名称与版本、校验值或唯一标识 | 必填 | 开发或构建负责人 |
| 配置基线 | 配置项版本、参数变更说明、依赖的外部服务版本 | 必填 | 开发、运维 |
| 发布环境 | 目标环境（测试/预发/生产）、机房或集群、目标实例范围 | 必填 | 运维 |
| 时间窗口 | 计划开始与结束时间、实际开始与结束时间 | 必填 | 发布经理、运维 |
| 执行人 | 实际执行发布操作的人员 | 必填 | 运维 |
| 审批记录 | 审批人、审批时间、审批结论与附带条件 | 必填 | 审批人 |
| 责任人 | 发布负责人、技术负责人、业务确认人 | 必填 | 发布经理 |
| 验证结果 | 验证项、验证方式、通过/不通过及证据位置 | 必填 | 测试、业务确认人 |
| 已知问题与遗留项 | 未关闭缺陷、已知限制、临时规避方式及后续处理计划 | 必填（无则写“无”） | 测试 |
| 回退方案 | 回退触发条件、回退步骤、回退所需制品版本 | 必填 | 开发、运维 |
| 回退点 | 可回退到的上一稳定版本及对应制品标识 | 必填 | 运维 |
| 回退执行记录 | 是否执行回退、执行时间、执行人、回退后状态 | 选填（触发时必填） | 运维 |
| 发布后观察结论 | 观察期长度、监控指标表现、用户反馈、结论 | 必填 | 发布经理、运维 |
| 关闭状态 | 已关闭/带遗留项关闭/回退关闭，关闭时间与关闭人 | 必填 | 发布经理 |
填写时有两条口径值得固定下来。其一，发布内容清单只登记关联编号加简短说明，详细描述留在需求或缺陷本身，避免同一信息两处维护、两处不一致。其二，制品标识必须能唯一定位到实际部署的那份产物，仅写版本号在多次构建同一版本号的情况下会产生歧义。
当记录需要与需求、缺陷、变更单和制品互相跳转时，可以借助工作项与发布管理工具承载这些关联。ONES 支持将工作项与版本、发布建立关联，使发布记录中的内容清单和审批信息可以回溯到具体条目；具体字段配置方式以团队实际使用的产品资料为准。
按发布流程分步填写：从准备到关闭
字段清单是静态的，真正决定记录质量的是每个字段在什么时点被填上。按发布前、发布中、发布后三段推进，可以避免发布结束后凭记忆补记。
发布前：确定范围、冻结内容、登记制品与回退点
输入是本次计划纳入版本的需求与缺陷清单、待发布的构建产物、上一稳定版本信息。动作包括：确认版本范围并锁定内容清单，标记内容冻结时点，登记构建号、制品标识与配置基线，指定回退点并核对回退制品可用。输出是内容清单、制品标识和回退方案三项已填写。完成标志是内容冻结后清单不再新增条目，回退点对应的制品可被检索到。
发布中：记录实际执行情况
输入是审批通过的发布单和发布操作步骤。动作是记录实际开始时间、执行人、每一步执行结果；出现异常时记录异常现象、临时处置方式和处置人，处置后继续或中止的判断也要留下。输出是执行时间线与异常记录。完成标志是发布操作全部执行完毕，或已按预案中止并进入回退流程。
发布后：补齐验证结果与观察结论并关闭
输入是发布完成状态和验证清单。动作是逐项填写验证结果及证据位置，登记已知问题与遗留项，在约定的观察期内跟踪监控指标和用户反馈，写出观察结论，最后填写关闭状态与关闭人。输出是一份字段完整的发布记录。完成标志是验证结论明确、观察结论已写、关闭状态已置位。
三个时点的分工可以概括为：发布前把“要发什么、发哪份、怎么退”写清楚，发布中把“实际怎么发的”记下来，发布后把“发完怎么样”补完整。任何一段缺失，记录都会在事后追溯时失去价值。
角色分工与各角色交付物
发布记录由多人共同填写，若职责不清，最容易出现的是验证结果无人认领、回退方案照抄模板。下表按角色列出动作与交付物。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 发布经理 | 建立发布记录、汇总内容清单、组织审批、跟踪各字段填写、发布后关闭记录 | 完整的发布记录、关闭结论 |
| 开发 | 提供变更内容与关联编号、构建号与制品标识、配置基线变更说明、回退方案技术部分 | 内容清单、制品标识、回退步骤 |
| 测试 | 执行发布后验证、记录验证项与结果、登记已知问题与遗留项 | 验证结果、遗留问题清单 |
| 运维 | 确认发布环境与时间窗口、执行发布操作、记录执行时间与异常、维护回退点、必要时执行回退 | 执行记录、环境信息、回退执行记录 |
| 审批人 | 确认发布范围、评估风险、给出审批结论与附带条件、对风险接受签字 | 审批记录 |
审批人的职责需要单独强调：审批不只是签一个字，而是对“发布范围是否清楚、风险是否被识别、回退是否可行”做出判断。审批记录中写明结论和条件，后续出现争议时才有依据。发布经理则承担兜底责任，在关闭前逐项核对字段，缺项退回对应角色补齐。
示例：一次常规版本发布的记录填写
以下为演示情景，用于说明字段如何被填满，不代表任何真实系统。
版本与范围：版本标识 V2.4.0，发布批次 2024-06 常规发布，范围包括订单服务与结算页前端，影响使用方为线上全部用户。
内容清单：关联需求 REQ-1182（订单批量导出）、REQ-1205（结算页加载优化），关联缺陷 BUG-3341（优惠券金额显示错误）、BUG-3350（导出文件名乱码），关联变更单 CHG-077（结算页接口参数调整）。
制品与回退点：构建号 build-240612-03，制品 order-service:2.4.0 与 web-settle:2.4.0，配置基线 config-2.4；回退点为 V2.3.2 对应制品 order-service:2.3.2 与 web-settle:2.3.2，回退触发条件为核心下单链路错误率超过阈值。
环境与执行：目标环境为生产集群 A，计划窗口 6 月 12 日 22:00–23:00，实际执行 22:05–22:38，执行人为运维值班人员，过程中结算页灰度实例出现一次超时，临时将灰度比例从 20% 降至 10%，十分钟后恢复。
审批：审批人技术负责人，审批时间 6 月 12 日 18:20，结论为同意发布，附带条件为观察期内每半小时检查一次下单成功率。
验证与已知问题：验证项包括批量导出、优惠券金额显示、结算页加载耗时，均通过，证据见测试报告附件；已知问题为导出文件在超过五万行时耗时偏长，已登记为遗留项并计划下个版本优化。
观察结论与关闭：观察期 24 小时，下单成功率与错误率均在正常区间，无用户集中反馈；记录状态为带遗留项关闭，关闭人发布经理，关闭时间 6 月 13 日 23:00。
这份示例的关键在于每个字段都能被独立核对：制品标识能定位到具体产物，回退点能对应到上一版本，验证结果有证据位置，遗留项有后续计划。照此结构填写，记录即可支撑事后追溯。
发布记录的存放、关联与完成检查
记录存放位置应满足两个条件：按版本或批次可检索，且能与需求、缺陷、变更单、制品互相跳转。常见做法是在发布管理或项目管理工具中为每个发布批次建立一条记录，内容清单以关联方式引用工作项，制品标识以文本或链接方式指向制品库条目，审批记录随记录一并保存。检索时按版本号、批次编号或时间范围都能定位到对应记录。
归档前按下表逐项核对，任一项不通过即视为阻断，不宜关闭归档。
| 检查项 | 通过标准 | 阻断条件 |
|---|---|---|
| 版本与范围 | 版本标识、批次、范围均已填写且与制品一致 | 版本标识缺失或与制品不一致 |
| 内容清单 | 每条需求、缺陷、变更均有可跳转的关联编号 | 存在无编号的“其他修改”条目 |
| 制品与基线 | 制品标识可唯一定位，配置基线已登记 | 制品标识无法定位到实际产物 |
| 审批记录 | 审批人、时间、结论齐全 | 无审批或审批结论不明确 |
| 验证结果 | 验证项逐条有结论和证据位置 | 关键验证项无结论 |
| 已知问题 | 已登记或明确写“无” | 字段空缺 |
| 回退方案与回退点 | 回退步骤可执行，回退点制品可用 | 回退点制品已不可获取 |
| 观察结论与关闭 | 观察结论已写，关闭状态与关闭人已填 | 观察期未结束即关闭且无说明 |
归档后记录进入只读维护状态，后续如需补充说明，以追加备注的方式记录，不覆盖原始内容。这样既保留了发布当时的真实情况，也保留了事后补充的痕迹，审计和复盘时都能还原完整过程。
常见问题
发布记录和发布单、变更单是什么关系，需要重复填写吗？
三者承担不同职责：变更单说明“为什么要改、改什么、风险如何评估”，发布单说明“这次批准发什么、发到哪”，发布记录说明“实际怎么发的、结果如何”。发布记录可以直接引用变更单和发布单的编号与结论，不必重复抄写评估内容，但实际执行时间、执行人、异常处置、验证结果和观察结论这些只有发布过程才会产生的信息，需要在发布记录中单独填写。
紧急发布或补丁发布，记录可以简化吗？
可以调整填写顺序，不宜减少关键字段。紧急发布常见的做法是先口头或即时通讯确认，事后在约定时限内补齐审批记录和内容清单，并在记录中注明“先执行后补审批”的原因与确认人。回退方案、制品标识、验证结果和关闭状态仍应完整保留，因为紧急发布的风险更高，事后追溯时这些字段恰恰最需要。
发布后观察期还没结束，但业务要求先关闭记录，怎么处理？
建议把关闭状态区分为“已关闭”和“带遗留项关闭”，观察期未结束时不要直接置为已关闭。可以在记录中写明观察期的计划结束时间、当前监控表现和责任人，待观察期结束后再补充结论并更新关闭状态。若确需提前关闭，应在关闭说明中写明原因和后续跟踪安排，避免事后无法还原当时的判断依据。
回退方案每个版本都要重新写吗？
回退步骤可以复用通用模板，但回退点和回退所需制品版本必须按本次发布重新确认。每次发布前应核对上一稳定版本的制品是否仍可获取、配置是否兼容、数据变更是否可逆。涉及数据库结构变更或外部依赖升级的发布，回退方案需要单独评估，不能直接套用上一次的模板。
发布记录应该保存多久，归档后还能修改吗？
保存期限通常由团队的审计要求、合规要求和问题追溯周期决定，涉及对外服务或受监管业务的发布，保存期限往往更长，具体以所在组织的制度为准。归档后建议将记录置为只读，后续如需补充说明，以追加备注的方式记录并保留追加人和时间，不覆盖原始内容，这样既能保留发布当时的真实情况，也能保留事后补充的痕迹。
