Using Liquibase with Docker to automate DB changes

Tame the chaos of database changes with Liquibase + docker.

TL;DR

git clone [e-mail]:sudh33ra/liquibase_poc.git
cd liquibase_poc.git
mkdir temp && ./support_scripts/initLocalDB.sh --schema-name <schema_name>
#MAKE THE DB CHANGES IN LOCAL DB
./support_scripts/generateChangeLogRemote.sh --schema-name <schema_name> --change-tag <change_tag> --db-change-version <db_change_version>

In a world where software sorcery meets the mystical arts of database management, syncing different realms (environments) can be a real headache. But fear not, for Liquibase is here to sprinkle some magic on your database change management journey.

Liquibase, like a trusty wizard’s wand, brings several handy spells:

Version Controlled Changes: Think of it as tracking the evolution of spells. Liquibase keeps tabs on database tweaks, making it a breeze to reverse changes and pinpoint pesky database gremlins.

Environment Agnostic: Its spells don’t discriminate between realms, meaning changes written in Liquibase scrolls can seamlessly travel across different realms. It’s like having a universal translator for databases.

Automation: With a flick of a wand (or a few command lines), Liquibase automates the incantations of database updates, saving you from the perils of manual errors and speeding up the deployment process.

Now, onto crafting new changelogs with Liquibase, where even Docker gets a cameo:

Generating New Changelogs in Liquibase

Liquibase gives you two primary ways to create changelogs that track database changes:

Manual Changelog Creation: You write changelog files in SQL or other supported formats like XML, YAML, or JSON, allowing for fine-grained control over your database changes. This, while being the recommended way, is a bit of a hassle.

Changelog Generation by Comparing Databases: Here, Liquibase harnesses its powers to conjure changelogs by comparing the mystical essence of your development database, ripe with new enchantments, to that of a reference database, such as a staging environment.

Here we're gonna use an automated script to take the comparison approach

Prerequisites:

• Docker installed.

Steps:

Configure Properties: Create a liquibase-local.properties file with connection details for your local database. (example file given in the repo)
Run Initiation Command: Execute this command, replacing variables:

mkdir temp && ./support_scripts/initLocalDB.sh --schema-name <schema_name>

Now your DB has the initial changes recorded in the liquibase tables. (you can see the script has generated sql files for the current db inside a temp folder in the repo directory)

1. Configure Properties: Create liquibase-remote.properties with connection details for your local (source) and staging (target) databases. (example file given in the repo)

2. Generate Changelog: Run the below command, replacing variables with your specific details:
   

./support_scripts/generateChangeLogRemote.sh --schema-name <schema_name> --change-tag <change_tag> --db-change-version <db_change_version>

1. Review and Refine: Carefully review the generated changelog to ensure it contains only the intended changes before applying it to other environments.

Additional Notes:

• The db_change_version and change_tag parameters are crucial for organizing your database changes and ensuring they are applied in the correct order.
• If you find that the change log generation process includes unintended changes, you can use the ./support_scripts/markLocalDB.sh command to mark your local database as up-to-date without actually applying changes.