4

私のアプリケーションには次のシナリオがあります。

  • 1本番サーバー
  • 1テストサーバー
  • n開発用コンピューター

データベースの移行では、スキーマにHibernate Schema Updateを使用し、すべての本番データ（すべてのサーバー/コンピューター）にDBUnitを入力します。スキーマの更新が完了すると、新しいスキーマの新しいDTDファイルが生成されるため、DBUnitXMLの新規インポートを実行できます。アプリケーションは、起動時にXMLファイルでデータベースを更新します（開発およびテストサーバー/コンピューターのみ！）

もちろん、このアプローチは最適で壊れやすいものではありません。そこで、LiquibaseとFlywayを見ました。どちらも優れたツールのようですが、私が得られないのは、データを移行するにはどうすればよいですか？私の場合、本番システムのデータを週に1回ダンプし、それをDBUnit XMLファイルとしてアプリケーションソース管理に追加します。これにより、すべての開発者が「新しい」データを持ち、テストサーバーも現在の本番データを持ちます。

LiquibaseとFlywayで私が目にする問題は、データベースデータから自動差分を実行し、移行の変更を自動的に生成する方法がないことです。

だから私の考えは次のステップで次のとおりです：

  1. 更新ではなく検証するようにHibernateを設定します。
  2. STRUCTURALデータベースの変更が必要な場合は、メジャーバージョンの移行スクリプトに追加します
  3. 移行スクリプトにはデータベースの挿入はありません。
  4. 新しいデータベース構造に基づいて、DBunitの新しいDTDを生成します
  5. 本番データベースからDBUnitXMLを生成します。

もう1つのアイデアは、flyways JavaMigrationを利用して、DBUnitに基づく初期データベースダンプを提供することです。データベースデータの他のすべての変更は、移行スクリプトで処理されます。しかし、それでも問題があります。現在の移行スクリプトの状態と本番データベースの状態との差分を作成するにはどうすればよいですか。

誰かが私のシナリオを処理する方法のヒントを私に提供できれば素晴らしいでしょう:)

4

2 に答える 2

1

簡単に言うと、すべての変更はLiquibaseまたはFlywayを介して行われます。

同じ製品/テスト/開発設定でFlywayを使用します。ソース管理に保存されているFlyway移行スクリプトを使用して、すべてのデータベースの変更（構造またはメタデータ）を行います。環境に新しいデプロイメントを行うたびに、最初にそこで移行スクリプトを実行します（コマンドラインツールまたはMavenプラグインのいずれかを使用）。コードは最初に開発環境に送られ、そこで統合テストが行​​われ、テストと本番環境に移行し続けます。

注意すべき主な点は、Flywayではファイルの線形バージョン管理が必要なため、2人の開発者が同時に移行をチェックインする場合、そのうちの1人が名前を変更する必要があることです。

于 2012-05-21T18:14:49.847 に答える
1

DEVおよびTEST環境でPRODデータベースのダンプを使用することが目標である場合、次のようにします。

  • アプリケーションの起動時に実行するようにDB移行ツールを構成します（FlywayとLiquibaseの両方がそれぞれのAPIを介してこれをサポートします）
  • すべてのDB構造の移行をアプリと一緒にパッケージ化します
  • PRODからデータと構造の両方をダンプします

このように、PRODデータベースがDEVまたはTESTに復元されると、移行ツールの古いメタデータテーブルも復元されます。

アプリが起動すると、移行ツールはdb構造が古くなっていることを検出し、最新バージョンにアップグレードします。終わり。

このためにDBUnitを使用する必要はありません。

于 2012-05-21T22:15:33.337 に答える