推送到Heroku的一个不好的方面是我必须在运行数据库迁移之前推送代码（并且服务器会自动重启）。
这显然会导致用户在没有新表/属性的情况下浏览具有新代码的网站时出现大约500个错误：Heroku提出的解决方案是使用维护模式，但我想要一种没有缺点的方法让我的webapp运行每次！
有办法吗？例如，使用Capistrano：
......我没有停机时间！
答案 0 :(得分：22)
您可以设置第二个Heroku应用程序，该应用程序指向与主要生产应用程序相同的数据库，并使用辅助应用程序在不中断生产的情况下运行数据库迁移（假设迁移不会破坏以前版本的应用程序）。
让我们称Heroku应用 PRODUCTION 和 STAGING 。
您的部署顺序将类似于：
git push heroku staging heroku run -a staging-app rake db:migrate git push heroku production 暂存应用程序不会花费你任何费用，因为你不需要超过Heroku的免费等级，设置一个rake部署脚本为你自动执行此操作将是非常简单的。
祝你好运！答案 1 :(得分：11)
如果您能够同时使用同一个应用程序的两个版本，Heroku现在具有预启动功能。
答案 2 :(得分：5)
改善这个过程的唯一方法就是这个家伙的建议。但这仍然不是热部署方案：
http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/
我建议的一件事是首先将您的迁移推送到Heroku并在推送代码库之前运行它们。这将需要将迁移作为独立提交提交并每次手动推送它们（这不是理想的）。我很惊讶现在Heroku上托管的所有大型应用程序都没有更好的解决方案。
答案 3 :(得分：3)
当Heroku重新启动你的应用时，你实际上会有一些停机时间。他们有一个名为Preboot的新功能，可以在取出旧dynos之前启动它们：https://devcenter.heroku.com/articles/labs-preboot/
对于数据库迁移，该文章链接到有关如何处理该问题的文章：http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
答案 4 :(得分：1)
我首先提交迁移，运行它们，然后推送剩下的代码。像这样添加一个文件：
git commit -m 'added migration' -- db/migrate/2012-your-migration.rb
答案 5 :(得分：0)
Heroku无法通过capistrano部署。你是heroku发布的工具。
在所有情况下都不可能没有停机系统。如何在不停止服务器的情况下通过大变更来更改架构。如果不停止它，可以避免一些更改，并且数据库可能不一致。因此，使用维护页面是一种常规解决方案。
如果你想要一个小解决方案，以避免问题是两个服务器的平衡。迁移期间只有一个只读数据库的数据库。您可以在迁移期间切换到此实例，避免维护页面。迁移后，您将回到主人那里。
答案 6 :(得分：0)
目前我认为没有停机时间可以做到这一点。我也讨厌它。
此控制台命令在我能想到的最短时间内完成
git push heroku master &&
heroku maintenance:on &&
sleep 5 &&
heroku run rails db:migrate &&
sleep 3 &&
heroku ps:restart &&
heroku maintenance:off
git push heroku master将主分支推送到heroku heroku maintenance:on进行维护，所以没有500s sleep 5让dynos启动新代码（没有它，迁移可能会失败）heroku run rails db:migrate进行实际迁移heroku ps:restart根据经验，重启确保新dynos具有最新架构heroku maintenance:off轮流维护如果您有多个应用，则可能必须在所有heroku命令后添加-a <app name>。
只需一个命令就可以在Mac OSX上的终端中串行运行这些命令。