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

[Hassan Schroeder]

On Wed, May 10, 2017 at 10:21 AM, Ilya Kaplan <kapla...@gmail.com> 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 ------------------------ hassan.s...@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote

[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.

[Hassan Schroeder]

On Thu, May 11, 2017 at 8:25 AM, Ilya Kaplan <kapla...@gmail.com> 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...