Liquibase Tag Rollbacks + Collaboration

I’m going to do my best to present this request to the community without the classic blunder where the only right answer is: “that depends entirely on your configuration, which I don’t know”

The spirit of my quandary is that I’d like to be able to have independent developers working on separate features concurrently without a given tag rollback triggering any unrelated files to rollback which someone else may have been working on at the same time. Since our Lab Snowflake account acts a bit as our local development instance, this sometimes is really disruptive to our way of working.

Forgive me if I n00b anything up to badly, I’ve inherited ownership of this process from those before me.

Today we use Liquibase to deploy Snowflake objects to 3 environments in sequence as as follows:

  1. Lab
    • This is a discreet Lab Snowflake account target/changelog table
    • Triggered by either explicitly calling a GHA workflow against your feature branch or by the act of opening a PR
    • This Liquibase release is tagged as pr-[feature-branch-name]
    • This environment deploys as update-testing-rollback
    • The tag is rolled back on failure or cancellation
  2. Stage
    • This is a discreet Stage Snowflake account target/changelog table
    • Triggered when we’ve met our SDLC requirements (codeowner approval, etc…)
    • This Liquibase release is tagged as release-[feature-branch-name]
    • The tag is rolled back on failure or cancellation
  3. Prod
    • This is a discreet Prod Snowflake account target/changelog table
    • Triggered on merge to main
    • This Liquibase release is tagged as release-[feature-branch-name]
    • The tag is rolled back on failure or cancellation

Note: We use a master changelog.xml file which contains our running list of directories and files sequenced appropriately for everything to work (e.g. deploy the tables before the views)

The main issue we’re trying to chase only really applies to the Lab environment. Based presumably on tag sequencing, sometimes developer A has an an issue in their feature branch we end up rolling back features from developer B who was making unrelated changes over the period of time between developer A doing an initial deploy and developer A pushing a mistake.

To me, intuitively, it should be possible for only incoming changes to be rolled back on failure; this way if maybe a developer paused work on a feature for some time they never run the risk of rolling back subsequent and unrelated changes that may have even shipped to Prod days or weeks prior. If I’m reading the docs correctly, Liquibase does not work this way, at least not as we’ve configured it.

Any advice would be much appreciated, community!

1 Like

Yeah, always hard to not just have “it depends” answers – especially since liquibase has a lot of flexibly built in.

It sounds like the main problem is that The tag is rolled back on failure or cancellation step from #1 The triggering and tagging and “update-testing-rollback” should generally work, correct?

We do have a problem where if there have been new changesets executed since the last tag, a re-tagging replaces the old tag vs. adding an additional one. But that’s probably not what you’re seeing?

And the update-testing-rollback should be using the same set of changesets to rollback and update again (assuming there is no failure in that command)?

But, if you find a problem in later testing OR if there is a problem in update-testing-rollback and you call rollbackToTag it’s rolling back unexpected changesets from a separate feature branch?

Although even in those scenarios, I’d expect rollbackToTag to normally work. What that does is look at your databasechangelog table to see what changesets have been executed after that tag and runs the rollback logic for them. So it’s not going by what is newly in the changelog but purely on what was just run, which should only be your few feature-branch changes? Or is it because you have some merges from other feature branches being ran as part of that step?

Nathan