Matt,
The original (and standing) reason is that most "toy" projects can get away
with running migrations on every deploy, but for larger organisations, and more
complicated projects which use Capistrano we expect professional developers to
know what they are doing, and not run migrations (which can quite easily take a
system offline) at deploy time unless they ask for it.
Possibly destructive changes to a database which might cause downtime should
always be opt-in, not opt out.
Naturally if someone is using Capistrano with Git/Subversion/other - then no
changes to the code are destructive, resources can be rebuilt, etc; but the
database holds such a massive potential for downtime that it's not worth
risking it.
At this point in Capistrano's history (some 5 years after it was first gaining
wide acceptance) - I think it would be foolish and unwise to change the
default, as at least I rely on the behaviour.
It's certainly even a difference between PostgreSQL and MySQL, the two behave
very differently regarding large table changes, there is no "safe" default.
I would suggest a compromise that a variable be made available that would cause
migrations to run after you `deploy`, if that would help ease the transition
for everyone.
It's worth pointing out that the API is flexible enough that you can easily
hook migrations to `after('deploy:update_code')`, which is effectively what
`deploy:migrations` does.
Thanks for brining this up Matt, I'd look forward to a patch, or further
discussion if you are so inclined!
- Lee
On Tuesday, January 3, 2012 at 5:36 PM, Matt 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
* 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
