この記事の輪郭
- フライウェイとは何ですか
- 私たちは、問題を解決することができますどのような
- springboot環境下フライウェイを使用します
- フライウェイの作品
まず、フライウェイは何ですか
フライウェイは、単純な、焦点を当て、強力な、データベース管理ツールのオープンソース版で、「構成された合意よりも大きい」促しました。SQLは、データ同期のために使用される、または特定のデータベースの構文に基づくことができる（例えば、PL / SQL、T-SQLなど）又は（高度なデータ変換または処理LOB用）Javaコードは、書き込みモード。そして、データベースは非常に広いをサポートしています。
第二に、私たちはすべての問題を解決するために
まあ、我々は最初のデータベース管理のバージョンは何を説明しますか？
- 我々は、すべてのgitのは、ソフトウェアプロジェクトのコードのバージョン管理を支援するために共同開発プログラマーを容易にすることであることを知っています
- フライウェイは、データベースのバージョン管理ツールであるので、目標は、マルチステート環境データベースの一貫性のプログラマは、共同開発することを確認することです
ここでは簡単な例です：
- 開発者は多くの場合、同じデータベースまたは自作のライブラリの開発を使用して、データベースの開発ライブラリはしばしば呼ばれます。
- テストデータ、通常、自作のテストライブラリの妥当性を保護するためにテスターは、このデータベースには、テスト・ライブラリーと呼ばれています。
- データのプレゼンテーションの効果を確実にするために、営業スタッフは、通常、プレゼンテーションライブラリーと呼ばれる独立したデータベースを、必要としています。
- ライン上の公式生産ライブラリは、ユーザーを供給、このデータベースは、生産ライブラリーと呼ばれています。
そこで問題は、次のようになります。私たちは、データベーススキーマの一貫性のある状態を確保するにはどうすればよいですか？一部の開発者は、効果的を通じて生産試験の後、ライブラリとライブラリを同期する方法を示すために、彼らは効果的にテストライブラリに同期させることができますどのように、新しいフィールドをライブラリの開発を変更していますか？不在フライウェイでは、このアクションは、通常、自身が完了するまでにSQLを実行するためにオンラインのプログラマーをしている、または会社のより正式なバージョンが動作する管理要員を特化しています。これは、多くの場合、あるいくつかの問題があります。
- 通信、社内の開発チーム、データベースフィールドのような修正のメンバーのコストの増加、他の人は知らないかもしれません。
- 開発チームとテストチームと他のチームの間の通信コストの上昇
- 継続的インテグレーションの自動化を完了できません、継続的インテグレーションプロセスコードはgitの、Mavenの、ドッキングウィンドウ、K8Sや他のツールで展開されたコードのパッケージを、自動化することができます。しかし、データベースの状態の変化は、効果的に自動化された継続的インテグレーションプロセスを実現することができない、自動的に変更されていません。
これが私たちの研究フライウェイの目的である：フライウェイが自動的に追加されているかどうか、効果的に各パブリケーションデータベースの同期間の状態にお役立てたり、フィールド、または新しいテーブルの追加を削除することができ、彼は、自動化することができますプロジェクトのリリース後も解除。
第三に、springboot環境下フライウェイを使用して
まず、プロジェクトがSpringBootある頼るフライウェイを追加します
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>6.0.7</version>
</dependency>その後、我々はspring.datasourceデータベースのデータソース構成があることを確認します。そして、application.propertiesに以下の設定を追加
spring:
flyway:
enabled: true #启用flyway
encoding: utf-8 #字符编码
locations: ["classpath:db/migration"] #版本控制文件存放目录その後、リソース/ DB / migrationディレクトリにスクリプトを次の形式を追加します。
V1.1__create_table.sql
V1.2__update_person_table.sql
V1.3__create_new_table.sql
V1.4__add_person_comment.sql
V2.1__modify_person_data.sql後スクリプトの内容が記載されている2つの下線の後、データベース・スクリプトの資本Vバージョン番号（インクリメンタル形は、繰り返すことができない）が続きます。例えば：V1.1__create_table.sqlスクリプトはデータベースのテーブル構造を作成するために使用され、コンテンツはDDLテーブル等を作成します。2番目のスクリプトは、更新されているデータベーステーブル内の人物です。あなたが行わspring.datasourceに代わって動作するデータベースの内容を内部短いスクリプトでは、テーブルは、作成、削除、変更、またはデータの削除を作成するように修正することができることができます。
もちろん、私は個人的には、挿入、更新を書き、このスクリプトを削除しない、つまり、書かれているDML-SQLスクリプトをお勧めしません。ように生産データを誤用する場合、リード線に注意を払うことはありません。あなたの会社は、生産ラインの管理に厳格な審査手続きを持っていない場合は、本番環境では、彼らは単にフライウェイを使用しない、開発を促進する一方で、生産の安全性がより重要です！
最後に、SpringBootプロジェクトを開始し、SQLスクリプトが実行されるターゲット・データベースの範囲内で行われていません。そして、スクリプト実行情報は、内部のデータベーステーブルのデータschema_version_historyに保存されています。
四、フライウェイの作品
- まず、このプロジェクトは、スキャンファイル次のdb /移行へのフライウェイを起動し、ファイル名、バージョン番号を取得して解析します
次に、あなたのファイルは、データベースレコードのバージョンのバージョン番号よりも大きい場合、バージョンの実行情報を対応するschema_version_historyテーブルを見つけるために、中に入ると、スクリプトが実行されます。それ以外の場合は無視されます。
あなたの注意を楽しみにして
- ブロガーは最近、本を書いた：「手のタッチ手をSpringBootシリーズ章97節を学ぶためにあなたを教えるために-16」
：この記事は、ソース（エンはテキストのみをオンにしてはいけません）を示して再現された文字ジボオフ。