Migrations and feature branches

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Migrations and feature branches

Florian Ebeling
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?)

Florian

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/23939ea5-cd1c-4780-8a16-fa43d2e2e704%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Migrations and feature branches

Walter Lee Davis

> On Sep 18, 2018, at 6:19 AM, Florian Ebeling <[hidden email]> wrote:
>
> 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?

Walter

>
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> To post to this group, send email to [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/23939ea5-cd1c-4780-8a16-fa43d2e2e704%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/11363694-F895-405E-A3D2-2C62E1A80123%40wdstudio.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Migrations and feature branches

Walter Lee Davis
In reply to this post by Florian Ebeling

> On Sep 18, 2018, at 6:19 AM, Florian Ebeling <[hidden email]> wrote:
>
> But how would you establish what to pass as `v` here from the new branch?
>

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?

Walter

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/440D765F-A78A-4C01-8742-97CED8CD7D98%40wdstudio.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Migrations and feature branches

Hassan Schroeder-2
In reply to this post by Florian Ebeling
On Tue, Sep 18, 2018 at 3:19 AM, Florian Ebeling
<[hidden email]> wrote:
> 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.

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

Very much an "it depends" question :-)

FWIW,
--
Hassan Schroeder ------------------------ [hidden email]
twitter: @hassan
Consulting Availability : Silicon Valley or remote

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CACmC4yCmHZWyYSahPc8aeo58NDTequZcqrMNZu8O_Y4DQ9xpvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.