我在使用 capistrano 运行生产部署时遇到了问题。我们刚刚完成了一个包含大量数据库迁移的大型重构。
在部署期间，最糟糕的事情发生了，我的 ssh 连接断开了，而 cap 正在运行迁移。
我认为通过我们的负载均衡器进行 SSH 连接存在问题，但这不是重点。
我通过在服务器上运行屏幕、在此处迁移并随后进行部署，设法使迁移完全运行。
应用程序现在已经启动并且似乎工作正常，但我只是想知道如果连接中断，是否有人知道 capistrano 如何处理迁移？
我可以确定连接断开时执行的迁移完成了吗？
执行一半或执行两次迁移的可能性有多大？
我会假设 cap 将每个迁移包装在一个 db 事务中，如果发生错误会回滚，会是这种情况吗？
【问题讨论】：
标签： ruby-on-rails deployment capistrano
失去 SSH 只是意味着您无法访问实例，但实例和命令已经（并且仍在）运行。
Capistrano 只会在后台执行 rake db:migrate，这基本上意味着您可以依赖迁移完全运行完成或发现错误。即使进程停止，由于每次迁移后架构都更改了，迁移也不会再次运行。如果它被停止，那么架构不会改变，当您（或 capistrano）再次运行rake db:migrate 时，会提示再次运行迁移。
如果您想始终确保不会出现问题（或可以有效地处理）完全可逆的写入迁移 - 这可以确保在迁移错误时 rake 可以回滚之前运行的迁移（运行在与调用错误）。通常大多数迁移默认情况下都是可逆的，无需额外代码，但如果您有更复杂的行为，他们可能需要编写特定的反向方法（例如，您正在更改列并将值转换为其他内容）。默认情况下唯一不可逆的是表/列删除，除非您将类型添加到remove 语句，因为它在删除时是可选的。如果存在column type，那么rails 也将知道如何恢复drop（不需要特定的reverse 方法）。
【讨论】：
db:migrate，它将从第一个“未运行”迁移开始并从那里开始。我会假设数据库本身（除了 rails、ruby 和 rake）对non-persisted 更改的故障具有保护，无论是记录本身（ACID）还是模式/表。