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

Why? Unless there is some kind of problem with disk space, I don't see a good reason for deleting them. I guess if you are absolutely certain that you are never going to roll back anything ever again, than you can. However, it seems like saving a few KB of disk space to do this wouldn't be worth it. Also, if you just want to delete the migrations that refer to old models, you have to look through them all by hand to make sure you don't delete anything that is still used in your app. Lots of effort for little gain, to me.

Answer 2

I agree, no value in 100+ migrations, the history is a mess, there is no easy way of tracking history on a single table and it adds clutter to your file finding. Simply Muda IMO :)

Here's a 3-step guide to squash all migrations into identical schema as production:

Step1: schema from production

# launch rails console in production
stream = StringIO.new
ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, stream); nil
stream.rewind
puts stream.read

This is copy-pasteable to migrations, minus the obvious header

Step 2: making the migrations without it being run in production

This is important. Use the last migration and change it's name and content. ActiveRecord stors the datetime number in it's schema_migrations table so it knows what it has run and not. Reuse the last and it'll think it has already run.

Example: rename 20161202212203_this_is_the_last_migration -> 20161202212203_schema_of_20161203.rb

And put the schema there.

Step 3: verify and troubleshoot

Locally, rake db:drop, rake db:create, rake db:migrate

Verify that schema is identical. One issue we encountered was datetime "now()" in schema, here's the best solution I could find for that: https://stackoverflow.com/a/40840867/252799

Answer 3

Once I hit a major site release, I'll roll the migrations into one and start fresh. I feel dirty once the migration version numbers get up around 75.

Answer 4

It's fine to remove old migrations once you're comfortable they won't be needed. The purpose of migrations is to have a tool for making and rolling back database changes. Once the changes have been made and in production for a couple of months, odds are you're unlikely to need them again. I find that after a while they're just cruft that clutters up your repo, searches, and file navigation.

Some people will run the migrations from scratch to reload their dev database, but that's not really what they're intended for. You can use rake db:schema:load to load the latest schema, and rake db:seed to populate it with seed data. rake db:reset does both for you. If you've got database extensions that can't be dumped to schema.rb then you can use the sql schema format for ActiveRecord and run rake db:structure:load instead.

Answer 5

Personally I like to keep things tidy in the migrations files. I think once you have pushed all your changes into prod you should really look at archiving the migrations. The only difficulty I have faced with this is that when Travis runs it runs a db:migrate, so these are the steps I have used:

1. Move historic migrations from /db/migrate/ to /db/archive/release-x.y/

2. Create a new migration file manually using the version number from the last run migration in the /db/archive/release-x.y directory and change the description to something like from_previous_version. Using the old version number means that it won't run on your prod machine and mess up.

3. Copy the schema.rb contents from inside the ActiveRecord::Schema.define(version: 20141010044951) do section and paste into the change method of your from_previous_version changelog

4. Check all that in and Robert should be your parent's brother.

The only other consideration would be if your migrations create any data (my test scenarios contain all their own data so I don't have this issue)

Answer 6

I occasionally purge all migrations, which have already been applied in production and I see at least 2 reasons for this:

1. More manageable folder. It is easier to spot if some new migration is added.
2. Cleaner text search results (Global text search within a project does not lead to tons of useless matches because of old migration, say, when someone created some column 3 years ago).