GitLab流水线中FlyWay多数据库测试配置的技术问询

1. 方案可行性与更简便实现 #

你的方案完全可行，但有更贴近生产环境的简化方式：

• 不用切换H2，直接用Testcontainers在GitLab流水线中启动临时MariaDB容器。这样可以避免H2与MariaDB的语法差异导致测试结果失真，同时复用生产的基础迁移脚本，再单独执行测试数据脚本即可。
• 这种方式的优势是测试环境和生产环境数据库引擎一致，迁移脚本的兼容性问题能更早暴露，配置也更统一。

2. FlyWay适配多数据库的配置方法 #

完全可以实现，核心是通过环境配置切换数据源和FlyWay参数：

• 比如在Spring Boot项目中，定义不同的Profile（dev/test/prod），每个Profile对应不同的数据库连接信息和FlyWay配置：
  • 测试环境（GitLab流水线）加载test Profile，连接H2，指定包含测试数据的迁移脚本路径；
  • 生产/预发布环境加载prod/pre Profile，连接MariaDB，指定生产迁移脚本路径。
• 非Spring项目可以通过环境变量或者不同的配置文件，在执行FlyWay命令时指定不同的配置参数，比如：

  # 测试环境执行H2迁移
  flyway -configFiles=flyway-test.conf migrate
  # 生产环境执行MariaDB迁移
  flyway -configFiles=flyway-prod.conf migrate
  

3. 区分生产与测试迁移脚本的其他方式 #

占位符不是唯一方式，还有几种更直观的方案：

• 按环境分目录：将生产脚本放在db/migration/prod，测试脚本放在db/migration/test，然后通过flyway.locations参数指定当前环境要加载的目录，比如测试环境设为db/migration/prod,db/migration/test，生产环境只设db/migration/prod。
• 脚本命名后缀区分：给测试专属脚本添加后缀，比如V2__add_test_data.test.sql，然后通过flyway.sqlMigrationSuffixes参数指定当前环境识别的后缀，测试环境设为.sql,.test.sql，生产环境只设.sql。
• 自定义脚本过滤器：通过FlyWay的API实现自定义的MigrationResolver，根据环境过滤要执行的脚本，这种方式适合复杂的场景，但配置成本较高。

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