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.
