マイグレーションスクリプトを自分で作成しなければならないので、フライウェイはどのような価値を提供していますか？

Question

私の状況では、すべてのデータベースのinit/create文を含むSQL文を生成するツールを使用します。 Flywayは私のツールが提供する以上の価値を提供していますか？ Flywayを使用するために手作業でコード化された移行スクリプトを書くのはなぜですか？

Answer 1

上記の質問には、分離する必要がある2つの事項、つまり移行の概念と組み合わせたデータベース作成という概念が混在しています。

データベース作成

完全なデータベースと空のデータベースを考えると、あなたは何も存在しない、完全なデータベースを再作成するために必要なスクリプトを生成するために多くのツールを使用することができます。フライウェイ用語では、ベースラインを作成するだけです。これは、移行の概念ではありません。もちろん、V2.0データベースがあれば、V1.0データベースを見て、それを吹き飛ばし、V2.0データベースをインストールすることができましたが、今度はデータを失ってしまいました。

移行

完全なデータベースV2.0とV1.0古いデータベースを考えると、あなたはV1.0データベースがV2.0に「アップグレード」することにしたいです。データベースの世界では、移行と呼ばれています。既存の1.0データはV2.0で動作するように再配置する必要があるためです。テーブルを作成/変更するだけでなく、ETLを実行するスクリプト（データの抽出、新しいテーブル構造に読み込むことができるようにデータを変換したり、古いデータベースを新しいテーブル構造に変更したり、データをデータベースにロードします）。これは場合によっては自明ではないかもしれません。それを行うスクリプトを作成すると、Flywayはそのスクリプトの実行を管理します。

フライウェイ

フライウェイには、次のことが可能になります

• 移行スクリプトは、ソフトウェア資産の一部となります。それらはバージョニングされており、ベースライン/移行スクリプトをソース管理で維持して、「ワンオフ」スクリプト作業とは対照的に、移行が繰り返し可能な機能になるようにしています。
• フライウェイはそれが
• フライウェイが
• 手動実行エラーを除去し、完全に自動化された方法で移行を適用することができますフライウェイのように移行スクリプトの作成を可能に適用されているかどうかのスクリプトを知っているとそれが動作する各データベース内のメタテーブルを維持開発の一部（テスト駆動型開発のように、単体テストの作成は開発の不可欠な部分です）を使用して、すべてのデータベース開発をマイグレーションスクリプトの形でキャプチャします（「ワンオフ」マイグレーションの一部として必要に応じてマイグレーションスクリプトを構築する）。
• Flywayを使用してアプリケーションの以前のバージョンを1つのコマンドで数秒で更新するのは一般的です。 e古いDBから新しいバージョンへの移行のストレスがなくなり、DBの進化は容易かつ普通になります。

Flywayを使用するには、ワークフローを変更する必要があります。開発者DBに変更を加えるたびに、その変更を移行スクリプトに入れて、それらの変更を実行することができます。世界。これらのスクリプトは、アプリケーションのソースコードにチェックインされ、他の機能と同様に、ソフトウェア資産の第一人者です。

Answer 2

あなたはそれが非常に少ない値を追加するアプリケーションの寿命にわたって静的なままになるデータベース構造を持つ単純なアプリケーションを作成することを計画している場合には

、ご使用の場合に非常に依存します。

スキーマ上で変更が発生しても、プロジェクトは生涯にわたり動的なデザインになると予想される場合、Flywayは変更を表現したり表示したりできる正式な構造を提供します。この正式な構造は、FlywayがマルチスキーマCI作業のようなものを処理するフレームワークの一部となるため、プロジェクトに携わる大規模なチームになった場合に非常に役立ちます。

重要なことの1つは、Flywayで始める必要がないということです。後で追加することができます。通常、その時点でのスキーマが将来の変更が反映されるベースラインになるため、追加される。