In rails every evolution of a model must be executed through migrations, isn’t
No. You don’t have to use migrations at all; if you’re managing your db
schema some other way already, you can continue to do so. Migrations are
a convenience for projects where the db is managed entirely within the
scope of a rails app.
Ok, and if I decided to work with migrations, what is the best way deploying in
a production environment?
Run a rake db:migrate in a production platform sounds like a little dangerous…
You need to review and test your migrations before deployment
You might want a third environment, “staging”, in addition to
development, test, & deployment. Let the staging db server have a
replica of the production db that is re-synced periodically to have the
full data. After other testing, before deployment, test the migration
there. Review the SQL executed by the migration.
Scott’s advice is top notch, a very best practice. In addition, you
ensure you have a full suite of acceptance tests you can run against the
staging server, and pull in live testers as well to give it a good
shake-down as only real live humans seem able to do.
Another aspect of this is to both automate and instrument your
processes. Capistrano seems the leading contender still amongst the
community and it does a pretty thorough job of things given a standard
range of deployment environments.
Definitely make sure you have a roadmap or punchlist of everything that
needs to be done, and stick to it; when you find something you had to do
make sure to add it to the punchlist for future deploys or file defects
fix the problems to prevent them from showing up again.
Deployment is a big deal; you’ve already sussed that out, but sometimes
it’s not at all apparent just how big a deal it is.