6

現在、開発者は全員、本番データベースのスナップショットを備えたローカル開発環境を持っています。これにより、自分以外の誰にも影響を与えることなく、データをねじったり、解約したり、打ち負かしたりできます。

これらのスナップショットは大きくなり始めており、それらのデータインポートには1時間近くかかり始めています。

開発データを維持するためのより良い推奨事項はありますか？開発データは、潜在的な変更のために分解することができ、変更のアイデアが悪かった場合などは、元に戻す必要があります。

4

4 に答える 4

2

私は次のアプローチを使おうとしています。

開発者は、バージョン管理下にあるベースラインスクリプトを維持し、データベーススキーマを最初から設定します。本番データベースに存在するのと同じようにスキーマを作成します。

また、テストデータを設定するための「スクリプト」も保持しています。この「スクリプト」は、実際には本番クラスを使用し、その上に小さなDSLを使用することもあります。適度に高速にするために、スクリプトは最小限のテストデータのみを生成します。新しい機能ビルドのテスト日付を作成するために、doneの定義の一部にすることをお勧めします。

開発者は、データベース（またはデータベーススキーマ）でこれらのスクリプトを自由に実行できます。最初のスクリプトは、自動データベーステストを実行するための基礎としても使用されます。

開発者が行った作業の結果は、移行スクリプトです。つまり、本番データベースに適用して、データの更新など、新しい目的の状態にすることができるスクリプトです。

これらの移行は、本番データベースのスナップショットでテストできます。本番データベースのスナップショットは、負荷テストとパフォーマンステストの実行にも使用されます。

スナップショットの場合のみ、データベース固有のツールを使用します。他のほとんどすべてはメインプログラミング言語（私にとってはJava）で書かれているので、開発者はそれを快適に使用できます。

このアプローチに対する抵抗に遭遇することがよくあります（「スクリプトが多すぎる」、「データベースが多すぎる」、「データベースモデリングツールがバージョン管理をサポートしていないため、バージョン管理を使用したくない」）。しかし、手作業の負荷からのアパートは、私は実際に代替案を見ていません。

于 2012-08-14T18:54:03.160 に答える
1

通常、開発者は、開発データベースからいくつかの設定を行う必要があります。

簡単に操作できるようにする必要があります。変更を加え、それらの変更をバージョン管理し、他の環境に適用するのは簡単である必要があります。

代表的なデータが必要であり、そのデータを予測可能にする必要があります。たとえば、請求システムを構築している場合は、既知のクレジット制限を持つクライアントが必要です。これにより、テストケースを作成して、請求書の発行や支払いなどでクライアントに何が起こったかを追跡できます（単体テストではなく統合テスト） 。

代表的なデータボリュームに対してクエリを実行できるようにする必要があるため、本番環境だけでなく開発環境でもパフォーマンスの問題が発生します。

「実際の」データに影響を与えたいとは決して思わないでしょう。たとえば、電子メールアドレスと名前を匿名にしたり、パスワードを再設定したりする必要があります。

継続的なデータベース統合は、このほとんどの解決策を提供し、「開発環境用のデータベースをセットアップするのに1時間かかる」問題も解決します。

于 2012-08-14T16:03:05.323 に答える
1

私の経験では、環境ごとに一元化されたDB +データ（開発、テスト+統合、本番）を用意することが最善のアプローチでした。

  • 開発：開発者に自分のやりたいことをさせましょう。本番環境のようなデータが必要な場合は、機密データを難読化/削除します。このデータベースが軽量であるほど、移動、保守、およびバックアップに適しています。
  • テスト：これを使用して本番環境をシミュレートし、テスターが必要なすべてのデータをアプリケーションインターフェイスを介してのみ入力/取得できるようにします。この環境では、デプロイメントを本番環境に送信する前にテストすることもできます。悪意のあるDBインストーラーが本番環境のアプリを使用できない状態のままにしておくことは望ましくありません。必要に応じて、この環境に本番データを入力できますが、機密データも難読化/削除できます。大量に使用して、本番環境に移行する前にパフォーマンスの問題を特定できます。
  • 本番環境：本番環境のデータ/環境はそのままにしておきます。機密データが悪用されたり、開発者が誤ってデータを変更できるようにするDBエラー構成になったりしないようにします。
于 2012-08-14T17:40:44.867 に答える
0

私も同じ状況です。アーカイブデータを読み取り専用のファイルグループに移動して、バックアップと復元を1回だけ行う必要があると考えました。非アーカイブデータははるかに小さく、バックアップストレージと開発マシンに頻繁にコピーされる可能性があります。

もちろん、これは、データベースサイズの大部分を読み取り専用ファイルグループに分割できる場合にのみ機能します。

別のアイデアは、開発マシンで1回復元し、データベーススナップショットを使用してクリーンな状態にすばやく復元することです。私はそれが特に有用だと思いました。

于 2012-08-14T14:39:07.583 に答える