Question

Consider a basic Rails development pipeline, going from development -> staging -> production. When going upstream it is easy to push code, then run migrations. However, after a while data will build up in the production database that I want to have in the staging database. I assume that creating a backup of the production database, then overwriting the staging database, and finally running migrations on the staging environment is the correct way to do this?

My assumption is based on the schema_migrations table which should reflect the current schema state, and the schema in the staging database might be different than production. Thank you!

Was it helpful?

Solution

I assume that creating a backup of the production database, then overwriting the staging database, and finally running migrations on the staging environment is the correct way to do this?

This is how I would do it. The schema_migrations table will automatically be transferred to your staging environment, and thus when you run the migrations it will start the update at the correct migration point. At the same time this is a good test to see that the production DB can indeed be migrated properly. I do this often in my on development cycle before I do complex big upgrades. It provides one extra "free" migration test case with real-world data.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top