Why doesn't `deploy` run migrations?

[Matt]

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

[Lee Hambley]

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

--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en

[Matthew Macdonald-Wallace]

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

[Donovan Bray]

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"

--

[Donovan Bray]

Adding the after hook in your deploy.rb may be too late because of callback execution ordering. This could cause your migrations to attempt to run before you've ensured the database.yml is correct, which is why I suggested using a before deploy:symlink in my previous post. This ensures any hooks placed on update_code are done before migrations try to run. 

[Matt Rogish]

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

[Lee Hambley]

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

[Matt Rogish]

Lee,

I understand. Capistrano has been awesome - been using it for years and years now - and I absolutely understand there are countless thousands of apps (or more!) using it and it's far too ubiquitous to make any major changes. If only my apps were as popular! :)

Keep up the great work and look forward to seeing what you create!

Thanks,

-- 
Matt

[Lee Hambley]

Matt, Thanks for the support! (And everyone thinks open source mantainership is for rockstars!)