So, theoretically, someone should be able to run your rails migrations and get the structure of the current production database. I tried to do this today on a big ‘ole existing codebase, and had to change a huge number of migrations just to get up to current. Here’s some stuff I found that was inappropriate, and probably shouldn’t be done with migrations.
- Using model classes in migrations to create / update data, run SQL, etc. If you ever prune your models, rename or get rid of them, the old migrations will be broken.
- Handling stuff other than data in migrations. A few migrations had cron management in them – the ideal way to do that is to store your crontab in the app code, then copy / overwrite it in Capistrano when you deploy. That way Cron gets versioned along with everything else, and you don’t have to mess with it when you’re trying to get a database up and running.
Anything else that should not be done in migrations?