Segmenting migrations based on target environment

I am developing against an existing database schema that I am enhancing
with some custom tables.

In the development and test database, I have basically generated
“copies” of the legacy tables that already exist in production. So I
have 12 migration files, some of which create dev/test versions of
production tables and some of which create tables that will need to be
moved to production since they are new.

I would like to have a separate set of migrations for the production
platform which is a subset of the set of migrations for my dev/test
platforms. Is there any built-in method for doing this with migrations
today (like some subdirectory convention, etc.) or do I have to roll my
own management scheme.

One simple solution I came up with was to compress my 12 migration files
into 2 files - 1 for the dev/test “copies” of legacy tables, and 1 for
the new tables that I’m adding. Then I just run the “new” migration
against the production DB.

But I’d really like to automate this so that I can have a capistrano
task that does migration as part of deployment to test and deployment to
production and have the migrations be correct in both environments.

Any migration gurus have any insight?


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs