For the complete documentation index, see llms.txt. This page is also available as Markdown.

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:

  1. Place your SQL files it in a subfolder named sql in git repository.

  2. Ensure that the SQL files are named in a way that reflects their order of execution.

For example, you can use a naming convention like V1__create_table.sql, V2__add_column.sql, etc.

  1. Each SQL file should contain the SQL statements that define the changes you want to apply to your database schema.

  2. Add changelog.yml to your git repository. In this file, include the following configuration to reference the SQL files:

databaseChangeLog:
  - includeAll:
      path: sql
      relativeToChangelogFile: true

Advanced 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: true

For 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:

  1. Under DBOps in the Harness UI, navigate to DB Schema.

  2. Click Add DB Schema. Create DB Schema

  3. Click Add DB Instance.

  4. Go to Pipeline, then click Create a Pipeline.

  5. Click Add Stage, then select custom stage.

  6. In the Stage section, create Add Step Group as the stage type.

  1. In the Step Group section, select Add Step as the step type. Under "DB DevOps", select Liquibase Command as the step type.

  2. By default the name is "LiquibaseCommand_1". Configure Command

  • 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-changelog to generate a changelog file.

  1. Click Apply Changes and Save the Pipeline.

  2. Click Run to run the pipeline.

  3. Once the pipeline is executed successfully, you will find the changelog file in the specified path. Generate Changelog

Commit to Git

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

Last updated

Was this helpful?