How should I set up LiquiBase for multiple databases which depend on each other?

General Discussion
1

I’m new to LiquiBase, so appreciate any guidance this community can offer. I’m trying to set up LiquiBase migrations for a very large legacy application built upon 30+ databases that are split across two different Microsoft SQL Servers (let’s call these servers X and Y). In short:

  1. These databases consist of tables, but also stored procedures, synonyms, user functions that can depend on tables from other databases, from the same server and the other server (through Linked Servers, etc).
  2. There is no clear boundary between the databases and the applications consuming it, and refactoring is out of the question right now given bandwidth constraints.
  3. The team works on a 2-week release cadence which all apps/DBs follow. So changes for all databases are deployed every 2 weeks.
  4. Today, these databases are not managed through version control - there is no change management framework being used. I’ll be setting up LiquiBase from scratch, and generating baseline changesets to match the current state of each database.

Here’s the directory structure I’m thinking of:

- rootchangelog.yml
- database1
  - changelog.yml
  - sprocs
    - changelog.yml
    - sp_XYZ.sql
  - views
    - changelog.yml
    - view_XYZ.sql
  - release-v1.0
    - changelog.yml
    - changeset1.sql
    - changeset2.sql
- database2
...

Hopefully the above illustration makes sense - each database has it’s own changelog, where each release is a separate changelog. In addition, objects like stored procedures, views, functions, etc are defined separately for each database and use runOnChange changelogs.

The problem I’m running into with this - I’m having a hard time figuring out how would I “sequence” changes to sprocs that depend on another database’s changes.

So for example, if sp_XYZ is contained in database1, but uses table X from database2, I need the changes in database2 to be deployed before changes in database1. There are several such dependencies to deal with, and refactoring is out of the question at this moment.

Questions for the community:

  • Would it make sense to have one changelog for all the databases? Does LiquiBase allow this (ie. applying changesets to multiple databases/different connections from one changelog?
  • Is there something obvious I’m missing? I imagine that this is not an uncommon scenario - how have people solved this in the past?
  • I would have said “we can just deploy the changelogs manually in sequence every time”, but unfortunately that doesn’t work with the release cycle, since all changes will go through at once through Continuous Deployment.

Would appreciate any help!

2

Welcome to the forum @echofoxxx!

I think your folder layout looks great. The approach I would take to solving your sequencing challenge would use labels.

I would assign a label to each of the sproc/view/function change sets called something like stored-logic. When it was time to deploy, I would run two liquibase update commands:

  1. Update tables, constraints, indexes, etc. - For this you will run:
    liquibase update --label-filter="!stored-logic".
    This will run all changesets EXCEPT those with the stored-logic label assigned.

  2. Update sproc/view/function changesets - For this you would run
    liquibase update --label-filter="stored-logic"
    This would ONLY execute changesets with the stored-logic changeset assigned.

Hope this helps!

3

Thanks Pete! This worked.