SpringBoot1.5.6集成Flyway

What？

       Flyway一款开源的数据库版本管理工具，它更倾向于规约优于配置的方式。Flyway可以独立于应用实现管理并跟踪数据库变更，支持数据库版本自动升级，并且有一套默认的规约，不需要复杂的配置，Migrations可以写成SQL脚本，也可以写在Java代码中，不仅支持Command Line和Java API，还支持Build构建工具和Spring Boot等，同时在分布式环境下能够安全可靠地升级数据库，同时也支持失败恢复等。

        通俗易懂的讲，像git管理代码一样管理数据库的sql，从而做到SQL同步。

Why？

现状以及存在问题

      在公司都是团队伙伴协同开发，sql的变动很难做到全部有迹可循，而且当存在多套环境，而且系统运行环境每晚与线上同步，经常性造成因为SQL变动造成开发，测试，仿真等环境使用异常，公司目前采取的解决方案是将让大家变动的SQL放到一个脚本中，每次数据同步后自动执行脚本内容，但是脚本目前只应用于开发，测试。仿真环境需要手动操作，而且如果忘记配置到脚本中，在其他环境同样会出现异常。系统和sql变动并非原子性的操作，非常容易发生问题，还有一点，就是当没有配置脚本的开发未在公司时，大部分恢复环境都需要远程沟通或者等待，这也是很浪费一种现象存在。即便这样，例如表结构的变动仍然无迹可寻。  

解决

      1、sql变动可以被追踪

       2、避免多环境脚本忘记配置造成的不可用

       3、减轻运维工作量，现在每个sql变动都需要审核平台工单批准，即便是正常上线的项目，这样省去开发->负责人->dba的审核流程

How？

      官网:https://flywaydb.org

      因为springboot版本的原因，暂时无法使用flyway的最新版本,小编使用的版本为5.2.4

1、引入maven依赖

      
            org.flywaydb
            flyway-core
            5.2.4
        

2、引入maven插件

          
                org.flywaydb
                flyway-maven-plugin
                5.2.4
            

3、application.yml相关配置

flyway:
  enabled: true  //是否启用，默认启用
//使用生成基准默认为false（半路接入的项目，需要配置，相当于画一个分割线，在基准线之前的sql不予管理，
默认从此之后的sql变动flyway处理），如果全新的项目schema为空可以使用默认值false，
如果迁移项目不配置此项会造成flyway相关类初始化不成功，项目无法启动
  baselineOnMigrate: true 
//配置sql加载路径，默认为db/migration,配置此项可以解决配置sql，却不执行的问题
  locations: db/migration,db/migration-mock
//sql版本是否可以不按顺序执行，默认为false，例如，项目配置了V1，V3sql都执行过，但是此时加入V2，如果采用默认值V2不会执行，设置为true，
此时V2的sql将被执行，建议开发环境开启，生产环境禁用
  outOfOrder: true

4、创建sql存放目录

     在resource下创建db/migration

配置上述几项内容，此时springboot和flyway集成过程完成。

关于flyway的几项内容，

1、关于sql文件命名

 

其中的文件名由以下部分组成，除了使用默认配置外，某些部分还可自定义规则。

• prefix: 可配置，前缀标识，默认值V表示Versioned，R表示Repeatable
• version: 标识版本号，由一个或多个数字构成，数字之间的分隔符可用点.或下划线_
• separator: 可配置，用于分隔版本标识与描述信息，默认为两个下划线__
• description: 描述信息，文字之间可以用下划线或空格分隔
• suffix: 可配置，后续标识，默认为.sql

注意：

    V代表版本，需要有数字用于版本号的标识

    R代表此SQL文件可以重复执行，只有R后面不能加数字，当带有R作为开头命名的sql文件，每当sql文件有变动，整个SQL文件都会被执行，所以使用此种需要慎重

 2、全部配置项

flyway.baseline-description对执行迁移时基准版本的描述.
flyway.baseline-on-migrate当迁移时发现目标schema非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认false.
flyway.baseline-version开始执行基准迁移时对现有的schema的版本打标签，默认值为1.
flyway.check-location检查迁移脚本的位置是否存在，默认false.
flyway.clean-on-validation-error当发现校验错误时是否自动调用clean，默认false.
flyway.enabled是否开启flywary，默认true.
flyway.encoding设置迁移时的编码，默认UTF-8.
flyway.ignore-failed-future-migration当读取元数据表时是否忽略错误的迁移，默认false.
flyway.init-sqls当初始化好连接时要执行的SQL.
flyway.locations迁移脚本的位置，默认db/migration.
flyway.out-of-order是否允许无序的迁移，默认false.
flyway.password目标数据库的密码.
flyway.placeholder-prefix设置每个placeholder的前缀，默认${.
flyway.placeholder-replacementplaceholders是否要被替换，默认true.
flyway.placeholder-suffix设置每个placeholder的后缀，默认}.
flyway.placeholders.[placeholder name]设置placeholder的value
flyway.schemas设定需要flywary迁移的schema，大小写敏感，默认为连接默认的schema.
flyway.sql-migration-prefix迁移文件的前缀，默认为V.
flyway.sql-migration-separator迁移脚本的文件名分隔符，默认__
flyway.sql-migration-suffix迁移脚本的后缀，默认为.sql
flyway.tableflyway使用的元数据表名，默认为schema_version
flyway.target迁移时使用的目标版本，默认为latest version
flyway.url迁移时使用的JDBC URL，如果没有指定的话，将使用配置的主数据源
flyway.user迁移数据库的用户名
flyway.validate-on-migrate迁移时是否校验，默认为true.

总结

      整个开发过程中配套的工具都已经很完善了，只是当前的知识储备还很有限，不能飘，需要沉下来，认真解决问题，积累，厚积薄发，不负时光，！