版本发布清单要覆盖八类信息：发布范围与版本标识、变更与缺陷关闭情况、构建与制品信息、环境与部署步骤、配置与数据变更、验证与回滚方案、审批与通知、发布后观察与收尾。清单按发布前准备、发布执行、发布后验证三个阶段组织，每项写明通过标准、证据和负责人，并单独标出阻断项。这样清单在评审前能填、执行中能核、发布后能查，而不是事后补填的文档。清单可用工作项和文档承载，ONES 可作为其中一种承载方式。
要点总览（TL;DR）
- 版本发布清单按发布前准备、发布执行、发布后验证三个阶段组织，覆盖版本标识、变更与缺陷、构建与制品、环境与部署、配置与数据、验证与回滚、审批与通知、发布后观察八类信息。
- 每项检查要写明通过标准、证据、负责人和判定结果，通过标准写成可观察、可判断的表述，例如“缺陷清单中无未关闭的严重级缺陷”。
- 阻断项单独列出，关键缺陷未关闭、回滚方案缺失或未验证、审批未完成、制品来源不明等情形不能放行，解除阻断需有记录和确认人。
- 清单在发布评审前填写、执行中核对、发布后确认收尾，版本范围或制品变化时同步更新，避免用旧清单核对新制品。
- 清单可与版本发布单绑定，用工作项承载检查项、用文档存放评审与验证记录，ONES 可作为其中一种承载方式。
谁在什么时点使用这份清单
清单的价值取决于它在正确的时点被正确的人使用。发布负责人、研发、测试、运维、产品与业务验收方各自关注不同信息，若只在发布后统一补填，清单就退化为记录文档，失去拦截风险的作用。
| 使用角色 | 主要关注内容 | 使用时点 |
|---|---|---|
| 发布负责人 | 整体进度、阻断项、放行结论 | 发布评审前汇总、执行中跟踪、发布后确认收尾 |
| 研发 | 变更范围、缺陷关闭、构建与制品、配置与数据脚本 | 发布前填写并提交证据 |
| 测试 | 验证用例结果、遗留缺陷与风险 | 发布前确认验证结论、发布后执行回归 |
| 运维 | 部署步骤、环境依赖、监控告警、回滚准备 | 执行前核对、执行中记录、发布后观察 |
| 产品与业务验收方 | 范围确认、功能验收、用户反馈 | 发布前确认范围、发布后验收 |
判定方式统一为三项：通过、不通过、不适用。不通过项必须写明处置结论和责任人，不适用项必须写明理由。清单版本与发布单号绑定，版本范围或制品发生变化时同步更新清单，避免用旧清单核对新制品。
发布前准备阶段的检查项
发布前阶段回答“这次发什么、凭什么发、谁批准发”。以下检查项在发布评审前完成填写，评审时逐项核对。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 版本标识 | 版本号、发布单号、关联需求与缺陷清单齐全且可追溯 | 发布单、需求与缺陷关联记录 | 发布负责人 |
| 范围确认 | 明确列出本次包含的模块与服务，以及明确不包含的内容 | 范围说明、评审记录 | 产品负责人 |
| 变更与缺陷 | 严重级缺陷全部关闭；遗留问题有风险接受记录 | 缺陷清单、风险接受记录 | 研发负责人、测试负责人 |
| 构建与制品 | 构建编号、制品来源、校验值、存放位置均可查，且与发布单一致 | 流水线执行记录、制品校验记录 | 研发负责人 |
| 环境与依赖 | 目标环境明确，依赖服务版本与第三方接口变更已确认 | 环境说明、依赖清单 | 运维负责人 |
| 审批与通知 | 评审结论已记录，审批人已确认，发布窗口与通知对象明确 | 评审记录、审批记录、通知记录 | 发布负责人 |
范围确认要写清“不包含什么”。只写包含项时，评审方容易默认其他变更也随本次发布，导致执行阶段出现计划外操作。变更与缺陷一项要区分“已关闭”和“已评估可接受”，后者需要单独的风险接受记录，不能以口头同意代替。
发布执行阶段的检查项
执行阶段回答“按什么顺序做、做到哪一步、出现偏差怎么办”。这一阶段的记录要能还原执行过程，便于事后定位问题。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 部署步骤 | 执行顺序、脚本或流水线编号、执行人明确，按序执行无跳步 | 执行日志、操作记录 | 运维负责人 |
| 配置与数据变更 | 配置项清单与数据库变更脚本齐全，执行结果逐项记录 | 配置清单、脚本、执行结果记录 | 研发负责人、运维负责人 |
| 灰度与分批 | 分批范围、观察指标、继续或停止的判断依据事先写明 | 灰度方案、观察指标记录 | 发布负责人 |
| 异常记录 | 执行中的偏差、处置动作与时间点均有记录 | 异常记录、处置记录 | 执行人 |
| 回滚准备 | 回滚包、回滚脚本、回滚决策人与触发条件就绪 | 回滚方案、回滚包校验记录 | 运维负责人 |
灰度与分批的判断依据要在执行前确定，例如观察哪些指标、观察多长时间、达到什么条件继续下一批。执行中临时决定继续或停止，容易把判断变成个人经验。异常记录要写时间点，便于与监控数据对齐。
发布后验证与收尾阶段的检查项
发布后阶段回答“交付结果是否成立、运行是否稳定、还有什么没做完”。验证结论由验收人确认，不以执行人自检代替。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 功能验证 | 核心用例执行完成，结果与预期一致，验收人已确认 | 验证报告、验收确认记录 | 测试负责人、业务验收方 |
| 监控与告警 | 关键指标有基线，观察时长达到约定，告警通道正常 | 监控记录、告警测试记录 | 运维负责人 |
| 用户反馈 | 反馈渠道明确，问题收集方式与责任人已告知 | 反馈渠道说明、问题登记记录 | 产品负责人 |
| 发布记录归档 | 发布单、执行记录、验证结论存放位置明确且可查 | 归档记录 | 发布负责人 |
| 遗留事项 | 未完成项、责任人与计划完成时间均已登记 | 遗留事项清单 | 发布负责人 |
监控观察时长要与业务节奏匹配，例如交易类系统需要覆盖一个完整业务高峰。遗留事项单独登记，避免混入下一次发布的变更清单后失去跟踪。
每项检查的通过标准与证据要求
检查项写成建议就无法判断是否完成。通过标准要可观察、可判断，例如“缺陷清单中无未关闭的严重级缺陷”，而不是“缺陷情况良好”。证据要能独立支撑结论，不依赖填写人的口头说明。
| 要素 | 写法要求 | 示例 |
|---|---|---|
| 通过标准 | 可观察、可判断，有明确对象和条件 | 回滚脚本已在预发环境执行成功并记录耗时 |
| 证据类型 | 发布单、评审记录、流水线执行日志、验证报告、监控截图 | 流水线执行日志含构建编号与时间 |
| 证据留存 | 位置与命名规则统一，能按发布单号检索 | 按“发布单号-检查项-日期”命名存放 |
| 不适用判定 | 写明理由与判定人 | 本次无数据库变更，由研发负责人确认 |
| 负责人字段 | 填写角色而非泛称，明确确认动作 | 运维负责人确认，而非“相关人员” |
负责人写角色，是因为人员可能轮换，角色对应职责稳定。确认动作要具体，例如“签字确认”“在发布单中标记通过”，避免出现“已知悉”这类无法判断的表述。
阻断项与放行条件
阻断项是无论其他项状态如何都不能放行的情形。清单中单独列出阻断项，评审时先看阻断项，再看其余检查项。
| 阻断项 | 判定人 | 解除条件 |
|---|---|---|
| 关键缺陷未关闭 | 测试负责人 | 缺陷关闭并有验证记录，或按风险接受流程批准 |
| 回滚方案缺失或未验证 | 运维负责人 | 回滚脚本执行成功并记录结果 |
| 审批未完成 | 发布负责人 | 审批人确认并记录结论 |
| 制品来源不明 | 研发负责人 | 制品与构建记录、校验值对应一致 |
带风险发布需要明确谁有权批准、记录哪些信息，通常包括风险内容、影响范围、接受理由和后续处置计划。放行结论要写明签署方式与生效时点，例如“评审会结束后由发布负责人在发布单中标记放行”。发布中止后，恢复发布需重新评审受影响的检查项，不能沿用中止前的结论。
把清单落到协作工具中的做法
清单要在发布过程中被使用，就需要与发布单绑定，而不是存放在个人文档里。常见做法是以版本发布单为父工作项，各阶段检查项作为子项或检查表字段，每项记录负责人、状态、证据链接与确认时间。
发布评审与审批记录挂接到同一发布单，评审结论、审批人和时间与检查项状态放在一起，便于放行时统一查看。发布完成后，发布单连同执行记录、验证结论一并归档，历史版本可按发布单号查询。ONES 可作为承载方式之一：用工作项组织发布单与检查项，用文档存放评审记录和验证报告，使检查状态与发布记录保持关联。具体字段与流程配置可按团队现有工作项体系设计。
常见问题
版本发布清单和发布单是什么关系，需要各做一份吗？
两者可以合并使用，也可以分层。发布单记录这次发布的对象、范围、审批结论和最终放行结果；清单是发布单下的检查明细，回答每项信息是否齐备、是否通过。实践中常见做法是以发布单为父工作项，把各阶段检查项作为子项或检查表字段挂在下面，这样放行时只需看一个入口。
如果团队已有独立的发布单模板，清单可以作为发布单的必填区块，不必另建文档。关键是两者使用同一发布单号，版本范围或制品变化时同步更新，避免清单与发布单描述不一致。
小团队发布频率高，每次都填完整清单会不会太重？
可以按发布风险分级裁剪，但裁剪的是检查项数量，不是判定方式。低风险的小版本可以合并部分检查项，例如把环境与依赖、部署步骤合并为一条执行核对；高风险版本或涉及数据库变更、第三方接口变更的发布，仍应保留回滚验证、灰度观察等关键项。
无论怎么裁剪，阻断项和放行结论都应保留。团队可以把常用检查项做成模板，发布时按类型套用，减少重复填写的工作量。
回滚方案在什么情况下可以判定为不适用？
回滚方案不适用通常出现在变更本身不可逆的场景，例如已执行且无法安全回退的数据迁移。这类情况需要由运维负责人和研发负责人共同判定，并在清单中写明理由、影响范围和替代处置方案，例如前向修复计划或数据备份恢复路径。
判定为不适用不等于跳过风险控制。评审时应确认替代方案已经过验证，并明确触发条件和决策人。若无法给出可执行的替代方案，应按阻断项处理。
发布中止后重新发布，清单需要全部重填吗？
不需要全部重填，但要重新确认受影响的检查项。中止后版本范围、制品或环境可能已经变化，与这些变化相关的检查项需要重新核对并更新证据，例如构建与制品、配置与数据变更、回滚准备。未受影响的检查项可以沿用原结论，并注明沿用依据。
重新发布前应重新走一次评审，由发布负责人确认哪些结论仍然有效、哪些需要更新，并在发布单中记录本次重新评审的时间和结论。
发布后观察多久才算完成收尾？
观察时长没有统一标准，应与业务节奏匹配。常见做法是覆盖一个完整业务周期，例如交易类系统覆盖一个业务高峰，内部系统覆盖一个工作日的主要使用时段。清单中应事先写明观察指标、观察时长和判断条件，而不是发布后再临时决定。
观察期结束后，由运维负责人确认关键指标在基线范围内、告警通道正常，再由发布负责人登记遗留事项并完成归档。若观察期内出现异常，按异常记录流程处置，处置结论一并归入发布记录。
