1概述

​ 本规范规定了，软件项目团队管理数据库版本的流程规范。推荐使用flyway工具进行数据库版本管理。

2 flyway配置

   在项目各环境dev|preview|pro|test的yml文件中增加flyway配置，示例：

spring:

  flyway:

    #是否开启flyway，默认true

    enabled: true

    # 脚本存放路径，一般配置在 /src/resources/db/migration下，如果系统使用多数据源则这里写主库路径，然后编写配置类进行转换

    locations: classpath:db/migration

    # 非空数据库初始化flyway时需要打开此开关进行Baseline操作

    baseline-on-migrate: true

    # 是否可以无序执行。开发环境最好开启 outOfOrder， 生产环境关闭 outOfOrder

    out-of-order: false

    # 版本历史记录表，默认为flyway_schema_history，

    table: flyway_schema_history

    # 迁移前校验 SQL 文件是否存在问题

    validate-on-migrate: false

    # 是否进行el变量替换

    placeholder-replacement: false

    # clean命令会在执行脚本前删除已有库下的所有 table， 默认为false，生产环境务必设置为true

    clean-disabled: true

3命名规范

​ 软件数据库以sql脚本形式进行版本管理，sql脚本的命名必须规范，具体要求如下：

1. 用于版本升级的sql脚本以大写的 "V" 为前缀 ，命名为V + 版本号 ( 程序版本+日期+ 数字，版本号以 ”.“ 分隔开)  + 双下划线 ( 用来分隔版本号和文件描述 ) + 文件描述 (用”_“ 分隔开，以操作类型开头，以作者结尾 ) + 后缀名。每个版本有唯一的版本号并且只能执行一次。示例：V1.5.00.20221016.2__ddl_create_user_lizz.sql。
2. 可重复运行的sql脚本以大写的 “R” 为前缀，命名为R + 双下划线 + 文件描述 ( 用 ”_“ 分隔开，以操作类型结尾 ) + 后缀名，只要脚本内容发生变化重启后就会执行。示例：R__truncate_user_dml.sql 。
3.  文件描述中的操作类型包括：init - 用于初始化，ddl - 用于定义或变更表结构，dml - 用于变更数据，dcl - 用于设置或更改数据库用户或角色权限。

4 开发规范

  通过在项目中配置，flyway 会在 application 启动时自动按顺序执行扫描路径下的 sql脚本文件。开发中建议遵循以下规范：

1. 多个系统公用一个数据库时需配置spring.flyway.table ，为不同的系统设置不同的版本历史记录表而不使用缺省值 flyway_schema_history 。
2. 所有的脚本一旦执行就会在 flyway_schema_history 表中有记录，如果更新出错可以手动从 flyway_schema_history 表中删除记录，然后修改 sql脚本后再重新启动（生产环境不建议）。
3. flyway自身无法区分数据源连接，为支持多数据源版本管理，需将多数据源对应的sql脚本分开存放，并增加FlywayConfig配置类。
4. 禁止修改已执行的sql脚本（已执行的定义：sql脚本已合并到公共分支，且 flyway_schema_history 表里已有该条记录），如需修改已执行脚本涉及的表，必须新增sql脚本进行版本升级。
5. 禁止提交执行失败的sql脚本，本地新增 sql脚本，application 启动成功后，再提交代码到远程。