Rake db:migrate should run for all environements

Rails
1

Or at least development and test. How many times did I find myself
banging my head on the table with buggy tests until I figured out that I
had forgotten to migrate the test database.

Why rake db:migrate doesn’t by default migrate all environments at the
same time?

2

Because maybe you don’t want it to happen all at once, maybe you need
to stage things. Imagine you’re developing new features for an
existing system, and you create some destructive migrations. You want
those to automatically affect your other environments when you might
not even be done writing and testing code?

A better idea is to realize that these processes are separate and
manual and get in the habit of doing it yourself. Plus, if you just
use “rake” instead of running a specific test, rake will warn you that
you have pending migrations.

On Feb 2, 5:47 pm, Fernando P. [email protected]

3

I do think that Fernando has a valid point. There is, for example,
already a rake task that can create all of your databases at once,
namely rake db:create:all. A rake db:migrate:all might be a
useful thing to have. That being said, it would be pretty trivial to
code this yourself.

Greg

4

Greg wrote:

I do think that Fernando has a valid point. There is, for example,
already a rake task that can create all of your databases at once,
namely rake db:create:all. A rake db:migrate:all might be a
useful thing to have. That being said, it would be pretty trivial to
code this yourself.

Greg

I have to disagree. It’s one thing to create the initial empty databases
and yet another to migrate them all. These should be kept separate just
as Jeff explained.

The normal workflow would be to (1) migrate your development database,
(2) prepare your test database (rake db:test:prepare), (3) run your
tests, and finally (4) migrate your production/staging database as part
of your deployment process/script.

You want your test database to begin in a known state, which is what
db:test:prepare gives you. You want to migrate your development database
forward for experimentation. And you only want to migrate your
production database after all tests pass and your ready to deploy a
release.

5

How in heck can people say that the migration of test_db and dev_db have
to be kept separate? These 2 DBs must be in sync (tables, columns) at
all time.

Hardly… I want my QA people working on their tests for the last set
of changes I gave them.

Once the test DB is migrated, and MY tests pass, then they have at it
with their oh so wonderfully oddball “Well, what if I do this?”
scenarios…

In the meantime, I want to continue on with my work.

6

The normal workflow would be to (1) migrate your development database,
(2) prepare your test database (rake db:test:prepare), (3) run your
tests, and finally (4) migrate your production/staging database as part
of your deployment process/script.

For f*!k sake!!! I just wasted 2 hours banging my head on the table, I
had forgotten to do RAILS_ENV=test rake db:migrate!!!

How in heck can people say that the migration of test_db and dev_db have
to be kept separate? These 2 DBs must be in sync (tables, columns) at
all time.