Best practices with migrations in production deployments

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.

On Jul 23, 2015, at 6:16 AM, Rafa F [email protected] wrote:

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

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.


Scott R.
[email protected]
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice

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!

El jueves, 23 de julio de 2015, 14:55:31 (UTC+2), Scott R. escribió:

On Jul 23, 2015, at 7:14 AM, Rafa F [email protected] wrote:

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 :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.


Scott R.
[email protected]
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice

On Thu, Jul 23, 2015 at 8:22 AM, Rafa F [email protected] wrote:

Run a rake db:migrate in a production platform sounds like a little

Scott R.
[email protected]
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice

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.

Ok! Understood! :^)

Thank you so much for your help.

El jueves, 23 de julio de 2015, 15:18:10 (UTC+2), Scott R. escribió:

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/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs