Re: push without restart
Just something else to note that we have seen, is that after running a migration we have had to *issue a restart* to correct odd behaviour with the new or changed table column. On Tue, Aug 9, 2011 at 6:42 AM, John Beynon wrote: > This isn't something that has affected myself but in selling Heroku to the > other devs at my workplace one thing that people dislike about the Heroku > workflow is that the application is restarted after a code push before > migrations may have been run. They are used a Capistrano style deployment > when the the code is pushed, migrations run and then the app restarted. > > What should I tell them to alleviate concerns? I'd have thought use > maintenance mode, deploy the code, do the work and then migrate it then > bring the application back up - > > Any one else have any thoughts? > > John. > > > -- > 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/-/ozy2gnNXQtoJ. > To post to this group, send email to heroku@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. > -- Shane Mingins -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to heroku@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.
Re: push without restart
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 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 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 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 > > 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 heroku@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 heroku@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 heroku@googlegroups.com. > > > To unsubscribe from this group, send email to > > heroku+unsubscr...@googlegroups.com. > > > For more options, visit this group at > >http:
Re: push without restart
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 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 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_downtime/ > > > > 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 > 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 heroku@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 heroku@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 heroku@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 heroku@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googleg
Re: push without restart
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 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_downtime/ > > 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 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 heroku@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 heroku@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 heroku@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 heroku@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.
Re: push without restart
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_downtime/ 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 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 heroku@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 heroku@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 heroku@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.
Re: push without restart
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 heroku@googlegroups.com > (mailto:heroku@googlegroups.com). > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com > (mailto: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 heroku@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.
Re: push without restart
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 heroku@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.
Re: push without restart
You could try a script like Kumade and patch it so that it always does a restart after migrating: https://github.com/thoughtbot/kumade On Mon, Aug 8, 2011 at 2:42 PM, John Beynon wrote: > This isn't something that has affected myself but in selling Heroku to the > other devs at my workplace one thing that people dislike about the Heroku > workflow is that the application is restarted after a code push before > migrations may have been run. They are used a Capistrano style deployment > when the the code is pushed, migrations run and then the app restarted. > What should I tell them to alleviate concerns? I'd have thought use > maintenance mode, deploy the code, do the work and then migrate it then > bring the application back up - > Any one else have any thoughts? > John. > > > -- > 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/-/ozy2gnNXQtoJ. > To post to this group, send email to heroku@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 heroku@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.
push without restart
This isn't something that has affected myself but in selling Heroku to the other devs at my workplace one thing that people dislike about the Heroku workflow is that the application is restarted after a code push before migrations may have been run. They are used a Capistrano style deployment when the the code is pushed, migrations run and then the app restarted. What should I tell them to alleviate concerns? I'd have thought use maintenance mode, deploy the code, do the work and then migrate it then bring the application back up - Any one else have any thoughts? John. -- 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/-/ozy2gnNXQtoJ. To post to this group, send email to heroku@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.
