Flyway数据库版本管理：DevOps下的数据库CI/CD

数据库变更的"最后一道手工墙"

在大多数 DevOps 流水线中，应用代码的 CI/CD 已经高度自动化，但数据库变更仍然依赖 DBA 手动执行 SQL 脚本。这种"应用自动、数据库手动"的分裂状态，是生产故障的主要来源之一。

Flyway 的核心价值：将数据库 Schema 变更纳入版本控制系统，实现与应用代码同步的自动化部署。

Flyway 基础工作流

迁移脚本命名规范

Flyway 通过严格的命名约定来保证迁移顺序：

V{version}__{description}.sql
V1.0.0__create_user_table.sql
V1.0.1__add_email_column.sql
V1.0.2__create_order_table.sql

迁移脚本示例

-- V1.0.0__create_user_table.sql
CREATE TABLE users (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  username VARCHAR(50) NOT NULL UNIQUE,
  email VARCHAR(100) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- V1.0.1__add_email_column.sql  
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT FALSE;

-- 回滚脚本（仅 Flyway Teams 支持 Undo）
-- U1.0.1__add_email_column.sql
-- ALTER TABLE users DROP COLUMN email_verified;

Spring Boot 集成

<dependency>
  <groupId>org.flywaydb</groupId>
  <artifactId>flyway-core</artifactId>
</dependency>
<dependency>
  <groupId>org.flywaydb</groupId>
  <artifactId>flyway-mysql</artifactId>
</dependency>

spring:
  flyway:
    enabled: true
    locations: classpath:db/migration
    baseline-on-migrate: true
    validate-on-migrate: true

应用启动时，Flyway 自动执行未应用的迁移脚本，并更新 flyway_schema_history 表。

CI/CD 集成

GitHub Actions Pipeline

name: Database CI/CD
on:
  pull_request:
    paths:
      - "db/migration/**"

jobs:
  flyway-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validate Migrations
        run: |
          docker run --rm \
            -v $PWD/db/migration:/flyway/sql \
            flyway/flyway:10 \
            -url=jdbc:mysql://staging-db:3306/mydb \
            -user=${{ secrets.DB_USER }} \
            -password=${{ secrets.DB_PASS }} \
            validate

生产部署红线

绝不手动修改数据库：所有 DDL/DML 变更必须通过 Flyway 迁移脚本执行。
迁移前备份：生产环境迁移前务必执行全量备份或快照。
禁止修改已执行的迁移：已应用的迁移脚本不可修改 checksum，如需变更必须创建新的迁移版本。
大表变更谨慎：对亿级记录的表执行 ALTER TABLE 需评估锁表影响，考虑使用 pt-online-schema-change 等无锁方案。

总结

Flyway 将数据库变更从"祈求 DBA 帮忙跑 SQL"变成了可追溯、可回滚、可审计的自动化流水线。对于追求完全自动化 CI/CD 的团队，这是必不可少的一环。