什么是Flyway?
Flyway is an open-source database migration tool. It strongly favors simplicity and convention over configuration.
Flyway是一款開源的數據庫版本管理工具，它更傾向於規約優於配置的方式。Flyway可以獨立於應用實現管理並跟蹤數據庫變更，支持數據庫版本自動升級，並且有一套默認的規約，不需要復雜的配置，Migrations可以寫成SQL腳本，也可以寫在Java代碼中，不僅支持Command Line和Java API，還支持Build構建工具和Spring Boot等，同時在分布式環境下能夠安全可靠地升級數據庫，同時也支持失敗恢復等。
Flyway主要基於6種基本命令：Migrate, Clean, Info, Validate, Baseline and Repair，稍候會逐一分析講解。目前支持的數據庫主要有：Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS, MySQL(including Amazon RDS), MariaDB, Google Cloud SQL, PostgreSQL(including Amazon RDS and Heroku), Redshift, Vertica, H2, Hsql, Derby, SQLite, SAP HANA, solidDB, Sybase ASE and Phoenix.
關於Flyway的優勢，支持的數據庫以及與其他數據庫版本工具的對比，可以閱讀Flyway官網介紹。
為什么使用Flyway?
通常在項目開始時會針對數據庫進行全局設計，但在開發產品新特性過程中，難免會遇到需要更新數據庫Schema的情況，比如：添加新表，添加新字段和約束等，這種情況在實際項目中也經常發生。那么，當開發人員完成了對數據庫更的SQL腳本后，如何快速地在其他開發者機器上同步？並且如何在測試服務器上快速同步？以及如何保證集成測試能夠順利執行並通過呢？
假設以Spring Boot技術棧項目為例，可能有人會說，本地使用Hibernate自動更新數據庫Schema模式，然后讓QA或DEV到測試服務器上手動執行SQL腳本，同時可以寫一個Gradle任務自動執行更新。
個人覺得，對於Hibernate自動更新數據庫，感覺不靠譜，不透明，控制自由度不高，而且有時很容易就會犯錯，比如：用SQL創建的某個字段為VARCHAR類型，而在Entity中配置的為CHAR類型，那么在運行集成測試時，自動創建的數據庫表中的字段為CHAR類型，而實際SQL腳本期望的是VARCHAR類型，雖然測試通過了，但不是期望的行為，並且在本地bootRun或服務器上運行Service時都會失敗。另外，到各測試服務器上手動執行SQL腳本費時費神費力的，干嘛不自動化呢，當然，對於高級別和PROD環境，還是需要DBA手動執行的。最后，寫一段自動化程序來自動執行更新，想法是很好的，那如果已經有了一些插件或庫可以幫助你更好地實現這樣的功能，為何不好好利用一下呢，當然，如果是為了學習目的，重復造輪子是無可厚非的。
其實，以上問題可以通過Flyway工具來解決，Flyway可以實現自動化的數據庫版本管理，並且能夠記錄數據庫版本更新記錄，Flyway官網對Why database migrations結合示例進行了詳細的闡述，有興趣可以參閱一下。
Flyway如何工作的?
Flyway對數據庫進行版本管理主要由Metadata表和6種命令完成，Metadata主要用於記錄元數據，每種命令功能和解決的問題范圍不一樣，以下分別對metadata表和這些命令進行闡述，其中的示意圖都來自Flyway的官方文檔。
Metadata Table
Flyway中最核心的就是用於記錄所有版本演化和狀態的Metadata表，在Flyway首次啟動時會創建默認名為SCHEMA_VERSION的元數據表，其表結構為(以MySQL為例)：
| Field | Type | Null | Key | Default |
|---|---|---|---|---|
| version_rank | int(11) | NO | MUL | NULL |
| installed_rank | int(11) | NO | MUL | NULL |
| version | varchar(50) | NO | PRI | NULL |
| description | varchar(200) | NO | NULL | |
| type | varchar(20) | NO | NULL | |
| script | varchar(1000) | NO | NULL | |
| checksum | int(11) | YES | NULL | |
| installed_by | varchar(100) | NO | NULL | |
| installed_on | timestamp | NO | CURRENT_TIMESTAMP | |
| execution_time | int(11) | NO | NULL | |
| success | tinyint(1) | NO | MUL | NULL |
Flyway官網上提供了一個很清晰的示例How Flyway works，可以參閱一下。
Migrate
Migrate是指把數據庫Schema遷移到最新版本，是Flyway工作流的核心功能，Flyway在Migrate時會檢查Metadata(元數據)表，如果不存在會創建Metadata表，Metadata表主要用於記錄版本變更歷史以及Checksum之類的。
Migrate時會掃描指定文件系統或Classpath下的Migrations(可以理解為數據庫的版本腳本)，並且會逐一比對Metadata表中的已存在的版本記錄，如果有未應用的Migrations，Flyway會獲取這些Migrations並按次序Apply到數據庫中，否則不需要做任何事情。另外，通常在應用程序啟動時應默認執行Migrate操作，從而避免程序和數據庫的不一致性。
Clean
Clean相對比較容易理解，即清除掉對應數據庫Schema中的所有對象，包括表結構，視圖，存儲過程，函數以及所有的數據等都會被清除。
Clean操作在開發和測試階段是非常有用的，它能夠幫助快速有效地更新和重新生成數據庫表結構，但特別注意的是：不應在Production的數據庫上使用！
Info
Info用於打印所有Migrations的詳細和狀態信息，其實也是通過Metadata表和Migrations完成的，下圖很好地示意了Info打印出來的信息。
Info能夠幫助快速定位當前的數據庫版本，以及查看執行成功和失敗的Migrations。
Validate
Validate是指驗證已經Apply的Migrations是否有變更，Flyway是默認是開啟驗證的。
Validate原理是對比Metadata表與本地Migrations的Checksum值，如果值相同則驗證通過，否則驗證失敗，從而可以防止對已經Apply到數據庫的本地Migrations的無意修改。
Baseline
Baseline針對已經存在Schema結構的數據庫的一種解決方案，即實現在非空數據庫中新建Metadata表，並把Migrations應用到該數據庫。
Baseline可以應用到特定的版本，這樣在已有表結構的數據庫中也可以實現添加Metadata表，從而利用Flyway進行新Migrations的管理了。
Repair
Repair操作能夠修復Metadata表，該操作在Metadata表出現錯誤時是非常有用的。
Repair會修復Metadata表的錯誤，通常有兩種用途：
- 移除失敗的Migration記錄，該問題只是針對不支持DDL事務的數據庫。
- 重新調整已經應用的Migratons的Checksums值，比如：某個Migratinon已經被應用，但本地進行了修改，又期望重新應用並調整Checksum值，不過盡量不要這樣操作，否則可能造成其它環境失敗。
如何使用Flyway?
這里將主要關注在Gradle和Spring Boot中集成並使用Flyway，數據庫通常會采用MySQL、PostgreSQL、H2或Hsql等。
正確創建Migrations
Migrations是指Flyway在更新數據庫時是使用的版本腳本，比如：一個基於Sql的Migration命名為V1__init_tables.sql，內容即是創建所有表的sql語句，另外，Flyway也支持基於Java的Migration。Flyway加載Migrations的默認Locations為classpath:db/migration，也可以指定filesystem:/project/folder，其加載是在Runtime自動遞歸地執行的。
除了需要指定Location外，Flyway對Migrations的掃描還必須遵從一定的命名模式，Migration主要分為兩類：Versioned和Repeatable。
-
Versioned migrations
一般常用的是Versioned類型，用於版本升級，每一個版本都有一個唯一的標識並且只能被應用一次，並且不能再修改已經加載過的Migrations，因為Metadata表會記錄其Checksum值。其中的version標識版本號，由一個或多個數字構成，數字之間的分隔符可以采用點或下划線，在運行時下划線其實也是被替換成點了，每一部分的前導零會被自動忽略。 -
Repeatable migrations
Repeatable是指可重復加載的Migrations，其每一次的更新會影響Checksum值，然后都會被重新加載，並不用於版本升級。對於管理不穩定的數據庫對象的更新時非常有用。Repeatable的Migrations總是在Versioned之后按順序執行，但開發者必須自己維護腳本並且確保可以重復執行，通常會在sql語句中使用CREATE OR REPLACE來保證可重復執行。
默認情況下基於Sql的Migration文件的命令規則如下圖所示：
其中的文件名由以下部分組成，除了使用默認配置外，某些部分還可自定義規則。
- prefix: 可配置，前綴標識，默認值
V表示Versioned，R表示Repeatable - version: 標識版本號，由一個或多個數字構成，數字之間的分隔符可用點
.或下划線_ - separator: 可配置，用於分隔版本標識與描述信息，默認為兩個下划線
__ - description: 描述信息，文字之間可以用下划線或空格分隔
- suffix: 可配置，后續標識，默認為
.sql
另外，關於如何使用基於Java的Migrations，有興趣可以參考Java-based migrations。
支持的數據庫
目前Flyway支持的數據庫還是挺多的，包括：Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS, MySQL(including Amazon RDS), MariaDB, Google Cloud SQL, PostgreSQL(including Amazon RDS and Heroku), Redshift, Vertica, H2, Hsql, Derby, SQLite, SAP HANA, solidDB, Sybase ASE and Phoenix。
目前來說，個人用得比較多的數據庫是PostgreSQL、MySQL、H2和Hsql，針對每種數據庫的flyway.url示例配置為：
1 |
# PostgreSQL |
Flyway命令行
Flyway的命令行工具支持直接在命令行中運行Migrate, Clean, Info, Validate, Baseline和Repair6種命令，不需要借助其他Build工具，不需要應用程序運行在JVM中，只需要單純的命令行即可，但需要根據不同的操作系統下載並安裝該命令行工具。Flyway會依次搜索以下配置文件，越靠后的配置會覆蓋靠前的配置：
- /conf/flyway.conf
- /flyway.conf
- /flyway.conf
一個典型Flyway項目示例目錄結構如下：
更多關於Flyway命令行使用可以參考Flyway Command-line。
在Gradle中的應用
首先需要在Gradle中引入Flyway插件，通常有兩種方式：
-
方式一：采用buildscript依賴方式。
1
2
3
4
5
6
7
8
9buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath("org.flywaydb:flyway-gradle-plugin:4.0.3")
}
}
apply plugin: 'org.flywaydb.flyway' -
方式二（推薦）：采用DSL方式引用Plugins。
1
2
3plugins {
id "org.flywaydb.flyway" version "4.0.3"
}
而在Gradle中配置Flyway Properties有兩種方式：
-
方式一：在
build.gradle中配置Flyway Properties。1
2
3
4
5
6
7
8
9
10flyway {
url = jdbc:h2:./.tmp/testdb
user = sa
password =
}
# 或者寫成：
project.ext['flyway.url'] = 'jdbc:h2:./.tmp/testdb'
project.ext['flyway.user'] = 'sa'
project.ext['flyway.password'] = '' -
方式二：在
gradle.properties中配置Flyway Properties。1
2
3flyway.url = jdbc:h2:./.tmp/testdb
flyway.user = sa
flyway.password =
如果期望在運行Gradle Clean/Build Tasks時自動執行Flyway的某些任務，可以設置dependsOn，若不期望隱式執行Flyway任務，可以不配置。
1 |
clean.dependsOn flywayRepair # To repair the Flyway metadata table |
另外，其它Tasks：flywayInfo, flywayValidate, flywayBaseline分別對應到Flyway的命令。在使用Spring Boot時，運行./gradlew bootRun會自動檢查並加載最新的db.migration腳本。
特別注意：在Production環境中不應執行./gradlew flywayClean，除非你知道自己的行為和目的，因為該命令會清除所有的數據庫對象，相當危險。
更多關於Flyway在Gradle中的使用請參閱Flyway Gradle Plugin。
與Spring Boot集成
在Spring Boot中，如果加入Flyway的依賴，則會自動引用Flyway並使用默認值，但可以修改並配置FlywayProperties。
1 |
flyway.baseline-description= # The description to tag an existing schema with when executing baseline. |
若使用Gradle，通常在build.gradle引入org.flywaydb:flyway-core:4.0.3依賴后即可使用。可能會有以下幾種需求：
-
在本地Run和Tests都會使用內存數據庫，其中的
spring.jpa.hibernate.ddl-auto都設置為validate，Schema不需要Hibernate自動生成，並期望使用Flyway，而在線上環境會使用真實數據庫，並不期望使用Flyway，如何實現呢？
解決方案：可以在common.properties中配置flyway.enabled=false，然后在local或dev的配置中啟用Flyway即可。通常推薦使用此模式，畢竟可以對不同的環境進行控制，另外本地Run不會依賴真實數據庫，又能保證數據庫Schema是按腳本創建的。 -
在運行Tests會使用內存數據庫，有單獨的配置文件，不使用Flyway，而在本地bootRun時會使用真實數據庫，使用Flyway，畢竟不想每次Schema改后都在本地手動去執行腳本，如何實現？
解決方案：設置bootRun.dependsOn動態添加Flyway的依賴即可：1
2
3
4
5
6
7
8
9addFlywayDenpendency {
doLast {
dependencies {
compile('org.flywaydb:flyway-core:4.0.3')
}
}
}
bootRun.dependsOn=addFlywayDenpendency -
若項目有多個團隊同時開發不同的功能，需要新建多個分支，並且都會涉及到數據庫Schema更改，當后期Merge時，Migration的版本如何控制並且不會產生數據庫更改的沖突呢？
解決方案：如果兩個分支的數據庫更改有沖突，要么最初數據庫設計不合理，要么目前數據庫更改不合理，所以需要團隊進行全局考慮和協調。而針對數據庫在同一段時間有修改，但不會造成沖突的情況，通常實際項目中主要存在這樣的情況，那可以設置flyway.out-of-order=true，這樣允許當v1和v3已經被應用后，v2出現時同樣也可以被應用。其實在本地使用內存數據庫不會存在該問題，因為數據庫所有對象會自動清除掉，而在local或dev中使用真實數據庫時可遇到這樣的問題，因此需要注意一下了。
另外，值得一提的是Flyway的參數ignore-failed-future-migration默認為true，使用情形為：當Rollback數據庫更改到舊版本，而metadata表中已存在了新版本時，Flyway會忽略此錯誤，只會顯示警告信息。
結束語
總得來說，Flyway可以有效改善數據庫版本管理方式，如果項目中還未使用，不防嘗試一下。如果有興趣，也可以關注MyBatis Migration，功能支持沒有Flyway多，屬於更輕量級的數據庫版本管理工具。如果在使用過程中遇到了問題或坑，歡迎留言一起交流討論。
References
http://blog.waterstrong.me/flyway-in-practice/