例としてMavenを使用するデータベースにFlyWayを使用する

こんにちはKhabrovchanとKhabrovchanovka！

FlyWayと呼ばれる非常に便利で便利なツールについてお話します。 実際、記事はすでに私たちのお気に入りのリソースにありましたが、最近、かなり重要な変更がいくつか行われたため、新しい情報が損なわれることはないと思います。



FlyWayとは何ですか？

公式ページ「Flywayへようこそ、データベースの移行が簡単になった」によると 、これは間違いではありません。

サポートされているデータベースの数は非常に素晴らしいです。

• オラクル
• SQLサーバー
• SQL Azure
• DB2
• DB2 z / OS
• MySQL
• MariaDB
• PostgreSQL
• 赤方偏移
• バーティカ
• Enterprisedb
• H2
• Hsql
• ダービー
• Sqlite
• SAP HANA
• solidDB
• Sybase ASE
• フェニックス
• みどり

合計で（現在Mavenの使用を検討していますが、イデオロギーとロジックは他のビルドシステム-AntとGradleに似ています）6つのコマンドがあります：

• migrate-データベースを移行します
• clean-構成されたスキーマ内のすべてのオブジェクトを削除します
• info-すべての移行に関する詳細とステータス情報を出力します
• validate-クラスパスで利用可能な移行に対して適用された移行を検証します
• baseline-baselineVersionまでのすべての移行を除外した、既存のデータベースのベースライン
• repair-メタデータテーブルを修復します

これは公式マニュアルの実際の説明です。

Sqlスクリプトに加えて、Javaベースの移行もサポートしています。

コミュニケーションの個人的な経験と使用戦術について簡単に説明します。



FlyWayをpom.xmlのプロジェクトに接続するには、次のようなシートの新しい部分を追加する必要があります。

<plugin> <groupId>org.flywaydb</groupId> //   <artifactId>flyway-maven-plugin</artifactId> <version>4.2.0</version> <configuration> <user>UserDB</user> //  <password>DBpass</password> //   <url>127.0.0.1</url> //   <baseDir>/database/script/</baseDir> //    -  ,       ,     main/src/db/migrate ,      </configuration> </plugin>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プラグインにはこれら以外にも多くの設定があり、ドキュメントで利用できます。現時点ではこれらだけを使用しています。 実質的に何でもカスタマイズしたり、複数の回路を接続したりできます。



次に、スクリプトの正しい命名が重要です。 移行は順次行われるため、バージョン管理を維持する必要があります。 名前は、最初のスクリプトの場合はV1_1__some_text.sqlの形式で、2番目のスクリプトの場合は2番目のV1_2__else_text.sqlのようにする必要があります。 テキストの前にある二重下線に注意してください。これは名前の必須要件です！



実際に、プラグインを接続し、いくつかのスクリプトを作成し、準備ができました。

プロジェクトが開始され、一部のデータがアップロードされたと仮定します。すべてを整理し、自動的にさらにロールバックします。



スクリプトを上記の形式にし、パフォーマンスを確認し（そして、それがない場合）、 mvn flyway：cleanを実行し、クリーンなベースを取得します。 次に、 mvn flywayを使用します。migrateおよびvoila、 clean以前の形式で取得します。



その後、時間が経つにつれて、データを追加する必要が生じます。 たとえば、上記の例を取り上げると、2つのスクリプトがあり、 V1_3_something.sqlという名前の3番目のスクリプトを作成し、 mvn flyway ：migrateを再度実行します。 Flywayは新しいスクリプトが出現したと判断し、それをベースにロールします。



V1_1またはV1_2に変更が加えられた場合、一部のアクションが実行されず、V1_3が追加されて移行が開始されたが、何も機能しないことに注意することが非常に重要です。 以前のスクリプトの不変性を観察する必要があります。



もちろん、 修復またはベースラインは上記の状況に役立ちますが、常にではありませんが、データベースには特定の制限が課されます。たとえば、公式の修復ドキュメントの最初の行には、「失敗した移行エントリを削除する（DDLトランザクションをサポートしないデータベースのみ）」という条件があります。 これに注意を払うことが重要です。



個人的な経験から、OracleBDを使用している場合、ベースラインは最後のスクリプトのローレットのエラーに役立ちます。



現時点では、私のプロジェクトのスクリプトの数はV3_21に達し、最初の桁はプロジェクトに応じて変更され、2番目は新しい変更の数の2番目です。 Jenkinsを使用してJobを起動するなど、新しい環境を展開する必要がある場合は問題ありません。 当然、プロファイルはpom.xmlで使用されますが、プロファイルはごくわずかです-ローカルホスト、新しいホスト、古いホストの更新 十分に速くて便利です。



一般に、善良な人々が期待するように、 公式文書は非常に詳細で、何、どのように、そして良い例を説明する写真がありますが、記事に記載されている最初のステップを踏むには十分です。