Is there a common practice how to apply migrations for staging systems running various feature branches?
Assume there is a db of significant size, and feature branches including migrations are pushed to this server instance.
Just calling rake db:migrate won’t be enough, as often it will be the situation that a feature branch introduced a schema change, and the subsequently deployed branch doesn’t work with it. So at deployment, I’d need to roll back one or more migration steps.
I know this can be done by invoking db:migrate VERSION=v.
But how would you establish what to pass as v here from the new branch?
(Or is loading a nightly db dump and uniformly migrate upwards still the best idea?)
Is there a common practice how to apply migrations for staging systems running various feature branches?
Assume there is a db of significant size, and feature branches including migrations are pushed to this server instance.
Just calling `rake db:migrate` won't be enough, as often it will be the situation that a feature branch introduced a schema change, and the subsequently deployed branch doesn't work with it. So at deployment, I'd need to roll back one or more migration steps.
I know this can be done by invoking `db:migrate VERSION=v`.
But how would you establish what to pass as `v` here from the new branch?
(Or is loading a nightly db dump and uniformly migrate upwards still the best idea?)
The we we manage this is to have a separate staging database, cloned monthly from the production database (to get a useful sample of data to play with) and then run migrations up and down in that database as we check things out for review. Does that help?
If you have run a migration up in staging, you can get its version from rake db:migrate:status (but I'm pretty sure you knew that). Are you talking about having run migrations from various branches up in staging all at various times? Does staging work as a sort of "integration branch" combining features from multiple stories?
Can you have a staging system per feature branch? If you're working
in the cloud it's not a huge deal to set that up, and once you have the
infra code written (chef, terraform, etc.), you can have those systems
only run while they're being used.
Alternatives:
1) multiple dockerized db instances per staging server
2) discrete db schema per feature branch on one big DB server
3) have staging deployments do an initial refresh from a base image
