Changes in a Production Environment

rubyonrails-talk
1

Hi guys, I am planning to make some changes in a Production environment. This include changes in the model. I was thinking about making a backup of the database, then running migrations to zero, making a svn update, running the migrations and then restoring the database.

Many would ask why I am making a rollback of migrations and then running them again. It seems that we made some changes to old migrations, so I prefer doing it this way.

Do you recommend me anything else?

Thanks a lot Rodrigo

2

Rodrigo Muiño wrote:

Hi guys, I am planning to make some changes in a Production environment. This include changes in the model. I was thinking about making a backup of the database, then running migrations to zero, making a svn update, running the migrations and then restoring the database.

Restore, how?

If there are any changes made to the schema then how is your restore going to handle them?

3

I analyzed that I wouldn’t have to make data changes to restore the whole info. We added some text columns in two tables which have no restrictions and created some tables that references another table we already had. I would backup only data with: mysqldump -u username -ppassword –no-create-info database_name > dump.sqland restore it with: mysql -u username -p password database_name < dump.sql Am I missing anything? Thanks Rodrigo

4

Rodrigo Muiño wrote:

I analyzed that I wouldn't have to make data changes to restore the whole info. We added some text columns in two tables which have no restrictions and created some tables that references another table we already had.

I would backup only data with: mysqldump -u *username* -p*password* –no-create-info *database_name* > * dump.sql

*and restore it with: mysql -u *username* -p* password* *database_name* < *dump.sql

Am I missing anything?

Thanks Rodrigo

If all you are doing is adding columns to several tables and several tables and related columns to an existing database then what benefit does a dump and restore give you? The major benefit of migrations is to leverage the ALTER TABLE capability of SQL to insert and remove columns without having to dump and restore.

5

James, Thanks for your answer. We’ll take it into account for the future. Now we need to do it the other way because we made changes in older migrations. You learn better of your own mistakes.

Rodrigo

6

James, Thanks for your answer. We'll take it into account for the
future. Now we need to do it the other way because we made changes in older
migrations. You learn better of your own mistakes.

I think you'd be better off just writing whatever migrations you need
to make your production environment right. For me at least, the
production database (and not the set of migrations and bits that got
you there) is the baseline.

Fred