I'd also like to point out that as someone who deploys php and puppet
manifests via cap having a migration run on every deploy would only fill my
logs with errors!
M
On 3 Jan 2012 16:42, "Lee Hambley" <lee.hamb...@gmail.com> wrote:
> 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
> * 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
>
>
> --
> * 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
--
* 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
