在 gitlab ci 中安全运行数据库迁移需集成 migrate 工具、规范迁移文件命名与路径、通过加密变量配置数据库连接、为 ci 创建专用低权限用户，并在独立 stage 中执行 up 命令且失败时中断流水线。

在 GitLab CI 中运行数据库迁移，核心是把 migrate 工具集成进流水线的某个 stage，让它连接目标数据库、比对当前版本、执行未应用的 .up.sql 脚本。关键不在“能不能跑”，而在于“安全地跑”——避免重复执行、跳过失败、误操作生产库。

确保迁移工具在 CI 环境中可用

GitLab Runner 默认不带 migrate 命令。你有三种可靠方式提供它：

• 在 .gitlab-ci.yml 的 job 中用 go install 动态安装（推荐）：
  go install github.com/golang-migrate/migrate/v4/cmd/migrate@latest
• 使用预装 migrate 的 Docker 镜像，例如 minio/mc 或自建镜像（需确认含对应数据库驱动，如 -tags 'postgres'）
• 将编译好的 migrate 二进制文件放入项目 bin/ 目录并提交，CI 中直接调用 ./bin/migrate

正确组织迁移文件与路径

迁移脚本必须结构清晰、命名规范，否则 migrate 无法识别顺序：

Git Manager

git-manager 让 AI 化身 Git 操作助手，覆盖日常开发中的高频场景。 核心能力 git_ops.py — 单仓库操作，27 个子命令：clone/pull/push/fetch、branch/checkout/merge/rebase、log/diff/status/show/blame、tag/remote/stash/reflog、worktree/bisect/grep、cherry-pick/revert、LFS 集成 batch_clone.py — 批量克隆 GitHub /

下载

• 统一存放在 migrations/（或 database/migrations/），不要嵌套无关目录
• 文件名格式严格为：时间戳_描述.up.sql 和 时间戳_描述.down.sql（如 1718234567_add_email_index.up.sql）
• 确保 .up.sql 和 .down.sql 成对出现，且内容逻辑匹配；单个脚本内 SQL 语句应幂等（比如用 CREATE TABLE IF NOT EXISTS）

配置安全可靠的数据库连接

绝不能把数据库密码硬编码在 .gitlab-ci.yml 里：

• 在 GitLab 项目设置 → CI/CD → Variables 中定义加密变量：DB_URL（格式如 postgres://user:$DB_PASSWORD@db:5432/app?sslmode=disable），再单独设 DB_PASSWORD
• 或使用 migrate -env 加载 .env 文件（该文件需 .gitignore 排除，仅 CI runner 挂载）
• 强烈建议为 CI 迁移创建专用数据库用户，只赋予 CREATE、ALTER、DROP 等必要权限，禁用 DELETE FROM pg_catalog 类高危操作

在 .gitlab-ci.yml 中定义迁移 job

迁移 job 应独立 stage，且放在构建和测试之后、部署之前：

• 指定明确的 image（如 golang:1.22），避免依赖缓存镜像的不确定性
• 用 migrate -path migrations/ -database $DB_URL up 执行升级；加 -verbose 查看实际执行了哪些文件
• 设置 allow_failure: false 并配合 when: on_success，确保迁移失败时整条流水线中断，不继续部署
• 可选：对预发环境加 dry-run 检查（migrate -path migrations/ -database $DB_URL goto latest -dry-run）

迁移不是“执行一次就完事”，而是持续校验状态的过程。只要路径、变量、权限三者对齐，每次推送新迁移文件后，CI 就会自动把它应用到对应环境。