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.

Reply via email to