Liquibase Enterprise was formerly known as Datical DB.

Developer Workflows: Managing Changesets During Development and Test

Owned by Former user (Deleted)
Last updated: May 10, 2022 by Former user (Deleted)
2 min read

Overview

The normal flow of deployment goes through stages. Depending on your environment, you may have more or fewer stages. 

Development > Test > Production

Developer Workflow

During development and test you may find problems with the original SQL scripts that were packaged and deployed to test. A failed test might indicate a need to remove or replace changesets that were deployed to Test and make adjustments in the Development environment. These adjustments might require the developer to:

  • Ignore a changeset - Abandon changeset in place and prevent it from being deployed further.  If needed, you can recover it (unignore) later. 
  • Clean up  a previously deployed changeset - Ignore deployed changeset, create changesets to clean up any changes that were created.
  • Replace a previously deployed changeset - Replace the changes in a changeset with other changes. This usually implies running a cleanup first.
  • Use versions with changesets - Deploy only the latest version of a changeset. This capability is intended for use with programmatic parts of the database (stored logic). 

To enable this capabilty, new changeset attributes are added to all changesets generated from a SQL script. 

Comparison to Rollback

The normal release workflow allows you to deploy and roll back changesets throughout a project pipeline. Rollbacks can be automatic for some changes or be performed by custom rollback scripts you supply. See Rolling Back Changes. 

However, the development workflow is for making changes to the changesets (and other changesets they affect).  When you use the -ignore, -cleanup, and -replace scripts, they mark the original changesets so that they are no longer deployed. Changes are anticipated at these stages in a pipeline.  They are not expected in later stages. 

See Rollback Script Handling for more information on how to work with existing rollback scripts in a development workflow. 

Example: ignoring a deployed changeset. 

To signal a change, you create a special file using the same base name as the original SQL script, apply a suffix (for example, -ignore), and place it in the same directory where you placed the original file. 

  • invoice_columns.sql
  • invoice_columns-ignore.sql or invoice_columns_ignore.sql

When invoice_columns-ignore.sql or invoice_columns_ignore.sql is processed, the ignore attribute is set on all of the original changesets produced by invoice_columns.sql.  The changesets are no longer deployed. 

Do not use more than one suffix when working in a development workflow (-ignore, -unignore, -replace, -cleanup, -rollback). For example, when you update a myscript-rollback.sql or myscript_rollback.sql file, you update it in place. Do not create a myscript-rollback-replace script. It causes an error during packaging.  

It is important to maintain consistent case in workflow file names!

When creating a new workflow file it is important to maintain file name casing that is consistent with the original file. MYSCRIPT-ignore.sql will not match myscript.sql.

If you are using git, you may have to run the following command to configure your repository to enforce consistent file name case: git config core.ignorecase false

Copyright © Liquibase 2012-2022 - Proprietary and Confidential