Flywayは、データベースの更新 (移行とも呼ばれます) を自動化するための非常に優れたツールです。ただし、バージョン 1.7 以降では、完全に直線的な移行シーケンスに依存しています。この仮定は、すでに新しいものを開発している間に修正を提供しなければならない実稼働システムがある場合、すぐに無効になります。FAQは、これが実稼働システム自体の問題ではないことを正しく主張していますが、既に開発ブランチにある開発および/または QA システムがある場合は、実稼働バージョンの修正から帯域外で移行を実行する必要があります。 .
これを可能にする解決策はIssue 138で保留中ですが、まだ完了していません。これはかなり致命的な問題なので、今すぐ使用したい場合、巧妙な回避策はありますか?
私が推奨する (継続的デリバリー/デプロイメントではほぼ必須となる) アプローチは、Feature または Release ブランチを使用する代わりに、Feature Toggles を使用して HEAD からリリースすることです。次に、これを下位互換性のある移行と組み合わせて、この問題を完全に軽減します。
何らかの理由でそれができない場合でも、それほど長く待つ必要はありません。Flyway 1.8 (138 の修正を含む) が間もなくリリースされます。
Flywayバージョン 2.0 以降、この問題は廃止されました。outOfOrderフラグを設定すると、flyway はまだ適用されていない以前のバージョン番号で移行も実行します。ただし、このようなアウト オブ バンド マイグレーションを後のマイグレーションに任意の順序で適用できることを確認する必要があります。そうしないと、重大な問題が発生します。
Flyway-1.7 を使用すると、次の回避策を作成できます。開発ブランチと運用ブランチがある場合、運用ブランチと開発ブランチ用に個別のメタデータ テーブル (SCHEMA_HISTORY と SCHEMA_HISTORY_DEV など) を含む Flyway の個別のインスタンスを持つことができます。運用サーバーには SCHEMA_HISTORY しかなく、通常どおり作業します。開発サーバーには両方があり、フライウェイを実行するたびに、最初にSCHEMA_HISTORYを使用して本番ブランチSQLで実行し、次にSCHEMA_HISTORY_DEVを使用して開発ブランチSQLで実行します。
ブランチを切り替えるときは、SCHEMA_HISTORY_DEV を SCHEMA_HISTORY にマージする必要があります。(最初のリビジョンを除外し、SCHEMA_HISTORY の CURRENT_VERSION をリセットする必要があります。) そして flyway-1.8 が出てきたら、このマージを行い、SCHEMA_HISTORY_DEV を捨てます。