Manage multibranch database versioning.

General Discussion
1

Hi,

Liquibase works as a charm when our delivery pipeline is straightforward, and we work with a short cycle development. But it is not always the case.

Firstly let’s imagine that we should have several instances of DB in productions at the same time: Version 5 and 6. All instances of “5” should eventually migrate to ‘6’ but it is not the case so far and will take some months.

Then the bug fix happens, and we should patch both 5 and 6 to some 5.1 and 6.1 versions. This means that the migration 5=>6 is becoming obsolete and risky.

So we have:

v5: 

\patch1 6 => 6.1  </div></blockquote>

So by introducing a patch into 2 versions, we’ve added a gap “5.1=>6”.

We can probably create 5.1=>6 every time we need a patch on older versions but it does not have any sense since “patch1” is valuable, and v6 as we know is worthless without this patch.

What would you recommend for this use case?

2

I would recommend that you call Datical right away.

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/

3

As your deployment complexity increases, Datical is a great option.

From a pure-Liquibase standpoint, it doesn’t really know or understand “versions”, it just tracks individual changeSets and relies on you to manage what changeSets are in the file using branches in your version control system. So, assuming you have a v5 branch and a v6 branch, you can add your patch1 changeSets into the v5 branch and then cherry-pick them into the v6 brach.

That way, when you deploy the v5 branch next time, it will apply the v5 changeSets and the patch1 changest and when you do upgrade to the v6 branch, it will see that the patch1 changeSets have been applied and not re-apply them.

Nathan