That's the best solution I know of generally if you have migrations that break the previous install; however, many migrations (such as creating tables/columns) are backward-compatible and thus can be run while the app is still running under the older version of the code. This allows you to avoid any downtime at all, which is of course far preferable to downtime.
Peter, your proposed solution is (unfortunately) the best I can think of given Heroku's current capabilities; it might be possible to at least automate it, though, by doing a little git-fu: - Check out a temporary local branch based on the head of the Heroku remote - Do a diff between your new temporary branch and your deployment branch, only on the db/migrate directory. - Apply that diff as a patch to your temporary branch. - Push your temporary branch to Heroku. This will keep your application running in its current codebase, but with new migrations. - Run heroku rake db:migrate - Merge your temporary branch back into your deployment branch. This merge won't have any actual effect on your deployment branch's working copy, but you need to do this to keep the revision history consistent. - Push your deployment branch to heroku. I've never tried this and YMMV but that's how I'd tackle it. I think a simple way for Heroku to support a less painful way of doing this would be to give you control over whether the app automatically restarts after a push -- maybe based on a config var. Then it'd just be -- turn off auto-restart, push, rake db:migrate, restart, turn on auto-restart. Not sure how easy that'd be to deliver with Heroku's cloud internals though. Mat On Tue, Sep 7, 2010 at 14:13, Mike Abner <mike.ab...@gmail.com> wrote: > This isn't the best option, but you can put your app in maintenance > mode during the deploy/migrations and then put it back in service. It > makes continuous deployment a bit of a problem, but if you can deploy > during low traffic periods it would probably be ok. > > Mike > > On Tue, Sep 7, 2010 at 12:21 AM, Peter Marklund > <peter_markl...@fastmail.fm> wrote: >> I've been a heavy user of Capistrano before switching to Heroku and my >> typical workflow with database migrations is that I try to keep them >> backwards compatible and then do my deploy with cap deploy:migrations. >> That command will do a rake db:migrate before the deploy and abort the >> deploy if there are errors. >> >> Heroku doesn't seem to have anyting like deploy:migrations and the >> problem with running heroku rake db:migrate after the deploy is that >> that leaves a time window where I am receiving requests with the new >> code which is not compatible with the old schema. >> >> The only workaround here I can think of is to push the migrations >> first, then db:migrate, then push the code. That seems very awkward >> and far from the Heroku philosophy and I'm not even sure how to set >> that up with Git. >> >> Any suggestions? >> >> Thanks for an awesome service! >> >> Peter >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Heroku" group. >> To post to this group, send email to her...@googlegroups.com. >> To unsubscribe from this group, send email to >> heroku+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/heroku?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
