Search code examples
phpliquibaserefactoring-databasesdbdeploy

How can I keep order of refactors using database refactoring software?

I have been trying to use either Liquibase or DBDeploy. I'm more drawn toward Liquibase because of its non-SQL interface (I.E. I can just use JSON or Yaml changesets). However, there is a problem I have with both of these software.

Liquibase Workflow

  1. I create a master changelog. All it does is to includeAll a folder which contains small files with small changesets inside.
  2. I then create changesets, and prefix them with a number (E.G. a timestamp, or a simple integer like 1, 2, etc).

DBDeploy Workflow

  1. I just start making delta sql files, prefixed by the same strategy as number 2 above.

The problem

Well, the problem is so trivial I'm feeling stupid for asking it, but here it goes. Consider this scenario:

  1. I make a branch to work on my feature, say, adding orders to the system.
  2. My colleague, Bob, makes his own branch to add products to the system.
  3. When it comes time to merge, there is no telling whose changesets or delta sqls will run first. This may break the database.

Doesn't this happen to anyone? If so, what's the way to solve it in the PHP land?

Thanks.

Solution

  • I've used a couple of different migration frameworks - Liquibase, Rails, and something from the C# world called Tarantino. Each used a similar strategy, where changes were recorded in separate files. Each was on a small team (<= 5 developers).

    Rails is the most dogmatic about how files are named, and is where I have had the most conflicts due to branches. Most of those conflicts were name based rather than logical conflicts in the database.

    In projects using Liquibase, we used a master/include pattern, and developers did their work on branches. Because the file names had a 3 digit sequence numbers plus a brief description (i.e. 009-add-customer0index.xml) we did not have name conflicts. We avoided database level conflict mainly by just talking to each other - daily standups, etc.

    We had similar experiences using Tarantino, although it just uses a directory full of files for its migrations. As with Liquibase, we adopted a naming convention that kept things in order. Even when two changesets had the same number, they would have different names, and 99.9% of the time, the order of those two changesets was not dependent on each other.

    Just for a datapoint, the project that used Tarantino leveled off with about 400 changesets.