轉自：https://blog.waterstrong.me/flyway-in-practice/
什麼是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
R
- 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 2 3 4 5 6 7 8 9 10 11 | # PostgreSQL flyway.url = jdbc:postgresql://localhost:5432/postgres?currentSchema=myschema # MySQL flyway.url = jdbc:mysql://localhost:3306/testdb?serverTimezone=UTC&useSSL=true # H2 flyway.url = jdbc:h2:./.tmp/testdb # Hsql flyway.url = jdbc:hsqldb:hsql//localhost:1476/testdb |
Flyway指令行
Flyway的指令行工具支援直接在指令行中運作
Migrate
,
Clean
,
Info
,
Validate
,
Baseline
和
Repair
6種指令，不需要借助其他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 9 buildscript { repositories { mavenCentral() } dependencies { classpath( "org.flywaydb:flyway-gradle-plugin:4.0.3") } } apply plugin: 'org.flywaydb.flyway' - 方式二（推薦）：采用DSL方式引用Plugins。
1 2 3 plugins { id "org.flywaydb.flyway" version "4.0.3" }
而在Gradle中配置Flyway Properties有兩種方式：
- 方式一：在
build.gradle
1 2 3 4 5 6 7 8 9 10 flyway { 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
1 2 3 flyway.url = jdbc:h2:./.tmp/testdb flyway.user = sa flyway.password =
如果期望在運作Gradle Clean/Build Tasks時自動執行Flyway的某些任務，可以設定
dependsOn
，若不期望隐式執行Flyway任務，可以不配置。
| 1 2 | clean.dependsOn flywayRepair # To repair the Flyway metadata table build.dependsOn flywayMigrate # To migrate the schema to the latest version |
另外，其它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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | flyway.baseline-description= # The description to tag an existing schema with when executing baseline. flyway.baseline-version=1 # Version to start migration. flyway.baseline- on-migrate=false # Whether to execute migration against a non-empty schema with no metadata table flyway.check-location=false # Check that migration scripts location exists. flyway.clean- on-validation-error=false # will clean all objects. Warning! Do NOT enable in production! flyway.enabled=true # Enable flyway. flyway.encoding=UTF-8 # The encoding of migrations. flyway.ignore-failed-future-migration=true # Ignore future migrations when reading the metadata table. flyway.init-sqls= # SQL statements to execute to initialize a connection immediately after obtaining it. flyway.locations=classpath:db/migration # locations of migrations scripts. flyway.out-of-order=false # Allows migrations to be run "out of order". flyway.placeholder-prefix= # The prefix of every placeholder. flyway.placeholder-replacement=true # Whether placeholders should be replaced. flyway.placeholder-suffix=} # The suffix of every placeholder. flyway.placeholders.*= # Placeholders to replace in Sql migrations. flyway.schemas= # Default schema of the connection and updating flyway.sql-migration-prefix=V # The file name prefix for Sql migrations flyway.sql-migration-separator=__ # The file name separator for Sql migrations flyway.sql-migration-suffix=.sql # The file name suffix for Sql migrations flyway.table=schema_version # The name of Flyway's metadata table. flyway.url= # JDBC url of the database to migrate. If not set, the primary configured data source is used. flyway.user= # Login user of the database to migrate. If not set, use spring.datasource.username value. flyway.password= # JDBC password if you want Flyway to create its own DataSource. flyway.validate- on-migrate=true # Validate sql migration CRC32 checksum in classpath. |
若使用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
-
在運作Tests會使用記憶體資料庫，有單獨的配置檔案，不使用Flyway，而在本地bootRun時會使用真實資料庫，使用Flyway，畢竟不想每次Schema改後都在本地手動去執行腳本，如何實作？
解決方案：設定
bootRun.dependsOn
1 2 3 4 5 6 7 8 9 addFlywayDenpendency { 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
結束語
總得來說，Flyway可以有效改善資料庫版本管理方式，如果項目中還未使用，不防嘗試一下。如果有興趣，也可以關注MyBatis Migration，功能支援沒有Flyway多，屬于更輕量級的資料庫版本管理工具。如果在使用過程中遇到了問題或坑，歡迎留言一起交流讨論。