Explanation of Backporting

General Discussion
1

Could someone give a clear example on the process of “Backporting” changesets between change control branches?

For example.

Version 1.0.0 is released to production.

Version 2.0.0 is cut as a new branch for development.

Development happens on Version 2.0.0 and new changesets are created.

A critical bug is found in production (Version 1.0.0) and has to be fixed with a new changeset.

Version 1.0.1 is cut from Version 1.0.0 and the changeset is added and Version 1.0.1 is released to production.

What is now the process to incorporate the changeset from Version 1.0.1 to the development Version 2.0.0?

Thank you all for your time.

2

The thing to remember is that liquibase knows nothing about versions, there are just ran and unran changes.  The ran changes are stored in the databasechangelog table, no matter how you merge changesets from one branch to the other, on every update liquibase will run any unran changesets.

I usually have a separate changelog for each version, with one “root” changelog that does an on each of the version changelogs.  If I make a change in the 1.0 changelog, that gets merged into the 2.0 branch along with any other 1.0->2.0 code.  If the database was updated with the 1.0.1 changeset as part of an early upgrade, when you deploy 2.0 the 1.0.1 changeset is known to be already ran and is not ran again.  If you hadn’t updated to 1.0.1, the new changeset will be ran when you upgrade to 2.0.

Does that help?

Nathan

3

Your explanation does help, thank you.

I’m fairly good with making changes to our production databases though time…

However, I was more discussing the time issues between production and development.

In the Best Practices guide there is a sub section titled “Full database definition.”

Version 1.0 is in production.

Development Branch 2.0 is cut for new development with a new ‘Seed Database’ script.

Interesting development starts on Development Branch 2.0 that incorporates database changes necessitating the need for Liquibase.

A critical bug is found in Version 1.0 and Version 1.1 is released that has some database changes.

Now the ‘Seed Database’ script for Development Branch 2.0 no longer reflects what is in the current production database and could very well likely cause incompatibilities in the Development Branch 2.0 changesets.

What is the preferred process for getting the Development Branch 2.0 ‘Seed Database’ back in sync with what is currently in production (Version 1.1)?

Should a new ‘Seed Database’ be created?  Or should the changesets for Version 1.1 be added to the Development Branch 2.0?

How should conflicts be handled?  I guess it depends on a case by case basis huh?  Should the changesets in Development Branch 2.0 be changed to work with the new ‘Seed Database’ or should the changesets for Version 1.1 be backed out?

I guess I’m looking for a little friendly direction on how to reconcile differences between Development branches and emergency changes to the state of production databases.

Thank you for your time.

4

Excellent topic. I’m surprised this didn’t generate more discussion. Did you ever settle on a process for handling this?