数据库版本控制Flyway+Maven的具体实现

1.  引言

想到要管理数据库的版本，是在实际产品中遇到问题后想到的一种解决方案，当时各个环境的数据库乱作一团，没有任何一个人（开发、测试、维护人员）能够讲清楚当前环境下的数据库是哪个版本，与哪个版本的应用相匹配，如何升级到与新版本的应用相匹配。

想到管理数据库版本时，先是心底形成了一个初步的解决方案，大致是通过数据库中的某张表来记录数据库表结构的历次更新与对应版本，在每次数据库表结构调整时除了提供库表更新sql ，还必须提供更新记录与对应版本的sql，以帮助维护数据库版本信息，并在遇到问题时提供相关的排查依据。

后来据此思路在网络上搜索了一把，结果搜到Liquibase （另一款开源数据库版本管理工具）。在学习了解Liquibase 的时候，经高手介绍又了解到了Flyway 这个项目的存在。经过一番了解，最后我们选择了Flyway ，主要原因是Flyway 支持sql 脚本，而Liquibase 只支持XML 方式的数据库表结构定义，虽然在新的版本中号称在XML 的数据库表结构定义方式中支持了sql 脚本。

虽然Flyway 的中文文档近乎为零，英文文档也凤毛麟角，但它却是我们最理想的数据库版本管理工具，它不但支持sql 脚本，还支持Java 代码直接操作数据库（在版本升级时做数据迁移相当有用），有Maven 插件，支持命令行（我们的平台数据库有部分由C 语言项目管理），而且在Spring 框架的配合下，很容易就能实现应用启动时自动检查并升级数据库的功能。

2.  什么是Flyway

Flyway 是独立于数据库的应用、管理并跟踪数据库变更的数据库版本管理工具。

Flyway 的项目主页是  http://flywaydb.org/  ），在项目的主页上可以看到Flyway 与几款主流数据库版本管理工具的特性对比列表。

3.  为什么使用Flyway

3.1. 我们遇到的问题

我们遇到的问题（以下内容来自Flyway 的一些英文文档，从中抽取出来的我们也遇到的一些主要问题）：

• 不同的开发人员在开发产品特性时，都有可能更新数据库（添加新表，新的约束等）。当开发人员完成工作并提交代码时，代码会被合并到主分支并在测试服务器上执行单元测试与集成测试。我们在哪个环节来执行数据库的更新操作呢？由QA 部门手工执行sql 脚本？或者我们开发一断程序自动执行数据库更新？以什么顺序来执行这些更新脚本？这些问题同样存在于生产环境。 
• 我们的产品部署在不同的客户服务器上，以及很多的测试、联调、实验局、销售环境上。不同的客户和测试环境上都部署着不同版本的产品。当他们需要升级他们的产品到新的版本时，我们不仅需要让他们的管理员可以升级产品到新的版本，同时需要保留他们的已有数据。在升级产品的步骤中，我们清楚地知道客户数据库的当前版本，以及需要在该数据库上执行哪些数据库更新脚本，来更新数据库表结构与数据库中已存在的数据。当升级完成时，数据库表结构及数据应当与升级后的产品版本保持一致。
• 有的时候，我们需要通过代码（Java ）来维护一些已存在的数据，如通过代码来维护blob 类型的用户头像数据。
• 当升级失败时（比如在升级过程中出现网络连接失败），我们应当支持对失败进行修复。

3.2. Flyway 的特性

• 自动升级（自动发现更新项）：Flyway 会将任意版本的数据库升级到最新版本。Flyway 可以脱离JVM 环境通过命令行执行，可以通过Ant 脚本执行，通过Maven 脚本执行（这样就可以在集成环境自动执行），并且可以在应用中执行（比如在应用启动时执行）。
• 规约优于配置：Flyway 有一套默认的规约，所以不需要修改任何配置就可以正常使用。
• 既支持SQL 脚本，又支持Java 代码：可以使用SQL 脚本执行数据库更新，也可以使用Java 代码来进行一些高级数据升级操作。
• 高可靠性：在集群环境下进行数据库升级是安全可靠的。
• 支持清除已存在的库表结构：Flyway 可以清除已存在的库表结构，可以从零开始搭建您的库表结构，并管理您的数据库版本升级工作。
• 支持失败修复。新的2.0 版本提供了repair 功能，用于解决数据库更新操作失败问题。
• 结合我们遇到的问题，与Flyway 所提供的特性，我们认为Flyway 是比较适合于我们的一款数据库版本管理工具。

4.  如何使用Flyway

使用Flyway ，我们需要准备Flyway 将要执行的数据库脚本（Flyway 支持sql 脚本与java 代码，这里认为在Flyway 下执行数据库更新操作的java 代码也是一种数据库脚本），然后通过Flyway 提供的几种不同运行方式来执行这些脚本。 （以下配置参数说明基于Flyway 4.1.0 版本）

4.1. 数据库脚本