3

We are using the git flow model for our development and trying to integrate liquibase for managing the database versioning efficiently. The problem comes when a developer is working on a feature branch and has made a DB script which is executed on his database and another developer's database, but it is not yet part of any release so it is not yet tagged. Now that feature is tested and becomes part of release and we tag the changeset and execute it on production.

The questions is how to rollback the changes made on the developer's machine because there was no tag defined at the moment when the script got executed and when we try to update it will the current tag it will show error "The table already exists".

How to manage these conditions through liquibase efficiently ?

Salman Raza
  • 320
  • 1
  • 8
  • 23

1 Answers1

0

What we do is not linked to Git or GitFlow, but to the database itself:

Each time a db script is executed, it is done through a wrapper which will also record said script execution in a dedicated table of the database.
That way, next time that same script is applied, the wrapper will detect it was already executed, and won't apply it again.

This is an implementation of what a product like Flyway does already (as shown in this answer, you can use both: Liquidbase and Flyway, they seem to differ).
The point is: this is not manageable solely with a Version Control System: you need an additional tool to enforce/control the database upgrade process.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So, how do I handle my condition in the given scenario? The problem is script is already executed with a changeset which was not part of the release tag yet, and now when it became part of release I need to apply the changeset with a proper release tag, which eventually fails. – Salman Raza Jun 06 '17 at 08:19
  • Generally, you would add to the release a second script which would fix what the first script introduced – VonC Jun 06 '17 at 08:29