Liquibase TAG best practice

General Discussion
, ,
1

Is it better to tag a version before making a change set or after making a change set? I need the tag for database rollback in the future.

I would appreciate any feedback.

2 Likes
3

I would suggest tagging after each “release” of your application. That will get you a known “checkpoint” that you can rollback to. Example pattern:

changeset1
changeset2
tag v1
changeset3
tag v1.1
changeset4
changeset5
changeset6
tag v2

This allows me to completely remove each release, if needed.

v1 represents changesets 1 and 2
v1.1 represents changeset 3
v2 represents changesets 4, 5, and 6

2 Likes
4

Thanks for your reply @daryldoak! I did a little rollback test according to your suggestion, and I found that if I rollback to tag v1.1, the tag v1.1 will be removed. If I want a complete release , do I have to tag v1.1 back to the database again every time after the rollback?

changeset1
changeset2
tag v1
changeset3

5

If you use the tagDatabase change-type in your changelogs, as opposed to the Liquibase “tag” command, then it will get reapplied automatically the next time you run Liquibase “update”.

<changeSet id="tag_database_v1" author="X">
  <tagDatabase tag="v1"/>
</changeSet>
1 Like
6

Just one more question on liquibase tagging. Is it better to tag it by adding a changeSet or tag it by command liquibase tag?

7

From copilot:

Liquibase tag Command

This is a CLI command used to tag the current state of the database.

:white_check_mark: Pros:

  • Quick and easy: No need to modify your changelog.

  • Flexible: Can be run at any time, independent of changelog structure.

  • Ideal for ad-hoc tagging: Useful during manual deployments or testing.

:cross_mark: Cons:

  • Not version-controlled: The tag is not part of the changelog, so it’s harder to track in source control.

  • Manual process: Requires someone to remember to run the command.

  • Rollback removes tag: If you rollback to a tag created via the tag command, the tag may be lost unless re-applied manually. [docs.liquibase.com]

Liquibase tagDatabase Change-Type

This is a changelog entry that applies a tag as part of a changeset.

:white_check_mark: Pros:

  • Version-controlled: The tag is part of the changelog and tracked in source control.

  • Automatic reapplication: If rolled back, the tag can be reapplied automatically on the next update.

  • Better for CI/CD: Works well in automated pipelines and structured deployments.

:cross_mark: Cons:

  • Requires changelog modification: You must add a changeset for each tag.

  • One tag per changeset: Cannot combine with other change types in the same changeset.

  • Rollback behavior needs care: Tags can be removed during rollback unless keepTagOnRollback is set to true. [docs.liquibase.com]

Best Practice Recommendation

  • Use tagDatabase for structured, repeatable deployments and when you want tags to be part of your version history.

  • Use tag command for quick, manual tagging during development or testing phases.

8

Thanks for the comment. At last, I decided to use tag command integrated with CICD. Because the changelogs are shared with others, and I afraid they forget to add tagDatabase changetype everytime.

1 Like