Deployment Rollback
部署回滚
部署回滚是发布失败或不安全后的恢复方式。它会用受控方式，恢复已知正常的版本和兼容状态。实际步骤按部署平台和数据改动而不同。
另一个例子
发布 3.2 后，错误率增加五倍。上一版 3.1 和数据结构仍兼容。自动流程恢复 3.1、检查服务健康和流量，并记录事故。只在源码做 Revert，不能撤销已部署文件或不可逆数据改动。它也不能撤销排队任务或外部影响。
主要部分
- 01回滚触发条件
- 02已知良好 artifact 与 state
- 03恢复后验证
什么时候用
发布健康指标超过预定门槛，而且能安全恢复到测试过的正常版本时，可以使用这个词。
什么时候不要用
先测试数据结构是否兼容。也要检查有状态任务、外部影响、监控和继续修复的条件。完成前，不要承诺一键回滚。
代码里的名称
health threshold → restore known-good artifact → verify 上线前要检查
发布前核对正确的代码仓库、分支、目标与代码差异。保留尚未发布的工作，并通过审查与自动检查（CI）。记录冲突、数据丢失风险、发布顺序、版本追踪、恢复与回到上一版的方法。
预期结果：用 部署回滚 (Deployment Rollback) 安全交付或恢复变更，并留下可审核记录。 用户场景：发布 3.2 后，错误率增加五倍。上一版 3.1 和数据结构仍兼容。自动流程恢复 3.1、检查服务健康和流量，并记录事故。只在源码做 Revert，不能撤销已部署文件或不可逆数据改动。它也不能撤销排队任务或外部影响。 交付概念或操作：部署回滚 (Deployment Rollback)。 适用理由：发布健康指标超过预定门槛，而且能安全恢复到测试过的正常版本时，可以使用这个词。 不应使用的情况：先测试数据结构是否兼容。也要检查有状态任务、外部影响、监控和继续修复的条件。完成前，不要承诺一键回滚。 交付要求：指出代码仓库与目标。列出前置条件、变更内容、审查与自动检查（CI）、冲突和数据丢失风险、发布顺序，以及恢复或回到上一版的命令。 仓库防护：保留尚未发布的工作与可审核历史。没有明确备份时，不得执行破坏性操作。发布前核对准确的代码差异与远程仓库目标。 验收标准：预期的代码差异已审查，必要检查已通过。目标版本可追踪，失败恢复已演练，发布历史也可审核。 证据与限制（证据边界）：它只代表该来源的官方说法。其他平台或团队可能有不同用法。 待确认：代码仓库与分支、协作状态、发布环境、批准负责人、受保护的检查，以及要恢复的版本。
检查这份需求
请 AI 编程助手检查当前如何使用 部署回滚 (Deployment Rollback)。 定义：部署回滚是发布失败或不安全后的恢复方式。它会用受控方式，恢复已知正常的版本和兼容状态。实际步骤按部署平台和数据改动而不同。 生产环境检查：发布前核对正确的代码仓库、分支、目标与代码差异。保留尚未发布的工作，并通过审查与自动检查（CI）。记录冲突、数据丢失风险、发布顺序、版本追踪、恢复与回到上一版的方法。 修改程序前，先列出看到的证据、缺口、严重程度，以及最小且安全的修正。