Flyway：データベース移行管理

この記事では、バージョン管理されたスキーマとデータベース移行管理を確実にする手段の1つ、 Flywayライブラリについて説明します。 遅かれ早かれ、DBMSに基づくアプリケーションの開発者は、データベーススキーマの問題のあるバージョン管理に対処する必要があります。 残念ながら、この問題は考慮に入れるのが遅すぎる場合があります。たとえば、アプリケーションがすでに動作しているときにデータベース構造を変更するという問題が発生した場合などです。 しかし、開発段階であっても、データベーススキーマの制御は、アプリケーションのバージョン管理の他のすべての側面と同様に問題を引き起こしません。明確な移行管理システムがない場合、ローカル、スタンド、および運用ベースは、現在の状態に関する情報を提供することなく、迅速に「分散」できます。





パフォーマンスプロバイダーは、現在のオブジェクトモデルをデータベーススキーマとしてエクスポートすることを1つの形式でのみ日常的に許可しています。 このプロセスは、再作成（構造全体を完全に削除）、更新（変更を伴う）または調整（変更を行わない）のモードで実行できます。 たとえば、Hibernateでは、hbm2ddlツールを使用してこれを実行します。hbm2ddlツールの操作は、hibernate.cfg.xmlまたはpersistence.xmlファイルの単一の構成パラメーターで構成できます。 ただし、データベースに既にデータがある場合、再作成（作成モード）は望ましくなく、更新（更新モード）はすべての変更を行わず、非破壊的な変更（たとえば、列とテーブルは削除されません）のみを行い、必要なデータの再構築を考慮しません。 多くの場合、データモデルに多くの変更が加えられている場合、特にデータベースの現在のバージョンが不明である場合、それらを運用ベースに適用するのは困難です。 いずれにせよ、しかしあなたはSQLスクリプトに「st索」しなければなりません-これがバージョン管理の問題が出てくるところです。

フライウェイ

プロジェクトのメインページには、ライブラリと同様のソリューションを比較した明確な表があります。ここでは、単純なSQLファイルまたはJavaクラス（後者は基本的にSpring JDBCテンプレートに基づいています）とネイティブSQLサポートの形式での移行で、豊富な機能に焦点を当てたいと思います一般的なDBMS（Oracle PL / SQL、SQL Server T / SQL、MySQL、PostgreSQLストアドプロシージャ）。



Flywayは、Ant、Maven、およびコマンドラインツールとうまく統合し、プログラムでSpringを呼び出して統合するためのAPIを備えており、多くのDBMSで動作します。 Flywayを既存のプロジェクトに接続する例を示します。このプロジェクトのアセンブリはMavenに基づいており、FlywayはSpringコンテキストの開始時に呼び出されます。 MySQLはプロジェクトのデータベースとして使用されます。

Flywayをプロジェクトに接続します

最初に、プロジェクトのsrc / main / resourcesサブディレクトリにdb / migrationフォルダーを作成します。移行スクリプトはそこに保存されます。 すべてのテーブル、ビュー、インデックスなどを含む、事前にエクスポートされたデータベーススクリプトを配置しましょう。 ファイルにV1__Base_version.sqlという名前を付けます。 移行の命名規則については、ドキュメントで詳しく説明しています 。現時点では、ファイル名はVで始まり、その後にバージョン番号（任意の数の区切りポイント）、二重アンダースコア、移行の説明が続くと言うだけで十分です。



プロジェクトの依存関係（依存関係セクション）にFlywayライブラリのコアを追加します。

<dependency> <groupId>com.googlecode.flyway</groupId> <artifactId>flyway-core</artifactId> <version>1.5</version> </dependency>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アセンブリプラグイン（セクションビルド/プラグイン）-Flywayプラグイン：

 <plugin> <groupId>com.googlecode.flyway</groupId> <artifactId>flyway-maven-plugin</artifactId> <version>1.5</version> <configuration> <driver>com.mysql.jdbc.Driver</driver> <url>jdbc:mysql://localhost:3306/flywaytest?autoReconnect=true&amp;useUnicode=true&amp;characterEncoding=UTF-8&amp;connectionCollation=utf8_general_ci&amp;characterSetResults=UTF-8</url> <baseDir>db/migration</baseDir> </configuration> </plugin>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プラグインからFlywayを起動するには、データベースに別のアカウントを作成することをお勧めします。 プラグインの設定で、データベースに接続するためのユーザーとパスワードをここで指定できます。

 <configuration> <user>flyway</user> <password>mySecretPassword</password> ... </configuration>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、コマンドラインオプションで：

 -Dflyway.user=flyway -Dflyway.password=mySecretPwd
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、Mavenでアセンブリする場合のより便利な方法は、Maven設定ファイル（settings.xmlファイル）に標準パラメーターを配置し、同様のすべてのプロジェクトでそれらをさらに使用することです。

 <servers> <server> <id>flyway-db</id> <username>flyway</username> <password>mySecretPassword</password> </server> </servers>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在のデータベースを最初から初期化する必要がある場合は、クリーニングを実行できます。 この場合、データベースのコンテンツ全体が削除されます。

 mvn flyway:clean
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タスクが正常に完了すると、データベースは空になり、Mavenログに次の行が表示されます。

 [INFO] --- flyway-maven-plugin:1.5:clean (default-cli) @ flyway-test-project --- [INFO] Cleaned database schema 'flywaytest' (execution time 00:03.911s)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データベースが最新の場合（以前にアンロードされたスクリプトに対応）、タスクを完了する必要があります。これにより、バージョン管理を維持するために必要な構造が作成されます。

 mvn flyway:init -Dflyway.initialVersion=1 -Dflyway.initialDescription="Base version"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、データベースの現在の状態に対応する単一のレコードでschema_versionテーブルがデータベースに表示されることを確認できます。







entityManagerFactoryの前に起動するSpring Beanの形式で、Flywayをアプリケーションと統合します。

 <bean id="flyway" class="com.googlecode.flyway.core.Flyway" init-method="migrate"> <property name="dataSource" ref="..."/> ... </bean> <!--        Flyway,  ,          --> <bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" id="entityManagerFactory" depends-on="flyway"> ... </bean>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クリーンベースでアプリケーションを起動すると、V1__Base_version.sqlスクリプトで初期化され、さらにschema_versionテーブルが作成されます。 ログでは、次のことを確認できます。

 2012-04-04 06:42:09,279 INFO [com.googlecode.flyway.core.metadatatable.MetaDataTable] -- <Metadata table created: schema_version (Schema: flywaytest)> 2012-04-04 06:42:09,318 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Current schema version: null> 2012-04-04 06:42:09,320 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Migrating to version 1> 2012-04-04 06:42:24,897 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Successfully applied 1 migration (execution time 00:15.615s).>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションが最後の移行と同じ基準で起動された場合、スキームに変更は発生せず、次の行のアプリケーションログに反映されます。

 2012-04-04 06:36:14,081 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Current schema version: 1> 2012-04-04 06:36:14,085 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Schema is up to date. No migration necessary.>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いずれの場合でも、Flywayが正しく統合されている場合、データベースには上記のschema_versionテーブルに単一のエントリが含まれている必要があります。

移行を作成する

db / migrationフォルダーに、V2__Test_change.sqlという名前で、次の内容のファイルを作成します。

 create table test_table ( id bigint(20) not null, primary key(id) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションを起動すると、ログに次の行が見つかります。

 2012-04-04 06:51:02,708 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Current schema version: 1> 2012-04-04 06:51:02,710 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Migrating to version 2> 2012-04-04 06:51:03,137 INFO [com.googlecode.flyway.core.migration.DbMigrator] -- <Successfully applied 1 migration (execution time 00:00.480s).>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、test_tableが正常に作成され、適用された移行に関するエントリがschema_versionテーブルに表示されたことを確認します。

ロールバック移行

Flywayは、たとえばRailsの移行システムとは異なり、変更のロールバックをサポートしていません。 ライブラリの作成者は、破壊的かつ不可逆的な変更を行った後、データベースの状態をロールバックして、失われたデータまたは変更されたデータをすべて以前の状態に復元することができ、一般的な場合は不可能であるという事実によってこれを動機付けています。 代わりに、冗長メカニズムを使用する合理的なアプローチが提案されています。 たとえば、次の移行を適用する前に、データベースのダンプダンプまたはスナップショットを実行できます（特定のDBMSで利用可能なバックアップ機能に応じて）。