CODEWITHSUNDEEP
liquibaseflyway
ruelloehr
ruelloehr

Reputation: 333

Database change management - how to handle changes on branch and trunk

Tools such as liquibase and flyway certainly make it easy to upgrade your database. What I haven't gotten straight in my mind is how to best handle changes that occur both on a release branch and trunk.

An example:

My code that is in product is version 2.5 and lives on a release branch. In the meantime, developers have started working on version 3.0 which lives on trunk.

A bug is found in production. A database change script is made (2.5.1) and committed to the release branch. The same change script must be merged back to trunk (3.0.1?).

Version 3.x is released into the wild production db's will already have the change from 2.5.1. The upgrade could potentially fail.

Conversely, if I'm creating a db from scratch if i was using a forward only strategy I would have the same change occurring twice (2.5.1 and 3.0.1).

How are others handling this scenario?

Upvotes: 4

Views: 760

Answers (1)

Axel Fontaine
Axel Fontaine

Reputation: 35169

You are right to recognize that production DB changes will always be linear.

To solve this you should place DB migration 2.5.1 both on the branch and on trunk. And not create a 3.0.1 with the same changes!

This way it will be deployed with the branch, but also with trunk.

Upgrading production to trunk will then

  • find migration 2.5.1 and skip it, as it has already been applied
  • find migration 3.0 and apply it on the 2.5.1 db

There is, of course, an ever better solution. And that is to get rid of branches altogether and always release from trunk using to feature toggles instead.

Upvotes: 1

Related Questions