回滚部署

If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…

如果部署破坏了生产环境，您可以在几秒内将早期的构建版本重新推向流量，无需重新构建任何内容。本指南介绍了回滚的工作原理、如何选择合适的部署、Orbit 可以为您执行的自动回滚，以及回滚后的操作步骤。

回滚的工作原理

Orbit 保留每次成功构建的打包构件。回滚不会重新运行您的安装或构建命令：它推送一个已经存在且已经被提供过的构件，因此它在几秒内完成，不会因为构建可能失败的任何原因而失败。

这正是首先使用它的原因。回滚速度更快，比在站点损坏时尝试向前修复要可靠得多。

回滚到以前的部署

在 Orbit 中打开您的项目。
打开 Deployments 选项卡。
找到您所知的最后一个良好部署。
点击该行上的 Roll back 并确认。

确认会准确说明将发生的情况：流量将立即从较早的构建版本提供，当前部署将被取代。

Deployments 选项卡的回滚操作

您也可以从部署自身的详情页面进行回滚，按钮上的文本为 Rollback to 后跟短提交哈希值。

恢复的部署获得 CURRENT 徽章。您回滚离开的部署保留在历史记录中，状态为 Rolled back。

回滚不具有破坏性，无需撤销。不会删除任何内容，历史记录不会被改写，您的存储库保持不变。您下次成功推送到生产分支的内容以正常方式成为新的实时版本。

识别正确的部署

Deployments 选项卡上的每一行显示提交消息和短哈希值、分支、状态、部署时间以及推送者。实时的部署带有 CURRENT 徽章。

通常您希望选择导致问题的部署之前的部署。两项功能可以帮助您确认：

Compare（比较）。 打开可疑部署并点击 Compare 将其与前一个进行对比：构建时间、构件大小、缓存状态、框架以及文件级构件差异。
Deployment notes（部署备注）。 任何部署都可以携带最多 500 个字符的备注。在部署时添加"修复支付错误的热修复"或"功能标记 X 开启"成本为零，几个月后会使历史记录变得易读，这正是您需要它的时候。

回滚到构件不会回滚您的环境变量、重定向规则或响应头。这些在请求时或构建时读取，不会被烘焙到构件中。如果事件是由配置更改而不是代码更改引起的，回滚代码将无法解决。部署详情页面将在构建时注入的变量与您当前的配置进行对比，这是区分两者的最快方式。

自动回滚

Orbit 可以在您甚至没有注意到之前为您执行此操作。所有三项设置都在 Settings 中。

故障时自动回滚

在 Runtime 下，打开 Auto-rollback on failure。如果生产部署失败，最后一个健康的部署会自动恢复，访问者不会看到停机时间。Staging 有自己的等效开关。

健康检查

在 Health check 下，设置 Health check path，例如 / 或 /api/health。每次生产部署后，Orbit 会获取该路径。如果它在 15 秒内没有返回 2xx 响应，先前的健康部署将被恢复。

烟雾测试

在 Smoke tests 下，列出最多 10 个逗号分隔的路径，例如 /,/blog,/api/health。每次成功部署后，Orbit 会向每个路径发送 GET 请求并记录通过或失败。如果任何失败且启用了自动回滚，先前的部署将被恢复。结果在部署页面上显示为 Smoke tests passed 或失败计数，当其导致回滚时显示 Triggered rollback。

对实际上调用您的数据库的路由进行健康检查的价值远高于对主页的检查。一个损坏的部署仍然可能提供缓存的主页，将通过 / 检查但失败真实检查。

回滚与部署锁定

如果您还没有准备好回滚，但想在调查时阻止任何新内容上线，请改为锁定部署：

打开项目。
点击 Lock deploys。
添加原因，例如"调查生产问题"。

推送触发的部署随后会被无声地跳过，横幅会显示 Production deploys are locked 和您的原因。手动部署仍然有效，这是有意的：锁定阻止意外部署，而不是您正在发布的修复。点击 Unlock deploys 来解除它。

锁定和回滚配合得很好。首先回滚以恢复服务，然后锁定，以便在您诊断时没有人的例行合并撤销它。

将 Staging 推送到生产环境

如果您运行 staging 环境，您可以将经过测试的 staging 构建放入生产环境，而无需推送任何内容。

打开项目概览并找到 Staging 部分。
如果 staging 领先于生产，Promote to production 会出现。
点击它并确认。

仔细阅读确认，因为 Orbit 中有两种不同的推送行为，它们不可互换。从项目概览推送触发同一提交处的 fresh production build，使用生产环境变量和生产构建命令。不会重用 staging 构件。从其详情页面推送特定的 staging 部署明确说明 staging 构建立即上线，无需重新构建。如果您的 staging 和生产环境变量不同，第一种方式将产生与您测试的构件不同的构件。

Orbit 也可以为您推送。Settings 中的 Auto-promote staging 在 staging 健康且烟雾测试通过数小时后将 staging 推送到生产，每 15 分钟检查一次。

回滚后

在您的存储库中修复潜在问题并推送新提交。这将触发成为新实时版本的正常构建。如果您锁定了部署，请先解除锁定，否则推送将被跳过。

项目的 Activity 选项卡记录了回滚以及发生的所有其他内容，因此有一份审计跟踪记录了谁在何时回滚了什么。

限制您可以回滚的距离的因素

回滚需要构件仍然存在。两项设置控制这一点：

您的计划的部署历史窗口：Launch 上为 7 天，Liftoff 上为 30 天，Apex 上为 90 天。
项目的 Artifact retention 设置，它为每个环境保留成功构件的数量，从 10 到 500，默认为 50。

当前实时部署的构件无论如何都始终保留。

如果您每天部署多次，构件计数是您首先会遇到的限制，而不是天数计数。五十次部署可能只是一周。提高 Artifact retention 而不是在事件发生时发现上限。