Twenty-three articles of Liquibase knowledge, distilled into one reference. Bookmark this page. Use the checklists before every production deployment. Come back when something breaks. This article doesn’t repeat the “why” — that’s in the earlier articles. This is the what: concrete rules, with the article number if you need the full explanation. The 7 Laws (Non-Negotiable) These apply without exception. Break them and you will eventually have a bad day in production.

Liquibase supports four changelog formats: XML, YAML, JSON, and SQL. The format you pick affects readability, tooling support, and what features are available. This article shows the same changeset in all four formats so you can compare them directly — then explains when each format is the right choice. The Same Change in All Four Formats To make comparison concrete, here is a single changeset — creating the users table from the e-commerce schema — written in every format.

A single changelog file works fine for a tutorial. It stops working the moment two developers add migrations on the same day, or when you need to find the changeset that introduced a column added six months ago, or when a feature branch’s migrations must be reviewed independently before merging. Changelog organization is not a polish step — it is what determines whether Liquibase stays manageable at scale or turns into a source of merge conflicts and mystery failures.

The read-process-write loop is at the heart of almost every Spring Batch job. Understanding exactly how it works — where transactions begin and end, what gets rolled back on failure, and how Spring Batch knows where to restart — makes everything else in the framework click into place. This article goes deep on chunk-oriented processing: the execution model, the three interfaces, the counters that track progress, and how to size chunks correctly.

The Liquibase commands covered in Articles 5 and 16 become reliable only when they run automatically on every change. A developer who remembers to run futureRollbackSQL before merging is better than one who doesn’t — but a pipeline that enforces it is better than both. This article builds a complete GitHub Actions pipeline: PR validation gates that block merges when rollback is missing, a staging deployment workflow, and a production deployment workflow with mandatory tagging and pre-generated rollback files.

Most Liquibase guides explain change types by listing them. This article is different — it walks through twelve patterns you will encounter repeatedly in a real project, explains the MySQL-specific behaviour of each, and shows the rollback you need to write alongside every change. All examples build on the ecommerce database established in Part 1. By the end, you will have a complete reference you can reach for on any working day.

Introduction So far every example has had a single step. Real batch jobs usually have multiple steps — validate input, import data, generate a report, send a notification, clean up temp files. Spring Batch’s JobBuilder DSL lets you compose these steps into flows with conditional branching, parallel execution, and decision logic. This article covers: Linear multi-step jobs Conditional step transitions using ExitStatus JobExecutionDecider for runtime branching Parallel flows with split Nested jobs with FlowStep The Flow abstraction for reusable step sequences Linear Multi-Step Job The simplest multi-step job runs steps in sequence.

The most common multi-environment problem in database migrations: seed data that should run in dev and staging but must never touch production. The naive solution is maintaining separate changelogs per environment. The correct solution is contexts and labels — Liquibase’s built-in filtering mechanism that lets a single changelog serve every environment. This article covers both features, explains the critical difference between them, and shows exactly how to wire them into Spring Boot profiles.

Liquibase has over 50 commands. In practice, you will use fewer than ten of them for 95% of your work. This article covers those ten commands — what each one does, when to reach for it, and what the output tells you. Every example builds on the ecommerce database and users table from Article 4. The commands are organized by what you’re trying to accomplish: inspect, apply, undo, and verify.

Before writing a single migration, you need the mental model. Understanding how Liquibase thinks about changelogs, changesets, and identity prevents the most common mistakes — ones that are painful to fix after deployment. The Changelog The changelog is the file Liquibase reads. It contains an ordered list of changesets. Think of it as your database’s Git history — a sequential record of every change ever made. # db/changelog/db.changelog-master.yaml databaseChangeLog: - changeSet: id: "20240101-001" author: abhay changes: - createTable: tableName: users columns: - column: name: id type: BIGINT autoIncrement: true constraints: primaryKey: true nullable: false - changeSet: id: "20240101-002" author: abhay changes: - addColumn: tableName: users columns: - column: name: email type: VARCHAR(255) constraints: nullable: false unique: true The changelog format (YAML, XML, SQL) doesn’t matter for understanding the concept — it’s always a list of changesets in order.