修改完成后的检查、发布与回退清单

AgentField 编辑整理｜发布准备指南。以虚构的表单校验变更说明流程；本次仅做隔离的本地 Git 验证，没有部署或回退真实环境。

假设这次只修改报名表单：名称为空时显示提示，不发送提交请求。发布记录需要回答三件事：将上线哪份变更、上线后怎样确认行为、出问题时怎样恢复。不能把“代码写完”或“构建通过”直接填成“用户已可使用”。

一、检查与本次变更对应的证据

先列出变更边界：空值提示、请求是否发出、有效输入是否仍可提交。用演示数据分别检查空值、只有空格和有效名称；记录实际结果，不能只测一个正常输入。

再核对完整待发布差异，避免顺带上线无关改动。工作区差异、已暂存差异和两个版本间的差异并不是同一范围。Git 的 diff --check 可发现空白错误等问题，但它不会替你验证表单逻辑。本文在临时仓库验证了尾随空白会被指出；没有把它称为功能测试。Git diff 官方说明

构建、自动测试、浏览器操作分别记录：检查对象、使用的版本、时间、结果和未覆盖范围。一次构建成功，只能作为该次构建的证据；浏览器验证未完成时如实保留待验项。

二、发布前准备能用的恢复路径

1. 确认目标：环境、服务、版本或产物标识、执行人，核对将上线的产物就是刚才检查的那一份。
2. 保存基线：当前运行版本、必要配置的受保护备份、受影响数据的备份范围。公开交接记录只写位置和标识，不贴密钥或数据内容。
3. 验证恢复条件：谁可以恢复、旧产物是否可取得、恢复需要哪些步骤。备份存在不等于已经证明能恢复；需要演练的，应在隔离环境检查并记录结果。
4. 约定停止条件：本例若空值仍发请求、有效输入无法提交或新增明显错误，停止继续扩大变更范围，进入回退或修复判断。

若平台支持逐步发布，可先让较小范围接收新版，比较约定指标后再扩大；具体机制依平台而定，不能假设项目已经具备。Google SRE 的渐进发布方法也强调用观测结果控制继续或停止。Google SRE：Canarying Releases

三、上线后验证用户实际走的路径

按发布前的用例重新检查目标地址：页面是不是新版、提示能否显示、空值是否被拦住、有效输入路径是否正常。涉及提交时使用明确允许的测试数据和范围，避免制造真实报名或业务记录。

页面、接口和资源的成功响应是各自证据；关键用户流程还要有实际结果。若只能取得服务端内容或接口数据，应明确浏览器画面与交互尚未验收，而不是补一句“页面正常”。

四、回退也要验收，记录也要闭合

代码撤销、应用版本恢复和数据恢复是三种不同动作。git revert 会记录撤销已有提交变更的新提交，不会替你完成部署或恢复数据库。隔离演示中，撤销代码提交后，未纳入 Git 的演示数据仍保持原值；这只是本地文件实验，不是数据库恢复证明。Git revert 官方说明

如果新版改变了数据结构，先确认旧版本与现有数据是否兼容，不能直接把“换回旧代码”当作完整方案。执行恢复后，核对运行版本并重走受影响流程，再决定是否恢复正常发布节奏。

变更与范围：本次修改、明确不包含的改动
发布对象：环境、版本或产物、执行人与时间
检查证据：构建 / 测试 / 浏览器各自结果
恢复准备：旧版本、备份位置、演练结果与限制
停止条件：哪个具体信号触发停止或回退
上线或回退结果：实际版本、用户流程、仍待验证项

可以用这份记录复盘一次小变更：哪一步有证据，哪一步只是计划。只有执行过并核对了结果，才把对应项改为完成。