Best practices with migrations in production deployments

rubyonrails-talk
1

Hi every one!

In rails every evolution of a model must be executed through migrations, isn’t it?

And if it must be done this way, how can we control migrations in a production deployment?

We have to take care of our data during the migrations in order to don’t erase anything.

What is the best way to do this?

Thank you so much in advance.

2

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.

3

Thanks for your fast answer! :^)

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…

Thanks again!

4

You need to review and test your migrations before deployment :wink:

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.

5

Ok! Understood! :^)

Thank you so much for your help.

6

Scott's advice is top notch, a very best practice. In addition, you should 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 deployment processes. Capistrano seems the leading contender still amongst the Rails 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 to 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.

7

Came here to recommend using Capistrano as well. I second what tamouse recommended. Capistrano can automate the running of the migrations as you do deployments to different environments.

Check it out http://capistranorb.com/