Flyway官網(wǎng)上提供了一個很清晰的示例How Flyway works，可以參閱一下。

Migrate

Migrate是指把數(shù)據(jù)庫Schema遷移到最新版本，是Flyway工作流的核心功能，F(xiàn)lyway在Migrate時會檢查Metadata(元數(shù)據(jù))表，如果不存在會創(chuàng)建Metadata表，Metadata表主要用于記錄版本變更歷史以及Checksum之類的。

Migrate時會掃描指定文件系統(tǒng)或Classpath下的Migrations(可以理解為數(shù)據(jù)庫的版本腳本)，并且會逐一比對Metadata表中的已存在的版本記錄，如果有未應(yīng)用的Migrations，F(xiàn)lyway會獲取這些Migrations并按次序Apply到數(shù)據(jù)庫中，否則不需要做任何事情。另外，通常在應(yīng)用程序啟動時應(yīng)默認(rèn)執(zhí)行Migrate操作，從而避免程序和數(shù)據(jù)庫的不一致性。

Clean

Clean相對比較容易理解，即清除掉對應(yīng)數(shù)據(jù)庫Schema中的所有對象，包括表結(jié)構(gòu)，視圖，存儲過程，函數(shù)以及所有的數(shù)據(jù)等都會被清除。

Clean操作在開發(fā)和測試階段是非常有用的，它能夠幫助快速有效地更新和重新生成數(shù)據(jù)庫表結(jié)構(gòu)，但特別注意的是：不應(yīng)在Production的數(shù)據(jù)庫上使用！

Info

Info用于打印所有Migrations的詳細(xì)和狀態(tài)信息，其實(shí)也是通過Metadata表和Migrations完成的，下圖很好地示意了Info打印出來的信息。

Info能夠幫助快速定位當(dāng)前的數(shù)據(jù)庫版本，以及查看執(zhí)行成功和失敗的Migrations。

Validate

Validate是指驗(yàn)證已經(jīng)Apply的Migrations是否有變更，F(xiàn)lyway是默認(rèn)是開啟驗(yàn)證的。

Validate原理是對比Metadata表與本地Migrations的Checksum值，如果值相同則驗(yàn)證通過，否則驗(yàn)證失敗，從而可以防止對已經(jīng)Apply到數(shù)據(jù)庫的本地Migrations的無意修改。

Baseline

Baseline針對已經(jīng)存在Schema結(jié)構(gòu)的數(shù)據(jù)庫的一種解決方案，即實(shí)現(xiàn)在非空數(shù)據(jù)庫中新建Metadata表，并把Migrations應(yīng)用到該數(shù)據(jù)庫。

Baseline可以應(yīng)用到特定的版本，這樣在已有表結(jié)構(gòu)的數(shù)據(jù)庫中也可以實(shí)現(xiàn)添加Metadata表，從而利用Flyway進(jìn)行新Migrations的管理了。

Repair

Repair操作能夠修復(fù)Metadata表，該操作在Metadata表出現(xiàn)錯誤時是非常有用的。

Repair會修復(fù)Metadata表的錯誤，通常有兩種用途：

• 移除失敗的Migration記錄，該問題只是針對不支持DDL事務(wù)的數(shù)據(jù)庫。
• 重新調(diào)整已經(jīng)應(yīng)用的Migratons的Checksums值，比如：某個Migratinon已經(jīng)被應(yīng)用，但本地進(jìn)行了修改，又期望重新應(yīng)用并調(diào)整Checksum值，不過盡量不要這樣操作，否則可能造成其它環(huán)境失敗。

如何使用Flyway?

這里將主要關(guān)注在Gradle和Spring Boot中集成并使用Flyway，數(shù)據(jù)庫通常會采用MySQL、PostgreSQL、H2或Hsql等。

正確創(chuàng)建Migrations

Migrations是指Flyway在更新數(shù)據(jù)庫時是使用的版本腳本，比如：一個基于Sql的Migration命名為V1__init_tables.sql，內(nèi)容即是創(chuàng)建所有表的sql語句，另外，F(xiàn)lyway也支持基于Java的Migration。Flyway加載Migrations的默認(rèn)Locations為classpath:db/migration，也可以指定filesystem:/project/folder，其加載是在Runtime自動遞歸地執(zhí)行的。

除了需要指定Location外，F(xiàn)lyway對Migrations的掃描還必須遵從一定的命名模式，Migration主要分為兩類：Versioned和Repeatable。

Versioned migrations

一般常用的是Versioned類型，用于版本升級，每一個版本都有一個唯一的標(biāo)識并且只能被應(yīng)用一次，并且不能再修改已經(jīng)加載過的Migrations，因?yàn)镸etadata表會記錄其Checksum值。其中的version標(biāo)識版本號，由一個或多個數(shù)字構(gòu)成，數(shù)字之間的分隔符可以采用點(diǎn)或下劃線，在運(yùn)行時下劃線其實(shí)也是被替換成點(diǎn)了，每一部分的前導(dǎo)零會被自動忽略。

Repeatable migrations

Repeatable是指可重復(fù)加載的Migrations，其每一次的更新會影響Checksum值，然后都會被重新加載，并不用于版本升級。對于管理不穩(wěn)定的數(shù)據(jù)庫對象的更新時非常有用。Repeatable的Migrations總是在Versioned之后按順序執(zhí)行，但開發(fā)者必須自己維護(hù)腳本并且確?？梢灾貜?fù)執(zhí)行，通常會在sql語句中使用CREATE OR REPLACE來保證可重復(fù)執(zhí)行。

默認(rèn)情況下基于Sql的Migration文件的命令規(guī)則如下圖所示：

其中的文件名由以下部分組成，除了使用默認(rèn)配置外，某些部分還可自定義規(guī)則。

• prefix: 可配置，前綴標(biāo)識，默認(rèn)值V表示Versioned，R表示Repeatable
• version: 標(biāo)識版本號，由一個或多個數(shù)字構(gòu)成，數(shù)字之間的分隔符可用點(diǎn).或下劃線_
• separator: 可配置，用于分隔版本標(biāo)識與描述信息，默認(rèn)為兩個下劃線__
• description: 描述信息，文字之間可以用下劃線或空格分隔
• suffix: 可配置，后續(xù)標(biāo)識，默認(rèn)為.sql
  

另外，關(guān)于如何使用基于Java的Migrations，有興趣可以參考Java-based migrations。

支持的數(shù)據(jù)庫
目前Flyway支持的數(shù)據(jù)庫還是挺多的，包括：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。
目前來說，個人用得比較多的數(shù)據(jù)庫是PostgreSQL、MySQL、H2和Hsql，針對每種數(shù)據(jù)庫的flyway.url示例配置為：

另外，關(guān)于如何使用基于Java的Migrations，有興趣可以參考Java-based migrations。

支持的數(shù)據(jù)庫

目前Flyway支持的數(shù)據(jù)庫還是挺多的，包括：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。
目前來說，個人用得比較多的數(shù)據(jù)庫是PostgreSQL、MySQL、H2和Hsql，針對每種數(shù)據(jù)庫的flyway.url示例配置為：

# PostgreSQL
flyway.url = jdbc:postgresql://localhost:5432/postgres?currentSchema=myschema
# MySQL
flyway.url = jdbc:mysql://localhost:3306/testdb?serverTimezone=UTCuseSSL=true
# H2
flyway.url = jdbc:h2:./.tmp/testdb
# Hsql
flyway.url = jdbc:hsqldb:hsql//localhost:1476/testdb

Flyway命令行

Flyway的命令行工具支持直接在命令行中運(yùn)行Migrate,Clean,Info,Validate,Baseline和Repair6種命令，不需要借助其他Build工具，不需要應(yīng)用程序運(yùn)行在JVM中，只需要單純的命令行即可，但需要根據(jù)不同的操作系統(tǒng)下載并安裝該命令行工具。Flyway會依次搜索以下配置文件，越靠后的配置會覆蓋靠前的配置：

• /conf/flyway.conf
• /flyway.conf
• /flyway.conf

一個典型Flyway項(xiàng)目示例目錄結(jié)構(gòu)如下：

更多關(guān)于Flyway命令行使用可以參考Flyway Command-line。

在Gradle中的應(yīng)用

首先需要在Gradle中引入Flyway插件，通常有兩種方式：

方式一：采用buildscript依賴方式。

buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath("org.flywaydb:flyway-gradle-plugin:4.0.3")
}
}
apply plugin: 'org.flywaydb.flyway'

方式二（推薦）：采用DSL方式引用Plugins。

plugins {
id "org.flywaydb.flyway" version "4.0.3"
}

而在Gradle中配置Flyway Properties有兩種方式：

方式一：在build.gradle中配置Flyway Properties。

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中配置Flyway Properties。

flyway.url = jdbc:h2:./.tmp/testdb
flyway.user = sa
flyway.password =

如果期望在運(yùn)行Gradle Clean/Build Tasks時自動執(zhí)行Flyway的某些任務(wù)，可以設(shè)置dependsOn，若不期望隱式執(zhí)行Flyway任務(wù)，可以不配置。

clean.dependsOn flywayRepair # To repair the Flyway metadata table
build.dependsOn flywayMigrate # To migrate the schema to the latest version

另外，其它Tasks：flywayInfo,flywayValidate,flywayBaseline分別對應(yīng)到Flyway的命令。在使用Spring Boot時，運(yùn)行./gradlew bootRun會自動檢查并加載最新的db.migration腳本。

特別注意：在Production環(huán)境中不應(yīng)執(zhí)行./gradlew flywayClean，除非你知道自己的行為和目的，因?yàn)樵撁顣宄械臄?shù)據(jù)庫對象，相當(dāng)危險。

更多關(guān)于Flyway在Gradle中的使用請參閱Flyway Gradle Plugin。

與Spring Boot集成

在Spring Boot中，如果加入Flyway的依賴，則會自動引用Flyway并使用默認(rèn)值，但可以修改并配置FlywayProperties。

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都會使用內(nèi)存數(shù)據(jù)庫，其中的spring.jpa.hibernate.ddl-auto都設(shè)置為validate，Schema不需要Hibernate自動生成，并期望使用Flyway，而在線上環(huán)境會使用真實(shí)數(shù)據(jù)庫，并不期望使用Flyway，如何實(shí)現(xiàn)呢？
• 解決方案：可以在common.properties中配置flyway.enabled=false，然后在local或dev的配置中啟用Flyway即可。通常推薦使用此模式，畢竟可以對不同的環(huán)境進(jìn)行控制，另外本地Run不會依賴真實(shí)數(shù)據(jù)庫，又能保證數(shù)據(jù)庫Schema是按腳本創(chuàng)建的。
• 在運(yùn)行Tests會使用內(nèi)存數(shù)據(jù)庫，有單獨(dú)的配置文件，不使用Flyway，而在本地bootRun時會使用真實(shí)數(shù)據(jù)庫，使用Flyway，畢竟不想每次Schema改后都在本地手動去執(zhí)行腳本，如何實(shí)現(xiàn)？

解決方案：設(shè)置bootRun.dependsOn動態(tài)添加Flyway的依賴即可：

addFlywayDenpendency {
doLast {
dependencies {
compile('org.flywaydb:flyway-core:4.0.3')
}
}
}
bootRun.dependsOn=addFlywayDenpendency

若項(xiàng)目有多個團(tuán)隊(duì)同時開發(fā)不同的功能，需要新建多個分支，并且都會涉及到數(shù)據(jù)庫Schema更改，當(dāng)后期Merge時，Migration的版本如何控制并且不會產(chǎn)生數(shù)據(jù)庫更改的沖突呢？
解決方案：如果兩個分支的數(shù)據(jù)庫更改有沖突，要么最初數(shù)據(jù)庫設(shè)計(jì)不合理，要么目前數(shù)據(jù)庫更改不合理，所以需要團(tuán)隊(duì)進(jìn)行全局考慮和協(xié)調(diào)。而針對數(shù)據(jù)庫在同一段時間有修改，但不會造成沖突的情況，通常實(shí)際項(xiàng)目中主要存在這樣的情況，那可以設(shè)置flyway.out-of-order=true，這樣允許當(dāng)v1和v3已經(jīng)被應(yīng)用后，v2出現(xiàn)時同樣也可以被應(yīng)用。其實(shí)在本地使用內(nèi)存數(shù)據(jù)庫不會存在該問題，因?yàn)閿?shù)據(jù)庫所有對象會自動清除掉，而在local或dev中使用真實(shí)數(shù)據(jù)庫時可遇到這樣的問題，因此需要注意一下了。
另外，值得一提的是Flyway的參數(shù)ignore-failed-future-migration默認(rèn)為true，使用情形為：當(dāng)Rollback數(shù)據(jù)庫更改到舊版本，而metadata表中已存在了新版本時，F(xiàn)lyway會忽略此錯誤，只會顯示警告信息。

結(jié)束語

總得來說，F(xiàn)lyway可以有效改善數(shù)據(jù)庫版本管理方式，如果項(xiàng)目中還未使用，不防嘗試一下。如果有興趣，也可以關(guān)注MyBatis Migration，功能支持沒有Flyway多，屬于更輕量級的數(shù)據(jù)庫版本管理工具。如果在使用過程中遇到了問題或坑，歡迎留言一起交流討論。

References

Flyway Documentation

Gradle Plugin: Flyway

Spring Common application properties

Execute Flyway database migrations on startup

到此這篇關(guān)于快速掌握和使用Flyway的詳細(xì)教程的文章就介紹到這了,更多相關(guān)使用Flyway的技巧內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！