Is it a good idea to purge old Rails migration files?

Question

I have been running a big Rails application for over 2 years and, day by day, my ActiveRecord migration folder has been growing up to over 150 files.

There are very

Answer 1

See http://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you

Migrations are not a representation of the database: either structure.sql or schema.rb is. Migrations are also not a good place for setting/initializing data. db/seeds or a rake task are better for that kind of task.

So what are migrations? In my opinion they are instructions for how to change the database schema - either forwards or backwards (via a rollback). Unless there is a problem, they should be run only in the following cases:

1. On my local development machine as a way to test the migration itself and write the schema/structure file.
2. On colleague developer machines as a way to change the schema without dropping the database.
3. On production machines as a way to change the schema without dropping the database.

Once run they should be irrelevant. Of course mistakes happen, so you definitely want to keep migrations around for a few months in case you need to rollback.

CI environments do not ever need to run migrations. It slows down your CI environment and is error prone (just like the Rails guide says). Since your test environments only have ephemeral data, you should instead be using rake db:setup, which will load from the schema.rb/structure.sql and completely ignore your migration files.

If you're using source control, there is no benefit in keeping old migrations around; they are part of the source history. It might make sense to put them in an archive folder if that's your cup of coffee.

With that all being said, I strongly think it makes sense to purge old migrations, for the following reasons:

• They could contain code that is so old it will no longer run (like if you removed a model). This creates a trap for other developers who want to run rake db:migrate.
• They will slow down grep-like tasks and are irrelevant past a certain age.

Why are they irrelevant? Once more for two reasons: the history is stored in your source control and the actual database structure is stored in structure.sql/schema.rb. My rule of thumb is that migrations older than about 12 months are completely irrelevant. I delete them. If there were some reason why I wanted to rollback a migration older than that I'm confident that the database has changed enough in that time to warrant writing a new migration to perform that task.

So how do you get rid of the migrations? These are the steps I follow:

1. Delete the migration files
2. Write a rake task to delete their corresponding rows in the schema_migrations table of your database.
3. Run rake db:migrate to regenerate structure.sql/schema.rb.
4. Validate that the only thing changed in structure.sql/schema.rb is removed lines corresponding to each of the migrations you deleted.
5. Deploy, then run the rake task from step 2 on production.
6. Make sure other developers run the rake task from step 2 on their machines.

The second item is necessary to keep schema/structure accurate, which, again, is the only thing that actually matters here.