Migrations in Ruby on Rails are files that indicate an incremental change to apply to the database. Examples include creating a table, removing an index, changing the default value of a record, or adding a column:
After you write a migration file, you can run it locally by typing
bin/rails db:migrate. In the example above, the migration will add a column called
priority of type
Integer to the table
tickets on your local machine.
To apply the same change to the production database, deploy the migration file to the production server, then run the migrations there. With Heroku, for instance, that means typing
heroku run bin/rails db:migrate or setting up a release process with that command.
Now that the incremental change has been applied both to your local and to the production database, there is no real need to keep the migration file around… except if you have co-workers! If you do, you should wait for all of them to run the migration before deleting the file.
My suggestion is to periodically delete migration files older than 3 months:
When you do that, also add a new migration with the same timestamp as the last migration you deleted, with the following content:
This migration takes care of co-workers who have not touched the app for 3 months, inviting them to reload the database schema before running further migrations.
Every other machine (including your local computer and the production server) will not try to run this migration, since it shares the same timestamp as the last deleted migration (
20171027231859 in the example above).
Deleting old migrations is not a requirement for a Rails project, but it’s a good practice to keep your codebase small, helping developers find the code they are looking for when they perform “Find in project” searches in the project.
If you enjoyed this article, please share with your friends. If you are looking to join an amazing team of Ruby developers, check our current openings at Clutter.