フライウェイとリキベースは一緒ですか？
LiquibaseとFlywayの両方を個別に見てきましたが、個別の比較だけでは、Liquibaseは私たちのニーズに適したツールのようです。一部の情報源では、LiquibaseとFlywayの両方を一緒に使用することに言及しています。 Liquibaseには、Flywayに備わっているすべての機能と、ロールバックに関する柔軟性が備わっているようです。 Flywayの主な利点はXMLを使用する必要がないようですが、LiquibaseではXMLでSQLファイルを指定できます。
基本的に、FlywayとLiquibaseを一緒に使用することの利点が、Liquibaseがある場合、それがLiquibaseに比べてどのような利点があるかについては、まだ明確ではありません。 Liquibaseが有効なFlyway SQLファイルを参照している場合でも、両方のツールを個別に実行する必要があり、技術的にどちらのツールを使用しても、同じ落とし穴があるため、それを行う方法があるかもしれません。
質問に答える前の小さな修正。仮定
LiquibaseにはFlywayのすべてが搭載されているようです
正しくありません。 Flywayは、SQLの解析に関しては優れています。 PL/SQLパッケージおよびプロシージャ、MySQLデリミタの変更、T-SQL、PostgreSQLプロシージャなど、あらゆる種類の複雑さを含むネイティブツールで生成された未変更のSQLファイルを使用できます。 SQLファイルに追加のコメントを追加する、...
SQLファイルをそのまま使用できることの利点は、ロックインを回避できることです。既存のSQLファイルを使用して、最小限の投資でFlywayの使用を開始し、ニーズに合わなくなった場合は後で移動できます。 Liquibaseではそうではありません。
また、ダウンマイグレーションの問題（ロールバックではなく、トランザクションを補正することと考えてください）は、理論上は素晴らしいと思われますが、実際にはほとんど必要ありません。 https://flywaydb.org/documentation/faq#downgrade を参照してください
しかし、どちらかまたは両方を使用することになったとき、私は間違いなくSteveDonie（Liquibaseチームメンバー）に同意します。
免責事項：私はフライウェイの作成者です
両方のツールを同時に使用することはお勧めしません。私の経験では、大規模な分散環境（同じDBにアクセスできる5チーム以上）で、そのうちの1つだけが時々競合/衝突を引き起こします。
また、大規模な分散チームを含むプロジェクトでこれらのツールを実行する場合の長所と短所もいくつか示します。
FlyWay：
短所：移行ファイルの変更に関しては非常に厳しい。誰かが移行ファイルをチェックインした場合、変更することは推奨されません。これは、共有プロジェクトでgitで強制プッシュを使用するようなものです。移行（内容またはファイル名）を変更すると、ファイルの以前のバージョンがあったすべてのマシンで移行エラーが発生します。移行パック全体を最初から実行する必要があります。場合によっては、時間がかかることがあります。
長所：さて、Consで説明されていたことは、同時に規律のレベルを構築します。複数のチームによる同時実行をプロダクション実行アプリケーションに導入することについて話すとき、それは合理的な制限かもしれません。
Liquibase：
短所：いくつかの 微調整 を使用すると、既存の（適用された）移行を変更できるはずです。多くの人が同じコードベースで作業しているため、これは利点と見なすことができますが、特に注意が必要です。柔軟性には代償が伴います。このような「git force push」スタイルの変更が分散プロジェクトに許可されている場合、「回帰」または矛盾を導入するのは簡単です。
長所：より柔軟に設定可能。将来的にNoSqlのソリューションが含まれる可能性があります。いくつかの便利なプラグイン（たとえば、hibernate統合）。