回滚

在大多数部署失败的情况下，回滚错误代码并重新部署可能比运行 deploy:rollback 更合理。Capistrano 提供基本的回滚支持，但由于每个应用程序和系统对回滚的处理方式不同，因此需要由个人测试和验证回滚是否适用于其用例。例如，capistrano-rails 会在回滚时运行特殊任务来修复资产，但不会对数据库迁移进行任何特殊操作。

正确回滚发布是一个复杂的过程，它取决于应用程序的具体情况以及您组装的 Capistrano 插件。请提前做好准备，并在紧急情况下尝试回滚程序之前对其进行测试。

当执行部署时，Capistrano 会在所有服务器上一次执行一个任务，并在该任务完成之前不会继续执行下一个任务。如果某个服务器上的任务失败，Capistrano 会退出，而不会等待其他任务。在多服务器情况下，当某个服务器上的任务因以非 0 退出代码退出而失败时，Capistrano 会关闭与任何仍在进行的服务器的 SSH 连接，并且它们的 task 会退出。

如果错误发生在最终切换之前的部署任务期间，例如在创建符号链接期间，该过程将简单地停止，并且先前部署的应用程序将继续运行。但是，如果失败的部署任务是在 deploy:symlink:release 之后，在此期间 current 符号链接被移动到新部署的代码，这可能会导致不一致的状态，可以通过执行 cap [stage] deploy:rollback 来解决。回滚也可以解决由于代码错误或其他原因导致的部署失败问题。

根据 https://capistrano.ruby-lang.com.cn/documentation/getting-started/flow/，标准部署和回滚过程几乎相同。区别在于，在部署中，会执行 deploy:updating 和 deploy:updated 任务，而在回滚中，会执行 deploy:reverting 和 deploy:reverted（一个钩子任务）任务。此外，不是执行 deploy:finishing，而是执行 deploy:finishing_rollback，因为清理有时可能不同。

deploy:reverting

这首先将 release_path 设置为最后一个已知正常发布路径。它通过获取 releases 文件夹中的文件夹列表来实现，如果至少有两个文件夹，则将倒数第二个发布设置为 release_path。它还将 rollback_timestamp 设置为与该发布相同的发布，它用于日志条目。

设置完成后，其余标准部署任务会相应地翻转符号链接。

deploy:finishing_rollback

为了完成回滚，Capistrano 会在部署路径中创建失败发布的 tarball，然后删除发布文件夹。

deploy:failed

在 cap [stage] deploy 失败的情况下，会调用 deploy:failed 钩子。您可以在此钩子中添加自定义回滚任务。

after 'deploy:failed', :send_for_help do
  #
end

这与专门调用的回滚不同，并且是特定于应用程序的。出于上述原因，在没有仔细测试的情况下使用此钩子可能很危险。

deploy:rollback ROLLBACK_RELEASE=release

使用 ROLLBACK_RELEASE 环境变量回滚到特定发布。

例如：cap staging deploy:rollback ROLLBACK_RELEASE=20160614133327