Consolidating Rails Migrations on a Long Running Project

Question

I'm working on a project that's accumulated hundreds of migrations, and I'm unsure what to do with them long term. I suppose they're no hurting anything, but it seems strange to keep around a bunch of old files for incremental migrations, some of them creating tables that are later removed.

So far, I've seen three possibilities:

1. Leave them alone. They're not hurting anything.

2. Just delete them. I don't see much harm in doing this, since a new developer would be probably be starting with schema load anyway, not migrations.

3. Delete them all, create a new one with a timestamp matching an old merge, and create a new merge from your schema. This seems very clean, but I'm not sure who would actually use it.

I'm inclined to just delete them, but I'm curious if there's a big pitfall I'm missing.

Answer 1

In my opinion, as soon as every database on the project, especially the production, are at least at version '201xxxxxxxx', it should be fine to delete migrations before that version. They are not technically necessary anymore.

After that, if you want to play archaeology with your database history, you can still use your version control system.

With Git for example, you can use the following commands to have a quick look over the past :

git log --name-only db/migrate/    #to list commit involving migrations + migration filename
git show xxxxx db/migrate          #to see the code of commit xxxxx's migration(s)

Alternatively, you can browse repository history of schema.rb, identify a commit and see the corresponding migration content with the command above.

If you prefer to have a lighter db/migrate and use Version control, I would go for a little cleanup.

If you find it more convenient to have the whole migrations history directly available because it's easier to browse, I would go for option 1.

Note: it is very likely that old migrations do not make sense with the current application code. For example, some migrations may refer to class or methods that don't exist anymore. Using version control to checkout the application at the time the migration was written could also avoid some confusion.