How to have a pre/post deployment script or changeset run

Applies to

Liquibase Pro
Liquibase Open Source (Community)

Summary

Incorporating pre- and post-deployment scripts in Liquibase enhances the reliability, efficiency, and safety of database changes.

Pre-deployment scripts allow teams to prepare the database environment by validating prerequisites, creating backups, disabling triggers, or setting up temporary configurations to ensure a smooth deployment process.

On the other hand, post-deployment scripts focus on verifying the success of the changes, cleaning up temporary artifacts, re-enabling features like triggers, or even sending notifications to stakeholders about the deployment status.

These scripts streamline automation, reduce human error, and provide a safety net for rollback and recovery in case of failure. Furthermore, they contribute to compliance and auditing by documenting deployment activities. Together, pre- and post-deployment scripts enable predictable, repeatable, and auditable database deployments, reducing downtime and improving overall system stability.

Environment Conditions

Any Version of Liquibase Pro or Open Source

This article explains how to use Liquibase to execute pre-deployment and post-deployment scripts, ensuring smooth and reliable database deployments.

Pre-deployment

runOrder

Liquibase has a runOrder attribute (available for XML, JSON, and YAML changesets) that can be added to a changeset. This attribute controls whether the changeset should run before (or after) all of the changesets in the deployment. For example, if a pre-deployment script is wanted to run, the changeset can have runOrder="first".

For example:

<changeSet id="1" author="liquibase_support" runOrder="first" runAlways="true">
    <sql>
        -- Backup a table 
        CREATE TABLE employees_backup AS TABLE employees; 

        -- Disable triggers
        ALTER TABLE employees DISABLE TRIGGER ALL;
    </sql>
</changeSet>

With the runOrder set to first and the runAlways set to true, this changeset will always be the first one to deploy regardless of which deployment it is apart of.

Note: If you have multiple changesets with runOrder="first", it will order those changesets by the way they appear in the changelog.

Pipeline

Another approach would be configuring your pipeline/script to call liquibase first with a pre-deployment changelog.

For example:

liquibase --changelog-file=pre-deployment.xml update
liquibase --changelog-file=main-deployment.xml update

Inside the pre-deployment.xml file, the runAlways attribute can be utilized to ensure that the changeset is always run like in the runOrder example.

Post-deployment

Flow file

With Flow files, there is a built-in end-stage (post-deployment) that will be executed once all stages are complete. The advantage of the end stage is that even if any stages fail during the flow file, the end stage will always be executed.

endStage:
    actions:
    - type: liquibase
      command: history

runOrder

As discussed in the pre-deployment section, the runOrder attribute (available for XML, JSON, and YAML changesets), can be used to specify a changeset should run last.

Example:

<changeSet id="1" author="liquibase_support" runOrder="last" runAlways="true">
    <sql>
        -- Backup a table 
        CREATE TABLE employees_backup AS TABLE employees; 

        -- Disable triggers
        ALTER TABLE employees DISABLE TRIGGER ALL;
    </sql>
</changeSet>

Note: If you have multiple changesets with runOrder="last", it will order those changesets by how they appear in the changelog.