在传统的环境中,代码部署可能看起来像这样：

>将代码推到某个分段目录(旧代码仍然存在)
>针对数据库运行迁移(通常情况下,事先运行迁移更为安全,可以防范破坏代码的几个)
>从负载均衡器中取一半(或一部分服务器).
>将代码部署到这些服务器.
>如果可能,运行某种自动化烟雾测试/锻炼服务器,使他们“热”
>切换哪些服务器进出负载平衡器
>冲洗并重复.

对于Heroku,我几乎无法控制两个关键步骤：

>我无法首先运行数据库迁移.我认为解决这个问题的一个方法是保持数据库迁移分开,并将其推送到英雄首先 – 尽管痛苦的解决问题 – 但只会加剧…
> Dyno的启动时间可能需要相当长的时间 – 显然,这更像是Rails的错误,而不是Heroku,但关键的问题是我不能像上面的负载均衡器那样执行某些操作,以确保我的应用程序在新部署的服务器被放回到负载平衡器之前准备并加载.相反,我几乎别无选择,只能给用户一个10-15秒的加载屏幕,并希望最好的(如果我使用上面的数据库部署策略,那么TWICE)

我们现在使用维护屏幕,但如果我们进行全面的部署(我们可能每天有大约10-20个部署,而10-20 * 30秒的维护屏幕开始到加起来)

有人遇到类似的问题吗？你怎么解决他们？任何伟大的案例研究/成功案例,真正的连续部署在英雄？