Sounds like Heroku could make this available for apps that don't use a [SQL?] DB.
On Aug 30, 11:13 pm, Peter van Hardenberg <[email protected]> wrote: > This totally sucks. I see no reason we can't write software which can help > take care of this and provide superior versioning in the system. Ultimately > the lesson here is that all cloud services need to be capable of being in > intermediate states (or reverting part way through!) during all deploys. > This is something that is easy to ignore on a new or smaller app, but > becomes increasingly clear as your dataset grows into the hundreds of gigs. > > Surely there is a careful thinker among us who can put their brain to work > on what is really an essential problem: how to make database schemas and > ORMs cooperate with version control/software releases? > > -pvh > > > > > > > > On Tue, Aug 30, 2011 at 9:10 PM, Tom O'Neill <[email protected]> wrote: > > In a sufficiently large/complex environment db and code changes > > necessarily happen at different times, even if you try to make them > > happen together. So one of the changes (code or db) needs to be > > backwards compatible each release - push the backwards compatible > > change first and then the other. Turns deployment into a 2-step > > process, but it's easy enough on the Heroku stack. > > > On Tue, Aug 30, 2011 at 6:42 PM, Pedro Belo <[email protected]> wrote: > > > Hey guys, > > > > We have a lot of interest on this subject at Heroku, if anything > > > because we use the product every time we can and we understand that > > > having to put the app on maintenance mode every time you deploy a > > > migration is not acceptable. > > > > That said, the problem with migrations like Mike said goes a bit > > > further - a big part of it is that most migrations are just not safe > > > to be executed against a live system, and on that front I don't > > > believe there's a lot we can do. You just need to carefully design > > > your migrations and change your deploy process to accomodate them - > > > something I tried to convey on this blog post: > > >http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_do... > > > > If you're designing your migrations with hot compatibility in mind, > > > the workflow imposed by Heroku should work - although it definitely > > > comes with effort. > > > > Well, let me know if you have any feedback on this topic, I'd love to > > hear it. > > > > Thanks, > > > Pedro > > > > On Tue, Aug 30, 2011 at 4:53 PM, Mike Abner <[email protected]> > > wrote: > > >> 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]. > > >> 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. > > > >> -- > > >> 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. > > > > -- > > > 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. > > > -- > > 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. -- 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.
