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 <[email protected] > (mailto:[email protected])> 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 [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/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 [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/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 [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
