Matt, Certainly, "continuous deployment" is a luxury few of us are afforded, I've mostly worked at places where the deploy is weekly, and that's as agile as we can get. The PHP crowd are another group who benefit. (although, for what it's worth Matther Macdonald-Wallace, I have a project called "Railsless-Deploy" which is the normal deploy, minus all the railsisms)
My standard opinion is that the usage of Capistrano is too wide and varied for me to be in a position to make any major leaps in functionality or behavior, which is why I'm focusing my efforts on writing a better underlying SSH driver, with a more sane API, which works the way most people are [mis]using Capistrano; my hope being that somewhere on top of that API can be a cookie-cutter Rails deployment with sane hooks for people. This project, when [or rather if, with my schedule the way it is] comes to fruition, I will be running a long, long pre-release phase, to try and come up with sane defaults that work for most people according to the way things work in 2011. Matt, you're not alone in thinking it's a little odd, either - I quite often forget to run migrations, and blow the production sites I work on up, with forgotten migrations… worse yet is when I've been out of the office a few hours, and the quite finally quietens down, Passenger mod_rails unloads the app… and it won't come back up! Here's to a brighter future. -- Lee Hambley Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, January 3, 2012 at 9:50 PM, Matt Rogish wrote: > If I (and by "I", I mean, what I've seen done and what we do now at my > current organization) have a migration that *must* be run before the site > comes back up, then it has to be run as part of the deploy; the site *should* > be down whilst it's doing whatever it is doing. In my experience, those are > usually ReallyBigDeals(™) and planned and scheduled in advance, and are the > exception, not the rule. Usually not something that is just coincidentally > run as part of a regular deploy. > > Preferably, though, I have a migration that can be feature-flagged away (or > some sort of "zero-downtime db deployment" techniques) so the lack of it > running won't break prod; then it's run as a background task thru a > predefined process/queue and then the feature enabled/toggled once > everything's in place & verified working OK. > > Still, I object that only "toy" apps are expected to have migrations run > automagically; I'd also argue that the premise of "professional developers > know what they are doing" doesn't necessarily lead to "don't run migrations > for them", but I think reasonable people could disagree. > > In a continuous deployment environment it's not just one person deploying a > massive release; we may do more than one a day (although typically not) and > they may or may not contain migrations. It seems to me that deploying with > potentially explosive "pending" migrations is very dangerous & not scaleable, > considering anyone could then run `cap deploy:migrations` and then execute > *yours* - oops! > > A big point of continuous deployment, continuous integration, agile, etc. is > that annoying or painful things should be done more often so they become less > painful (via automation, etc.); having feature flags/0-downtime migrations > seems to be the way I'd handle "breaking" migrations - relying on someone > "not running :migrate" seems like a smell more than a best-practice. > > In any rate, I didn't mean for my initial comment to be a feature request - I > know I can simply hook into after deploy; just looking for an additional > perspective on the matter. And I think I got it - there are a lot of people > out there doing different deploy methods and I failed to take that into > account. > > Thanks, > > -- > Matt > > > On Tuesday, January 3, 2012 at 11:56 AM, Donovan Bray wrote: > > > Because if you want to deploy with migrations there's a task for that > > > > deploy:migrations > > > > That gives you the ability to choose what's best for your situation > > > > deploy > > (site comes back up) > > deploy:migrate > > > > For long running migrations > > > > Or > > > > deploy:migrations > > (site comes back up) > > > > Or > > > > deploy > > (site comes back up) > > > > Fastest deploy when you know you don't have migrations. > > > > You can also change the normal deploy to always do migrations. > > > > before "deploy:symlink", "deploy:migrate" > > > > On Jan 3, 2012, at 8:36 AM, Matt <matt.rog...@gmail.com > > (mailto:matt.rog...@gmail.com)> wrote: > > > > > Hi, > > > > > > Just curious - why is the default for `cap deploy` to *not* run > > > migrations? > > > > > > I accept that there may be some circumstances in which you'd want to skip > > > migrations on a deploy (long-running migrations you'll run later, I > > > guess?). But, in my years of deploying many many different rails apps, I > > > can only think of a handful of times I've wanted to deploy but not run > > > migrations. And even then, it was probably best done as a separate rake > > > task. > > > > > > Indeed, whenever I start a new rails project I use RailsMachine's > > > excellent "moonshine" which runs migrations automagically. I don't even > > > know if there's a way to disable migration running on moonshine? > > > > > > In any rate, it seems like it would best be done the other way around - > > > `cap deploy` does migrations, too, and `cap deploy:nomigrations` does > > > what it says. Is there something I'm missing? > > > > > > Thanks, > > > > > > -- > > > Matt > > > > > > -- > > > * You received this message because you are subscribed to the Google > > > Groups "Capistrano" group. > > > * To post to this group, send email to capistrano@googlegroups.com > > > (mailto:capistrano@googlegroups.com) > > > * To unsubscribe from this group, send email to > > > capistrano+unsubscr...@googlegroups.com > > > (mailto:capistrano+unsubscr...@googlegroups.com) For more options, visit > > > this group at http://groups.google.com/group/capistrano?hl=en > > > > -- > > * You received this message because you are subscribed to the Google Groups > > "Capistrano" group. > > * To post to this group, send email to capistrano@googlegroups.com > > (mailto:capistrano@googlegroups.com) > > * To unsubscribe from this group, send email to > > capistrano+unsubscr...@googlegroups.com > > (mailto:capistrano+unsubscr...@googlegroups.com) For more options, visit > > this group at http://groups.google.com/group/capistrano?hl=en > > -- > * You received this message because you are subscribed to the Google Groups > "Capistrano" group. > * To post to this group, send email to capistrano@googlegroups.com > (mailto:capistrano@googlegroups.com) > * To unsubscribe from this group, send email to > capistrano+unsubscr...@googlegroups.com > (mailto:capistrano+unsubscr...@googlegroups.com) For more options, visit this > group at http://groups.google.com/group/capistrano?hl=en -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to capistrano@googlegroups.com * To unsubscribe from this group, send email to capistrano+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
