如何使用Gitlab CI测试数据库迁移 适配旧版本数据库状态

前置配置要求 #

• 项目开启GitLab制品存储功能，保留每次构建产出的应用镜像标签、对应版本的数据库初始化脚本，保留周期可按分支规则设置，比如常规分支保留最近5次构建的关联制品，MR临时制品保留7天即可。
• 给k8s自托管Runner配置对应命名空间的操作权限：允许Runner在CI任务专属命名空间下临时创建数据库实例、拉取历史应用镜像、启动/销毁临时Pod。

场景1：常规分支推送的测试流程 #

向普通开发/发布分支推送代码触发CI时，按以下步骤执行：

1. 调用GitLab CI API查询当前分支最近一次构建成功的应用镜像标签，若为分支首次构建无历史版本，则直接跳过该测试，仅执行默认的空库迁移测试即可。
2. 用kubectl创建临时数据库Pod，启动旧版本应用Pod连接该数据库，执行旧版本的全量初始化逻辑，生成对应版本的数据库状态，初始化完成后销毁旧版本应用Pod，保留数据库服务。
3. 启动当前提交构建的新版本应用Pod，连接上述旧版本数据库，启动应用自动触发数据库迁移流程。
4. 执行校验逻辑：首先确认应用无报错正常启动，其次执行预设的数据库读写校验（基础增删改查、表结构校验、核心业务数据完整性校验），所有校验项通过则测试通过，否则直接阻断后续CI流程。
5. 测试结束后自动销毁本次任务创建的所有临时k8s资源。

场景2：合并请求（MR）的测试流程 #

创建或更新MR触发CI时，按以下步骤执行：

1. 调用GitLab CI API查询MR目标分支最近一次构建成功的应用镜像标签。
2. 后续执行逻辑和常规分支场景完全一致：生成目标分支版本的数据库状态，用当前MR分支的版本执行迁移和校验。
3. 该测试项必须通过才可允许MR合并，可在GitLab项目的合并请求设置中配置为合并前置检查项。

配置优化建议 #

• 用GitLab CI内置变量即可区分场景：$CI_COMMIT_BRANCH对应普通分支推送场景，$CI_MERGE_REQUEST_TARGET_BRANCH_NAME对应MR场景的目标分支，无需额外配置自定义变量。
• 临时数据库可使用k8s临时存储类或空卷，不需要长期持久化，测试结束自动销毁即可，不会占用额外存储资源。
• 可将整个测试流程封装为可复用的GitLab CI模板，所有需要做迁移兼容性测试的项目直接引用模板即可，无需重复编写配置。

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