在TeamCity流水线中实现Liquibase自动回滚的方案咨询

问题根源 #

你当前的操作逻辑存在漏洞：回滚0.0.1、0.0.2版本后直接执行liquibase:update部署0.0.3，Liquibase会重新执行已被回滚的0.0.1、0.0.2变更集，并且将这些变更的标签统一覆盖为0.0.3，导致标签与变更的对应关系完全混乱，后续回滚0.0.3时会误将所有关联该标签的变更（包括前两个版本的内容）全部回滚。

正确的标签回滚+重新部署流程 #

1. 回滚后的基准标签处理 #

回滚到指定状态后，不能直接部署新版本，需要先为当前数据库状态打一个基准标签，再执行新版本的更新操作：

• 执行回滚：mvn liquibase:rollback -Dliquibase.rollbackTag=0.0.1
• 为回滚后的状态打基准标签：mvn liquibase:tag -Dliquibase.tag=rollback-base-pre-0.0.2
• 部署0.0.3版本：mvn liquibase:update -Dliquibase.tag=0.0.3

这样0.0.3的变更只会标记为自身版本标签，与前两个版本的变更完全隔离，后续回滚0.0.3仅会回滚该版本新增的变更。

2. 调整打标签的时机 #

不要在执行liquibase:update前打标签，应该在数据库更新执行成功后再打对应版本的标签，确保标签精准关联该版本实际执行的变更集：

• 执行数据库更新：mvn liquibase:update
• 验证更新无异常后，打版本标签：mvn liquibase:tag -Dliquibase.tag=0.0.x

其他回滚方式的适配建议 #

• Count回滚：适合小范围快速回滚（比如回滚最近3个变更集），但无法精准对应版本，多服务迭代场景下容易出错，不建议作为生产环境主要回滚方式。
• Date回滚：需要服务器与数据库时间完全同步，否则回滚范围会出现偏差，仅适合应急场景，维护成本较高。

核心原则 #

无论采用哪种回滚方式，必须保证每个版本的变更集与标签一一对应，标签仅标记该版本新增的变更，避免不同版本的变更共用同一标签，防止回滚范围失控。

内容的提问来源于stack exchange，提问作者Swathy