Build a Changelog File
Learn how to build a changelog file for your database using Harness Database DevOps.
A changelog is a collection of database changes that can be applied to a database. It serves as a version-controlled record of changes, allowing teams to manage and track modifications to the database schema and data.
Harness Database DevOps offers multiple methods to generate changelogs for your database. This document lists each approach and provides step-by-step guidance.
Create a changelog
You can create a changelog by pointing to SQL files in your git repository. This method is useful if you have existing SQL scripts that you want to use as changelogs. This approach allows you to leverage your existing SQL files without needing to convert them into a specific changelog format.
Steps to create a changelog with SQL files
Follow these steps to create a changelog by pointing to existing SQL files:
Place your SQL files it in a subfolder named
sqlin git repository.Ensure that the SQL files are named in a way that reflects their order of execution.
Each SQL file should contain the SQL statements that define the changes you want to apply to your database schema.
Add
changelog.ymlto your git repository. In this file, include the following configuration to reference the SQL files:
databaseChangeLog:
- includeAll:
path: sql
relativeToChangelogFile: trueAdvanced usage options
If you need an order other than alphabetical, or want to leverage advanced features of changes, or a mixture of YAML/SQL based changes, you can use the sqlFile change type in a YAML changeset:
databaseChangeLog:
- changeSet:
id: execute-specific-sql-file
author: sonichigo
changes:
- sqlFile:
path: sql/specific_script.sql
relativeToChangelogFile: trueFor customers with an existing directory of scripts to run in alphabetical order, you can leverage includeAll and then follow it with additional YAML changesets to run after the referenced scripts:
You can create a changelog by using the generate-changelog command. This method is useful if you want to generate a changelog based on the current state of your database. This approach allows you to create a changelog file that reflects the current state of your database schema. For MongoDB, the generate-changelog command is not supported. Go to MongoDB changelog generation to generate a MongoDB changelog.
Steps to create a changelog with the generate-changelog command
Follow these steps to generate a changelog from the current state of your database:
Under
DBOpsin the Harness UI, navigate toDB Schema.Click
Add DB Schema.
Click
Add DB Instance.Go to
Pipeline, then clickCreate a Pipeline.Click
Add Stage, then selectcustom stage.In the
Stagesection, createAdd Step Groupas the stage type.
Enable container-based execution
Enable container-based execution.
In the
Step Groupsection, selectAdd Stepas the step type. Under "DB DevOps", selectLiquibase Commandas the step type.By default the name is "LiquibaseCommand_1".

Select DB Schema: The DB Schema we created on Step 2.
Select DB Instance: The Instance we created on Step 3.
Command: The command to be executed. In this case, we will use
generate-changelogto generate a changelog file.
Click
Apply Changesand Save the Pipeline.Click
Runto run the pipeline.Once the pipeline is executed successfully, you will find the changelog file in the specified path.


This step will ensure that the generated changelog file is committed to your Git repository, allowing you to track changes and maintain version control over your database schema changes.
How changesets work
A changeset is the smallest deployable unit of change to a database. When using database DevOps practices, changesets can be applied or rolled back individually. Which changesets have been applied are tracked inside the database itself in a tracking table called databasechangelog.
A changeset looks something like this:
The change management system only executes new changesets or those with modified checksums and records successful executions in the tracking table. If a changeset fails, it will not be recorded in the tracking table, and you can re-run it later. This allows for easy rollback and re-application of changesets as needed.
The database tracking table is used by default, and can be overridden by setting the database-changelog-table-name global parameter.
Next steps
Go to Apply a DB schema step to deploy your changelog in a pipeline.
Go to Rollback for database schemas to configure automated rollback for failed deployments.
Last updated
Was this helpful?