Applies to
- Liquibase Secure (Pro)
Summary
When enabling Policy Checks, some teams may run into failures when they have changesets with runOnChange=true but no rollback statement due to the RollbackRequired policy check.
Rollback Benefits
Typically, rollbacks may be omitted for runOnChange changesets since subsequent updates will replace previous version deployments. However, there are some specific scenarios where defining a rollback is advisable, or even necessary:
Non-idempotent Changes
If the changeset modifies the state in a non-reversible way (e.g., dropping a column or table), a rollback can ensure the change can be reverted in case of an issue encountered during a deployment.
Multi-Step Dependency Chains
Rollbacks maintain transactional integrity when a runOnChange changeset depends on prior changes (e.g., inserting reference data into a new table).
Post-Deployment Defects
If a runOnChange update introduces a bug (e.g., faulty stored procedure logic), rolling back to the last stable version can resolve this issue.
Policy Compliance
Organizations enforcing strict deployment policies (e.g., RollbackRequired) may require rollbacks even for idempotent changes.
How to Implement No-Op Rollback
However, if the situation requires passing the policy check RollbackRequired and a rollback statement is not desired, a user can use an explicit no-op rollback.
This is done simply by including the rollback with the keyword "empty".
XML Example:
<changeSet id="proc_v1" author="dev" runOnChange="true">
<sql>CREATE OR REPLACE PROCEDURE ...</sql>
<rollback>empty</rollback>
</changeSet>In this situation, the <rollback>empty</rollback> will satisfy the policy check.
Formatted SQL Example:
--changeset liquibaseuser:1
CREATE OR REPLACE PROCEDURE ...
--rollback empty
Comments
0 comments
Article is closed for comments.