1. 项目缘起为什么我们需要Liquibase如果你是一个Java后端开发者尤其是使用Spring Boot框架的那么你一定经历过数据库版本管理的痛苦。项目初期可能就一两个表直接在数据库客户端里点点鼠标就建好了。但随着项目迭代需求来了要给某个表加个字段要改个字段类型要加个索引甚至要回滚到上一个版本。这时候问题就来了。张三在本地开发环境改了表结构李四在测试环境也改了等代码合并到一起准备上线时发现两个人的SQL脚本冲突了或者干脆忘了把改表的SQL提交到代码库。最后的结果往往是生产环境的数据库结构和代码期望的结构对不上轻则功能报错重则服务直接启动失败。更头疼的是你怎么知道生产环境现在的数据库状态具体对应到代码的哪个版本回滚的时候又该执行哪些反向的SQL这就是数据库版本管理工具要解决的问题。而Liquibase就是这类工具中的佼佼者。它不像Flyway那样直接使用原生的SQL文件虽然也支持而是通过一种更结构化的方式——使用XML、YAML、JSON或SQL格式的“变更日志”文件——来定义数据库的变更。它的核心思想是将数据库的每一次变更都视为一个可追踪、可重复、可回滚的“变更集”并与你的应用程序代码一起进行版本控制。那么集成到Spring Boot里有什么好处呢最大的好处就是“开箱即用”和“自动化”。Spring Boot的自动配置机制使得集成Liquibase变得异常简单。你只需要添加依赖、做一点基础配置Spring Boot应用在启动时就会自动检测并执行那些尚未应用到当前数据库的变更集确保你的代码和数据库结构始终保持同步。这对于持续集成和持续部署CI/CD流程来说是至关重要的一环。想象一下你的应用在Docker容器里每次启动都能自动将数据库升级到最新版本这该多省心。所以这篇内容就是要把Liquibase集成到Spring Boot的每一步从环境准备、依赖引入、配置详解到变更集的编写、多环境适配、以及实际开发中那些容易踩的坑给你掰开揉碎了讲清楚。目标就是让你看完之后能在一个全新的Spring Boot项目里稳稳当当地把Liquibase用起来。2. 环境准备与项目初始化在开始集成之前我们得先把“舞台”搭好。这里我假设你已经有基础的Java和Spring Boot开发环境并且使用Maven作为构建工具Gradle的配置思路类似文件格式不同而已。2.1 创建Spring Boot项目首先我们通过Spring Initializr来快速生成一个项目骨架。你可以访问 start.spring.io 也可以直接在IDEA里选择Spring Initializer。在依赖选择页面我们需要勾选Spring Web: 构建Web应用方便我们后续写个简单的接口测试。Spring Data JPA: 这里选它不是为了必须用JPA而是因为它会帮我们引入数据库相关的基础依赖如Hibernate并且方便演示Liquibase与JPA实体类的协作。当然你只用MyBatis或JdbcTemplate也完全没问题。MySQL Driver(或PostgreSQL Driver等): 根据你实际使用的数据库选择。我这里以MySQL 8为例。Liquibase Migration: 这是关键勾选它Spring Initializr会自动为我们添加liquibase-core依赖和基础配置。点击生成下载并解压项目然后用你喜欢的IDE如IntelliJ IDEA打开。2.2 检查pom.xml依赖打开项目中的pom.xml文件你应该能看到Spring Initializr已经帮我们添加了Liquibase依赖。dependency groupIdorg.liquibase/groupId artifactIdliquibase-core/artifactId /dependency注意这里没有指定版本因为Spring Boot的父POMspring-boot-starter-parent已经为我们管理了兼容的版本。这是一种最佳实践可以避免版本冲突。如果你想确认或使用特定版本可以查看Spring Boot官方文档中关于liquibase-core的版本映射。同时确保有数据库驱动依赖例如dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency2.3 配置数据库连接接下来我们需要在src/main/resources/application.properties(或application.yml) 中配置数据库连接信息。这是Liquibase能够工作的前提因为它需要知道连接哪个数据库来执行变更。application.properties 示例# 数据库连接配置 spring.datasource.urljdbc:mysql://localhost:3306/your_database_name?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai spring.datasource.usernameyour_username spring.datasource.passwordyour_password spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver # JPA相关配置可选如果你用了JPA spring.jpa.hibernate.ddl-autovalidate # 重要这里必须设置为 validate 或 none绝对不能是 create, create-drop, update # 因为数据库结构的创建和变更将由Liquibase全权负责Hibernate只负责验证实体与表结构是否一致。这里有一个至关重要的坑点spring.jpa.hibernate.ddl-auto属性。在集成Liquibase后这个属性应该设置为validate或none。validate模式会在应用启动时检查JPA实体定义是否与数据库表结构匹配如果不匹配则启动失败这能有效防止代码与数据库不同步。绝对不要再设置为update否则Hibernate会和Liquibase“打架”擅自修改你的表结构导致变更历史混乱失去版本控制的意义。实操心得我建议在团队内将此配置作为一条硬性规范。可以在项目的README.md或配置文件中显式注释出来避免新人误设。我曾经就遇到过因为有人本地设为update导致本地表结构多了一些莫名其妙的字段合并到测试环境后引发的问题排查起来相当耗时。3. Liquibase核心配置与目录结构详解依赖和数据库连接配好了现在我们来认识一下Liquibase在Spring Boot项目中的“工作方式”和标准目录结构。3.1 默认约定与目录结构Spring Boot为Liquibase提供了自动配置。在默认情况下Liquibase会在应用启动时自动在classpath下寻找名为/db/changelog/db.changelog-master.yaml的主变更日志文件也支持.xml,.json,.sql格式。这是它的“入口”文件。因此我们需要手动创建这个目录和文件。在src/main/resources下创建如下结构src/main/resources/ └── db/ └── changelog/ ├── db.changelog-master.yaml # 主变更日志文件总入口 ├── changelog-v1.0.yaml # 版本1.0的变更集文件 ├── changelog-v1.1.yaml # 版本1.1的变更集文件 └── ... # 更多版本或模块的变更文件当然你也可以自定义这个路径和文件名但遵循约定可以省去很多配置。3.2 主变更日志文件 (db.changelog-master.yaml)这个文件是变更集的“总目录”它本身不定义具体的变更操作而是通过include或includeAll指令来组织其他具体的变更文件。这样做的好处是结构清晰易于管理。一个典型的db.changelog-master.yaml内容如下databaseChangeLog: - include: file: classpath:db/changelog/changelog-v1.0.yaml - include: file: classpath:db/changelog/changelog-v1.1.yaml # 未来新的版本继续在这里include3.3 详解application.properties中的Liquibase配置除了默认路径Spring Boot还提供了许多Liquibase的配置项让我们可以精细控制其行为。下面是一些常用且重要的配置# Liquibase 核心配置 spring.liquibase.enabledtrue # 是否启用Liquibase默认为true可用于特定环境关闭 spring.liquibase.change-logclasspath:/db/changelog/db.changelog-master.yaml # 主变更日志文件位置 spring.liquibase.default-schema # 默认schema不指定则使用数据源连接的用户默认schema spring.liquibase.liquibase-schema # Liquibase自身表如DATABASECHANGELOG存放的schema用于多租户或权限分离场景 spring.liquibase.liquibase-tablespace # Liquibase自身表的表空间 # 运行控制 spring.liquibase.drop-firstfalse # 危险是否先删除所有表再执行变更绝对不要在生产环境设置为true spring.liquibase.clear-checksumsfalse # 是否清除旧的checksum可用于修复因手动修改历史变更文件导致的校验失败 spring.liquibase.run-asyncfalse # 是否异步执行一般设为false确保启动时完成变更 # 上下文和标签用于环境过滤 spring.liquibase.contexts # 指定执行的上下文如 dev,test spring.liquibase.labels # 指定执行的标签 # 数据库连接可选默认使用主数据源 # spring.liquibase.url # 如果不希望使用应用的数据源可以单独为Liquibase配置 # spring.liquibase.user # spring.liquibase.password # spring.liquibase.driver-class-name3.4 Liquibase如何工作DATABASECHANGELOG 表这是Liquibase的“大脑”。当Liquibase第一次在你的数据库中运行时它会自动创建两个表如果不存在的话DATABASECHANGELOG: 这是核心表用于记录所有已执行的变更集。DATABASECHANGELOGLOCK: 这是一个锁表用于防止多个JVM实例同时运行Liquibase导致变更执行冲突。DATABASECHANGELOG表的结构大致如下ID: 变更集的ID与AUTHOR和FILENAME共同组成唯一标识。AUTHOR: 变更集的作者。FILENAME: 变更集所在的文件名。DATEEXECUTED: 执行时间。ORDEREXECUTED: 执行顺序。EXECTYPE: 执行类型EXECUTED, FAILED, SKIPPED等。MD5SUM: 变更内容的MD5校验和。这是关键Liquibase通过对比文件内容的MD5和数据库中记录的MD5来判断一个变更集是否被修改过。如果被修改下次运行时会报错防止已执行的变更被意外篡改。DESCRIPTION: 描述。COMMENTS: 注释。TAG: 标签。LIQUIBASE: 执行该变更的Liquibase版本。每次应用启动Liquibase都会检查DATABASECHANGELOG表获取已执行变更集列表。解析db.changelog-master.yaml及其包含的所有变更文件生成待执行变更集列表。对比两个列表找出尚未执行即不在DATABASECHANGELOG表中的变更集。按顺序和在主文件中的include顺序一致执行这些新的变更集。将执行成功的变更集信息插入DATABASECHANGELOG表。注意事项永远不要手动去修改DATABASECHANGELOG表中的记录除非你非常清楚自己在做什么比如修复因网络问题导致的错误状态。错误的修改可能导致Liquibase状态混乱。4. 编写你的第一个变更集 (ChangeSet)理论讲得差不多了现在我们来动手写一个真正的变更集。假设我们要为一个小型博客系统初始化数据库创建user用户和post文章两张表。我们在src/main/resources/db/changelog/下创建文件changelog-v1.0.yaml。4.1 变更集的基本结构每个具体的变更文件如changelog-v1.0.yaml里包含一个或多个changeSet。changeSet是Liquibase执行的最小单位它被赋予一个唯一的标识由id,author,filename共同决定并且应该是幂等的。这意味着无论执行多少次只要这个changeSet没被修改过它对数据库产生的最终效果都是一样的。一个changeSet的基本骨架如下databaseChangeLog: - changeSet: id: 1 # 变更集ID在同一文件中必须唯一通常从1开始顺序编号 author: your_name # 作者标识 changes: # 具体的变更操作放在这里比如 createTable, addColumn, insert 等4.2 创建表 (createTable)让我们先创建user表。databaseChangeLog: - changeSet: id: 1 author: zhangsan changes: - createTable: tableName: user remarks: 用户表 columns: - column: name: id type: bigint constraints: primaryKey: true nullable: false primaryKeyName: pk_user_id remarks: 主键ID - column: name: username type: varchar(50) constraints: nullable: false unique: true remarks: 用户名 - column: name: email type: varchar(100) constraints: nullable: false remarks: 邮箱 - column: name: created_at type: timestamp defaultValueComputed: CURRENT_TIMESTAMP remarks: 创建时间 - column: name: updated_at type: timestamp defaultValueComputed: CURRENT_TIMESTAMP remarks: 更新时间代码解读与注意事项id字段类型为bigint对应Java的Long。设置了主键 (primaryKey: true)、非空 (nullable: false) 约束并指定了主键约束名称 (primaryKeyName)。指定约束名称是个好习惯在后续需要删除约束时会很方便。username字段设置了唯一约束 (unique: true)。created_at和updated_at字段使用了defaultValueComputed: CURRENT_TIMESTAMP。这是一个强大的特性它允许你使用数据库的函数或表达式作为默认值。对于MySQL这会在插入数据时自动填入当前时间戳。注意对于更新时间戳我们通常还需要触发器或应用层逻辑来更新这里只是设置了默认值。remarks: 为表和列添加注释这会让你的数据库文档更清晰很多数据库客户端可以直接显示这些注释。4.3 添加第二个变更集创建post表并添加外键通常一个功能模块的初始化创建表、初始化数据可以放在一个changeSet里但为了演示我们新建一个changeSet来创建post表并建立它与user表的外键关系。- changeSet: id: 2 author: zhangsan changes: - createTable: tableName: post remarks: 文章表 columns: - column: name: id type: bigint constraints: primaryKey: true nullable: false remarks: 主键ID - column: name: title type: varchar(200) constraints: nullable: false remarks: 文章标题 - column: name: content type: text remarks: 文章内容 - column: name: author_id type: bigint constraints: nullable: false remarks: 作者ID外键关联user.id - column: name: status type: varchar(20) defaultValue: DRAFT remarks: 文章状态DRAFT, PUBLISHED - column: name: created_at type: timestamp defaultValueComputed: CURRENT_TIMESTAMP remarks: 创建时间 - column: name: published_at type: timestamp remarks: 发布时间 - addForeignKeyConstraint: baseTableName: post baseColumnNames: author_id constraintName: fk_post_author referencedTableName: user referencedColumnNames: id onDelete: RESTRICT # 或 CASCADE, SET NULL onUpdate: RESTRICT代码解读我们在同一个changeSet中定义了两个changes先createTable然后addForeignKeyConstraint。这确保了这两个操作作为一个原子单元执行。如果外键约束创建失败整个changeSet会回滚不会留下一个没有外键约束的post表。addForeignKeyConstraint操作清晰地定义了外键关系、约束名称以及删除和更新时的行为 (onDelete,onUpdate)。明确指定这些行为而不是依赖数据库默认值能使你的数据完整性策略更清晰。4.4 初始化数据 (insert) 修改表结构 (addColumn)现在假设我们需要为系统初始化一个管理员用户并且在后续迭代中需要给user表增加一个avatar_url头像链接字段。我们在changelog-v1.0.yaml文件中继续追加changeSet。- changeSet: id: 3 author: zhangsan changes: - insert: tableName: user columns: - column: name: username value: admin - column: name: email value: adminexample.com # 可以一次插入多条数据 # - insert: # tableName: user # columns: ...- changeSet: id: 4 author: zhangsan changes: - addColumn: tableName: user columns: - column: name: avatar_url type: varchar(255) remarks: 用户头像链接4.5 为变更集添加上下文 (context) 和标签 (labels)在实际项目中我们可能有些变更只想在特定环境如开发、测试执行或者有些数据初始化脚本只需要跑一次。Liquibase提供了context和labels来进行过滤。context (上下文)通常用于区分环境。例如我们有一个用于填充测试数据的变更集只希望在开发或测试环境运行。- changeSet: id: 5 author: zhangsan context: dev,test # 只有上下文包含 dev 或 test 时才会执行 changes: - insert: tableName: user columns: - column: name: username value: test_user - column: name: email value: testexample.com在application.properties中可以通过spring.liquibase.contextsdev来指定当前运行的上下文。如果不指定则所有变更集都会执行。labels (标签)用于更灵活的逻辑分组。比如你可以给所有“数据迁移”类的变更集打上migration标签给“基础表结构”打上baseline标签。运行时可以通过spring.liquibase.labelsbaseline来只执行带有该标签的变更集。- changeSet: id: 6 author: zhangsan labels: baseline, important changes: - createTable: tableName: category # ... 表结构定义合理使用上下文和标签可以让你的变更日志管理更加清晰和灵活。5. 运行、验证与常见问题排查编写好变更集后最激动人心的时刻就是运行它看看我们的数据库是否如预期般被创建和更新。5.1 首次运行与验证启动应用直接运行你的Spring Boot主类通常是带有SpringBootApplication注解的类。在启动日志中你应该能看到Liquibase相关的输出类似于INFO 12345 --- [ main] liquibase.lockservice : Successfully acquired change log lock INFO 12345 --- [ main] liquibase.changelog : Reading from your_database_name.DATABASECHANGELOG INFO 12345 --- [ main] liquibase.changelog : Custom SQL executed INFO 12345 --- [ main] liquibase.changelog : ChangeSet db/changelog/changelog-v1.0.yaml::1::zhangsan ran successfully in 15ms INFO 12345 --- [ main] liquibase.changelog : ChangeSet db/changelog/changelog-v1.0.yaml::2::zhangsan ran successfully in 8ms ... INFO 12345 --- [ main] liquibase.lockservice : Successfully released change log lock如果看到ran successfully恭喜你变更已成功执行检查数据库打开你的数据库客户端如MySQL Workbench, DBeaver等连接到目标数据库。你应该能看到user和post表已经创建并且有我们定义的字段、主键和外键。检查DATABASECHANGELOG表里面应该有4条记录对应我们写的4个changeSet包含了执行时间、MD5校验和等信息。检查user表应该有一条username为admin的记录。5.2 模拟迭代增加新变更现在假设我们进入了版本1.1的开发需要给post表增加一个view_count浏览量字段并给user表的username字段加上一个普通索引。创建新的变更文件changelog-v1.1.yaml并在db.changelog-master.yaml中引入它。db.changelog-master.yaml 更新后databaseChangeLog: - include: file: classpath:db/changelog/changelog-v1.0.yaml - include: file: classpath:db/changelog/changelog-v1.1.yamlchangelog-v1.1.yaml 内容databaseChangeLog: - changeSet: id: 1 # 注意这里的id是文件内唯一即可和v1.0文件里的id不冲突 author: lisi changes: - addColumn: tableName: post columns: - column: name: view_count type: int defaultValue: 0 constraints: nullable: false remarks: 文章浏览量 - createIndex: indexName: idx_user_username tableName: user columns: - column: name: username unique: false # 普通索引再次启动应用。Liquibase会检测到db.changelog-master.yaml中新增了一个文件并执行其中尚未被记录的changeSet。查看日志和数据库确认新字段和索引已添加成功。DATABASECHANGELOG表也会新增一条记录。5.3 常见问题与排查指南在实际集成过程中你可能会遇到一些“坑”。下面是一些常见问题及其解决方案问题1启动时报错liquibase.exception.ValidationFailedException: Validation Failed可能原因1变更集文件语法错误。YAML/XML格式不对比如缩进错误、标签未闭合。仔细检查报错位置附近的语法。可能原因2变更集被修改。这是最常见的原因。Liquibase发现DATABASECHANGELOG表中某个已执行变更集的MD5校验和与当前文件计算出的不一致。这意味着有人修改了历史变更文件。解决方案绝对不要直接修改已经应用到生产环境的变更集如果是在开发环境并且确定需要修改可以在开发数据库手动回滚该变更如果会的话。清除DATABASECHANGELOG表中对应记录仅限开发环境。或者在配置中设置spring.liquibase.clear-checksumstrue并重启一次让Liquibase重新计算并更新校验和同样仅限开发环境。正确的做法是编写一个新的变更集来修复或调整。例如如果你错误地删除了一个列应该写一个addColumn变更集来加回来而不是去改原来的dropColumn变更集。问题2变更执行失败如SQL语法错误、字段已存在等现象应用启动失败日志中显示具体的SQL执行错误。原因变更集本身的逻辑有问题比如试图创建一个已存在的表、添加一个已存在的字段、或SQL语句不符合当前数据库方言。排查仔细阅读错误信息定位到出错的changeSet(id, author, file)。检查该changeSet中的操作逻辑。可以使用Liquibase的updateSQL命令或Spring Boot的spring.liquibase.url指向一个空数据库来预览将要生成的SQL进行验证。检查数据库当前状态确认要执行的操作是否可行例如要添加唯一约束的列是否已有重复数据。修复修正变更集文件中的错误。由于该变更集执行失败它不会被记录到DATABASECHANGELOG中。修复后直接重启应用即可。问题3Liquibase锁表 (DATABASECHANGELOGLOCK)现象应用启动卡住日志显示Waiting for changelog lock...。原因上一个Liquibase运行实例异常终止如应用被强制杀死没有释放锁。DATABASECHANGELOGLOCK表中LOCKED字段为1且LOCKGRANTED时间很久远。解决方案手动解锁。连接到数据库执行SQLUPDATE DATABASECHANGELOGLOCK SET LOCKED 0, LOCKGRANTED NULL, LOCKEDBY NULL WHERE ID 1;。注意确保没有其他应用正在执行Liquibase变更。问题4多模块项目或复杂目录结构如何组织变更日志建议不要把所有变更都堆在一个目录下。可以按功能模块或发布版本来组织。db/changelog/ ├── db.changelog-master.yaml ├── module-auth/ # 认证授权模块 │ ├── 2024-01-01-init-tables.yaml │ └── 2024-06-01-add-column.yaml ├── module-blog/ # 博客模块 │ ├── 2024-01-01-init-tables.yaml │ └── 2024-07-01-add-index.yaml └── releases/ # 或按版本组织 ├── v1.0.0.yaml └── v1.1.0.yaml在主文件中使用includeAll时需注意顺序includeAll会按文件名的字母顺序包含可能不符合你的时间逻辑。通常更推荐在主文件中显式地include每一个文件以精确控制顺序。踩坑实录有一次在预发布环境同事修改了一个已执行过的变更集里的注释remarks以为只是改个注释没关系。结果导致下次部署时MD5校验失败整个应用启动不了。最后是通过在预发布环境临时设置spring.liquibase.clear-checksumstrue解决的但这也给我们提了个醒任何对历史变更文件的修改无论多小都必须视为高风险操作。最好的实践是将变更集文件视为只读的。任何修改都通过新增变更集来实现。6. 高级特性与生产实践建议当你熟悉了基础操作后下面这些高级特性和实践建议能让你的数据库版本管理更加稳健和高效。6.1 回滚操作 (rollback)Liquibase的强大之处在于它不仅支持前进update还支持回滚rollback。每个changeSet都可以定义其回滚操作。自动回滚对于一些简单的操作Liquibase可以自动生成回滚语句。例如对于createTable回滚就是dropTable对于addColumn回滚就是dropColumn。你不需要显式写出来。手动回滚对于复杂操作特别是insert、update、delete数据或者自定义SQL你必须显式指定回滚操作。- changeSet: id: 7 author: zhangsan changes: - insert: tableName: user columns: - column: name: username value: temp_user - rollback: delete: tableName: user where: usernametemp_user为什么回滚很重要在CI/CD流水线中如果新版本的部署失败我们需要能快速回滚到上一个稳定版本。这包括代码回滚和数据库回滚。Liquibase提供了liquibase rollback命令需要命令行工具可以回滚到指定的标签、日期或变更集ID。虽然Spring Boot应用本身不直接触发回滚但将其集成到你的部署脚本中是非常有价值的。6.2 使用预条件 (preConditions)预条件允许你在执行变更集之前检查某些条件是否满足只有条件为真时才执行。这可以增加变更集的安全性。- changeSet: id: 8 author: zhangsan preConditions: - onFail: MARK_RAN # 如果条件不满足则标记为已执行跳过而不是失败 - not: - tableExists: tableName: legacy_table changes: - createTable: tableName: new_table # ...上面的例子表示只有当legacy_table表不存在时才创建new_table。如果legacy_table已存在则跳过此变更集MARK_RAN。6.3 多环境配置策略不同环境开发、测试、生产的数据库配置、需要执行的变更集可能不同。配置文件分离使用Spring Boot的Profile特性。创建application-dev.properties,application-test.properties,application-prod.properties。上下文过滤如前所述使用context属性。在开发配置中设置spring.liquibase.contextsdev在测试配置中设置spring.liquibase.contextstest。那些标记了context: dev的变更集就只会在开发环境执行比如填充大量测试数据。独立的Liquibase配置对于生产环境你甚至可以考虑不通过应用启动来执行Liquibase而是在发布流程中使用Liquibase命令行工具由运维人员或自动化脚本在应用重启前手动执行。这样可以更严格地控制数据库变更的时机并进行人工复核。6.4 与JPA实体类的协同工作如果你同时使用JPAHibernate需要特别注意两者之间的分工。Liquibase负责DDL数据定义语言即创建、修改、删除表、列、索引、约束等结构。JPA实体类负责对象映射定义Java对象与数据库表的映射关系。spring.jpa.hibernate.ddl-autovalidate这是黄金配置。Hibernate在启动时会读取实体类注解与数据库中的实际表结构进行比对。如果发现不匹配比如实体类里有个字段avatarUrl但数据库表里没有avatar_url列应用就会启动失败。这形成了一个完美的闭环Liquibase保证数据库结构是预期的版本Hibernate验证代码中的实体模型与数据库一致。6.5 代码审查与上线流程数据库变更是高风险操作必须纳入严格的代码审查和上线流程。变更集文件必须纳入版本控制和源代码一样db/changelog/目录下的所有文件都应该提交到Git等版本控制系统。每次变更一个Pull Request无论是新功能需要加表还是修复Bug需要改字段都应该为相关的Liquibase变更集创建独立的Git分支和Pull Request。PR中必须包含SQL预览在PR描述中附上本次变更将会生成的SQL可以通过本地运行liquibase updateSQL命令获得。方便其他成员尤其是DBA或团队负责人进行审查。先在测试环境验证合并到主分支后CI/CD流水线应先将变更部署到测试环境确保无误后再进入生产发布流程。考虑备份对于重要的表结构变更或数据迁移在执行前告知相关人员并确认是否有必要进行数据库备份。6.6 使用Liquibase的其他格式除了YAMLLiquibase也支持XML、JSON和纯SQL格式。选择哪种取决于团队偏好。SQL格式优点是直观就是写原生SQL学习成本低。缺点是失去了数据库无关性且回滚操作需要手动编写反向SQL。对于复杂的、数据库特性相关的操作或者团队SQL能力很强时可以考虑。-- liquibase formatted sql -- changeset zhangsan:1 CREATE TABLE user ( id BIGINT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE ); -- rollback DROP TABLE user;注意SQL文件也需要特定的注释头-- liquibase formatted sql和-- changeset author:id来让Liquibase识别。我个人更推荐YAML格式它在可读性、结构化和简洁性上取得了很好的平衡并且是Spring Boot默认支持的格式。集成Liquibase到Spring Boot一开始可能会觉得多了一些配置和学习的成本但一旦团队熟悉了这个流程它带来的好处是巨大的数据库变更变得可追溯、可重复、可回滚彻底告别了“这表谁建的”“生产环境怎么少了这个字段”这类混乱的问题。它让数据库的版本管理和应用程序的版本管理真正同步了起来是迈向稳健的DevOps实践的关键一步。
