This requires TWO, and this is not trivial.
1) Migrations must be backward compatible (i.e., performed while the application is active). See this article about this: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
2) Deployment using two heroku applications. I opened a ticket with Heroku on this topic, and that was their answer:
We are currently working on a solution that provides zero downtime but does not have an ETA when it may be available.
In the meantime, a workaround that might be possible is to deploy to two separate applications. You can click the new code on the second application, unscrew it, then move the domain names to the second application. Wash and repeat the next time you deploy. This is less than ideal, but may have the desired result in the interim.
If you do this, you will want to automate as much as possible, as there are many ways to ruin this. Here is an article on this topic: http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/
Why?
Both of these solutions should be implemented , because database migration should work in BOTH code versions (live and to-be-live). Once you get started, THEN you can solve the second problem when the application does not seem to have come down. There is no supported way to turn and rotate individual speakers after triggering a click.
UPDATE: Now with Heroku there is a beta function. To use, follow these steps before clicking:
heroku labs:enable -a APP_NAME preboot
This will change the behavior of the application during click. He will push a parallel instance, which will warm up for two minutes. Almost exactly two minutes after clicking, all traffic will go to a new application. Be careful with migrations, as I mentioned above, as they still remain a problem.