Skip to main content

Building Changelog File

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 DBOps offers multiple methods to generate changelogs for your database. This document outlines the various approaches available and provides step-by-step guidance for each.

Setup 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

  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.
info

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:

databaseChangeLog:
# First run all SQL files in the directory alphabetically
- includeAll:
path: sql/existing-scripts
relativeToChangelogFile: true

# Then run additional changesets after all the SQL files
- changeSet:
id: additional-changes-after-sql-files
author: sonichigo
changes:
- createTable:
tableName: new_feature_table
columns:
- column:
name: id
type: INT
constraints:
primaryKey: true

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 somthing like this:

databaseChangeLog:
- changeSet:
id: product-table
author: animesh
labels: products-api
comment: Creating product table for REST API
changes:
- createTable:
tableName: products
columns:
- column:
name: id
type: SERIAL
constraints:
primaryKey: true
- column:
name: name
type: VARCHAR(100)
constraints:
nullable: false
- column:
name: price
type: NUMERIC(10,2)
constraints:
nullable: false
defaultValue: 0.00

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.