What is a ChangeSet?
A changeset in Harness Database DevOps (built on Liquibase) is a discrete, version-controlled unit of work that describes a single change to a database schema or its data. It could be a DDL change like adding a column, or a DML operation like inserting test data.
Changesets form the core building blocks of changelogs and are executed in sequence during deployment, ensuring consistency and traceability of database modifications.
Here's a sample changeset written in YAML:
databaseChangeLog:
- changeSet:
id: add-users
author: jane.doe
context: dev
changes:
- createTable:
tableName: users
columns:
- column:
name: id
type: int
- column:
name: username
type: varchar(255)
In above, the key components are:
id
: A unique identifier for the change. (It can be a simple string or a combination of numbers and letters.)author
: Person responsible for the change.context
: Optional tag to filter execution.changes
: The actual change operation (DDL or DML).
Why Changesets Are Important?
Changesets help:
- Track and audit every change made to the database.
- Ensure consistent deployment across environments.
- Enable rollback and safe failure handling.
- Facilitate CI/CD for databases with minimal manual intervention.
How does a Changeset Work?
When a deployment runs, Harness Database DevOps (via Liquibase) executes changesets in the order they appear in the changelog. Before running, it checks the "DATABASECHANGELOG" table to determine if a given changeset (by author:id:filepath) has already been executed.
Execution Conditions
- If not previously run, the changeset is executed and recorded.
- If already executed, it is skipped-unless:
runAlways
: true is set.runOnChange
: true and the checksum differs.
This mechanism ensures idempotency and traceability of database changes.
What are Common Attributes in a Changeset?
Each changeset supports a set of attributes that control how, when, and where it should be executed.
Attributes | Description | Required |
---|---|---|
author | Creator's identifier. Required if strict=true . | ✅ |
id | Unique identifier for the change. Can include decimals or text. | ✅ |
context | Tag for environment-specific execution. | ❌ |
labels | Logical grouping of changesets for filtering. | ❌ |
runAlways | Executes every time, regardless of prior runs. Default: false. | ❌ |
runOnChange | Re-executes if the contents of the changeset change. | ❌ |
runInTransaction | Controls transactional execution. Default: true. | ❌ |
preConditions | Checks to validate database state before executing. | ❌ |
failOnError | Determines whether failure of a changeset halts execution. Default: true. | ❌ |
dbms | Restricts execution to specific DB types. | ❌ |
logicalFilePath | Custom path to define the changeset identity (used if changelog file is moved/renamed). | ❌ |
What are Sub-Tags inside a ChangeSet?
You can nest the following sub-tags within a changeset to provide additional metadata, validation, or rollback behavior.
Sub-Tag | Description |
---|---|
comment | Adds inline documentation. |
preConditions | Specifies pre-checks for conditional execution. |
rollback | Defines how to revert the changes. Supports SQL or Liquibase syntax. |
validCheckSum | Allows custom or legacy checksums to be considered valid. |
How does Transaction Handling work with Harness?
Harness Database DevOps leverages Liquibase’s runInTransaction
flag to control transactional execution of changesets:
-
runInTransaction: true
: Changesets execute as a single, atomic transaction. If any statement within the changeset fails, the entire transaction is rolled back. Harness surfaces the failure in pipeline logs, halts downstream steps, and preserves database consistency. -
runInTransaction: false
: Each statement is committed immediately upon success. On encountering an error, Harness marks the changeset as failed-prior successful statements remain applied. This mode can be appropriate for very large data migrations where partial progress is acceptable, but it risks leaving the database in a partially updated state.
Conclusion
A changeset is the building block of schema evolution in Harness Database DevOps. It encapsulates a single database change and supports robust features like conditional execution, transaction control, and deployment safety. By following best practices such as one change per changeset, clear authorship, and use of contexts, you enable scalable, predictable, and auditable database deployments across all environments.
FAQ
1. How do I manage multiple database environments with Liquibase?
Managing multiple environments (dev, test, staging, prod) with Liquibase can become complex, especially when using different changelog configurations, contexts, and manual approvals. Harness Database DevOps simplifies this by offering native environment-aware pipelines, context based filtering, approval gates, and audit trails ensuring the right changes reach the right environments, automatically and securely.
2. Can I automate Liquibase changesets in CI/CD pipelines?
Yes, but setting up Liquibase in custom CI/CD pipelines often involves scripting, managing secrets, and ensuring rollback safety. Harness Database DevOps provides built-in CI/CD integrations with GitOps, approvals, rollback workflows, and visibility across every changeset without any scripting needed. You get end-to-end changelog promotion and governance with minimal configuration.
3. What’s the best way to track which Liquibase changesets ran in production?
Liquibase tracks execution via the DATABASECHANGELOG
table, but lacks centralized reporting or audit capabilities.
Harness offers a visual dashboard showing who deployed what, when, and where with Git linked changelogs, change approvals, and environment-level audit logs. This eliminates the guesswork and improves compliance posture.
4. How do I roll back a failed Liquibase deployment?
Liquibase supports manual rollbacks via custom rollback blocks or SQL, but it's error-prone without automation. With Harness, you can define rollback changesets, link them to environments, and automatically execute them on failure-triggered by pipeline conditions or user input. This makes recovery fast, safe, and consistent across teams.
5. Can I preview the SQL generated by Liquibase before applying it?
Liquibase’s updateSQL
command lets you preview SQL, but integrating it into approval workflows is manual.
Harness Database DevOps automatically previews SQL in pull requests and during pipeline execution—giving DBAs visibility into the exact SQL that will run, along with diffs, context filters, and approver visibility before any database change is applied.