We're thinking about having a migrations branch where we put all migrations. They get merged to master first, then pushed and run, and then after those complete we merge the new code to master and push again.
It does mean that you have to spend more time and effort dealing with data model changes and not making breaking changes in the data model. For instance, if you want to change a column name you have to have a migration that creates a new column and moves all the data over and then after you push your new code you have to write a migration to remove the old column/data. It's more work and takes more planning/discipline, but I don't think it's that big of an issue given the ease of just about everything else on the heroku platform. Mike On Tuesday, August 30, 2011 at 4:34 PM, Jonathan Owens wrote: > That only half solves it by forcing downtime you'd be taking anyway because > your app is likely to crash if started before the migrations run, as you are > forced to do. Having to take downtime just to add a field is pretty lame. > > We're looking at running our migrations from an EC2 server since we use RDS. > Heroku-hosted postgres could make that more tricky. > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/heroku/-/IsBLMKs4c0sJ. > To post to this group, send email to [email protected] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]). > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
