Structure.sql with version control

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

Structure.sql with version control

Ilya Kaplan
Hi,

We use structure.sql as base for tests DB in standard way - we configured system to create it every time developers run db:migrate and then they commit structure changes together with the migration.

The problem starts when there are more than one project with migration in staging environment. When deploying developers always have conflicts with each other, mainly because of migrations list at the bottom.

Is there any common solution to this problem?

I thought about creating separate file for each table and migration version, and that way make git manage it in non-conflict way.

Thanks,
Ilya

--
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/5fb282df-3481-416d-8444-87455de530e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Structure.sql with version control

Hassan Schroeder-2
On Wed, May 10, 2017 at 10:21 AM, Ilya Kaplan <[hidden email]> wrote:

> The problem starts when there are more than one project with migration in
> staging environment. When deploying developers always have conflicts with
> each other, mainly because of migrations list at the bottom.
>
> Is there any common solution to this problem?

The startup where I'm working now has a "global" staging system
plus separate staging systems for each developer.

If you're using AWS or equivalent, you can spin up instances when
you need them, if you don't want them running all the time...

HTH!
--
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/CACmC4yBn-fAaW-UUGvJcCZrwu15HTPuRT_it92OJ3JrJAPZLJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Structure.sql with version control

Ilya Kaplan
Hi, Hassan Schroeder,

Appreciate the advice, but it doesn't solve the problem. When you deploy to the "global" staging, you'd still have same problem.

I'm coming to think that creating "structure.sql" wasn't meant to be part of feature branch, but only be created after deployment to production.

On Wednesday, May 10, 2017 at 9:00:26 PM UTC+3, Hassan Schroeder wrote:
On Wed, May 10, 2017 at 10:21 AM, Ilya Kaplan <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="SQGLpTWpAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">kapla...@...> wrote:

> The problem starts when there are more than one project with migration in
> staging environment. When deploying developers always have conflicts with
> each other, mainly because of migrations list at the bottom.
>
> Is there any common solution to this problem?

The startup where I'm working now has a "global" staging system
plus separate staging systems for each developer.

If you're using AWS or equivalent, you can spin up instances when
you need them, if you don't want them running all the time...

HTH!
--
Hassan Schroeder ------------------------ <a href="javascript:" target="_blank" gdf-obfuscated-mailto="SQGLpTWpAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">hassan.s...@...
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/de20bd50-86e1-4448-8a36-e6c4b7a2527c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Structure.sql with version control

Hassan Schroeder-2
On Thu, May 11, 2017 at 8:25 AM, Ilya Kaplan <[hidden email]> wrote:

> Appreciate the advice, but it doesn't solve the problem. When you deploy to
> the "global" staging, you'd still have same problem.

Is "structure.sql" (I've never even heard of it until now) generated
from the DB via migrations like schema.rb?

If so, I don't see how you can have migration conflicts unless your
developers are pushing untested code, in which case all bets are off...

--
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/CACmC4yDB8BrXPkn9y%2Bn6%3D5oD3hM84bGOZhgBqwO7Q7KnTcHA6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.