実稼働データベースをテストデータに変換する

テストが実稼働に近いほど、実稼働の動作をエミュレートできます。データベースのバックアップを運用環境からテスト環境にコピーしたいのですが、テストが機能するように変更し、運用環境を妨害したり、実際の顧客に誤ってメールを送信したりしないようにする必要がありますweb/%secure/base_urlか？

この質問について考える別の方法は、私自身の生産データからMagentoサンプルデータのようなものを生成する方法を検討することです。

1）DBダンプ

エクスポートを行うと、次のテーブルの構造のみをエクスポートできます。

core_cache
core_cache_option
core_cache_tag
log_customer
log_quote
log_summary
log_summary_type
log_url
log_url_info
log_visitor
log_visitor_info
log_visitor_online
enterprise_logging_event
enterprise_logging_event_changes
index_event
index_process_event
report_event
report_viewed_product_index
dataflow_batch_export
dataflow_batch_import

またcore_url_rewrite、これらのすべてのレコードが必要な場合（さまざまなテストの場合）を除き、構造を使用してのみインポートし、インポート後にカタログURL書き換えリインデックスを実行することもできます。

放棄されたカートを掃除することもできます（ヒント：）sales_flat_quote、必要がない場合は注文を削除して、限られた数だけ保持することもできます

2）構成設定

• web /（unsecure | secure）/ base_url
• 連絡先メールアドレス
• system/smtp/disable誤ってメールを送信しないように、メールを無効にします（）

3）顧客情報の匿名化

• MagentoのAnonygentoモジュールを使用できます
• 顧客情報/販売注文などを難読化する独自のスクリプトを作成する

4）モジュール設定

• 支払い/発送モジュールのサンドボックスモードを有効にし、適切な設定を行うことができます
• さまざまな統合に使用されるモジュールをチェックします（無効にするか、サンドボックスモードに設定します）

分岐用のDBダンプを処理するスクリプトを作成しました。この記事を読んでください。

基本的なプリンシパルはlocal.xml、データベースの資格情報を取得するためにを読み取り、それに基づいてデータをダンプすることです。ダンプは、構造のみとデータの2つの部分に分割されます。ただし、重要なのは、非必須データをスキップすることで従来のダンププロセスを高速化し、ダンプ中にライブサイトをブロック/ハングさせるテーブルロックを最も重要に防止することです。

MySQLダンプを取得したら、次を使用するだけでURLを非常に簡単に変更できます。 sed

sed -i 's/www.mydomain.com/staging.mydomain.com/g' ./var/db.sql

次に、mysqlインポートを新しいDBに実行します。

したがって、スクリプトがなければ、非常に基本的なバージョンは次のようになります。

mysqldump -hHostname -uUsername LiveDbname -p > db.sql
sed -i 's/www.mydomain.com/staging.mydomain.com/g' db.sql
mysql -hHostname -uUsername DevDbname -p < db.sql

この方法でDBのURLを変更した場合、local.xmlファイルを削除するか、インストーラーを再実行する必要はまったくありません。

分岐のプロセス全体は、Magento GITガイドで詳しく説明されています。これは開発ブランチを作成するのに適したプロセスですが、ライブDBを大幅に縮小します。そのため、テストは実際のサイトと完全に同じになるわけではありません。

そのため、ステージングサイトには、バニラDBダンプ、sed replace、DBインポートで十分です。また、ライブサイトをできる限り厳密にミラーリング/マッチングします。

顧客とのコミュニケーションを防ぐという点では、テストのために常に意図的にアカウントを作成し、実際の顧客の注文をテストに使用することは決してないため、それが必要であることは一度もありません。

電子メールの問題に対する1つのオプションは、すべての電子メールを自分にリダイレクトするように開発サイトを構成することです。少し心を追加します。

それを行う方法は環境に依存します-これをvhostに追加することで仕事ができます：

php_admin_value sendmail_path "/usr/sbin/sendmail -i -- xyphoid@example.com,coworker@example.com"

なし。安全なURLと安全でないURLを変更するだけで十分です。

log_*ダンプを軽くするために、テーブルデータを省略することもできます。

これを試してください。ユーザーのメールをスクランブルして、テスト環境から実際の顧客に誤ってメールを送信する問題を解決します。

UPDATE customer_entity SET email = REPLACE(email, '@', '-test@abcxyz123-')