借助Jenkins将Flyway集成到现有项目数据库的操作方案咨询

原流程可行性判断 #

你梳理的流程逻辑上可以完成Flyway的接入，但存在两处明显不合理的设计：

• 完全不需要执行flyway clean清空开发库：该操作风险极高，误操作到带业务数据的环境会造成不可逆的数据损失，且现有开发库已经有符合预期的结构和测试数据，清空后重建属于冗余操作
• 基线版本和初始脚本版本的衔接设计冗余：不需要单独设置1.0.0的基线再跑1.0.1的初始脚本，两步可以合并简化

更优的接入方案 #

统一前置准备 #

• 导出当前生产/测试/开发环境完全对齐的全量基准DDL+必要基础DML，命名为V1_0_0__initial_base_schema.sql
• 在Flyway配置文件中添加flyway.cleanDisabled=true，全局禁用clean操作，避免误执行风险

各存量环境接入步骤 #

所有已经在运行的环境（开发/测试/生产）统一执行以下操作：

1. 不需要修改任何现有业务表结构和数据，直接执行flyway baseline -baselineVersion=1.0.0 -baselineDescription="Pre-Flyway baseline"
2. 该命令只会在库中新增Flyway自带的flyway_schema_history版本管理表，标记1.0.0版本已经执行完成，不会对现有业务数据产生任何影响

后续使用规范 #

• 所有新的数据库变更脚本均使用高于1.0.0的版本号命名，比如V1_0_1__add_account_table.sql、V1_0_2__add_user_mobile_unique_index.sql
• Jenkins发布流程中加入flyway migrate执行步骤，每次发布时自动执行当前版本所有未执行的SQL脚本
• 新增脚本必须保证幂等性，比如建表前添加IF NOT EXISTS判断、修改字段前先校验字段是否存在，避免重复执行报错

新开发环境初始化流程 #

新同事搭建本地开发环境时，不需要做基线操作，直接执行flyway migrate即可自动从V1_0_0开始执行所有脚本，快速得到和线上完全一致的库结构。

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