There is much discussion where I work at present regarding migrations, and the ‘correct’ usage or not of them.
Should migrations be used just to modify schema, and other ‘deploy’ tasks done other ways? If yes, how to ensure no repeat runs of such tasks (seeds, jobs etc)
Once you’re live there are often additional things which need to be done on a deploy. They only need running on that specfic deploy of code, not each subsequent deploy. This might include:
Sending emails to subset of customers
Seeding new tables
Starting off a delayed job
Currently the simplest mechanism we’re aware of is to add in a migration which will either seed or insert jobs or whatever. Rails then knows that this migration ran, and won’t run it on subsequent releases.
The question is as to whether this is an abuse of migrations, given that it’s db:migrate. The expectation might be that they should be about schema transformation only…
Should migrations be considered anything to migrate the system state on a deploy, which includes seeds and other tasks, in which case, should db:migrate be renamed or aliased to something which suggests use for more than just ‘db’, like deploy:migrate (kind of like how before_filters were renamed to avoid confusion of people stating they should only be used for filters
If on the other hand, they’re being abused. What is the way to support single run on deploy tasks? The migration framework is really the right ‘fit’ here. Does an abstraction of it need building for deploy:tasks which does the same sort of thing.
The general issue we encounter is that if on deploy today we need to run rake xyz and rake abc, but then next deploy we run rake cde it’s prone to human error, rather that automation.
Additionally, rails doesn’t (to my knowledge) provide a way to run db:seed after you have a live system which doesn’t try and push prior seeds in too. What is the recommended way to add seeded values to new tables in a live system?