開発/ステージングと本番の間のデータベース同期

開発と本番の間のWordPressデータベースの同期に問題があり、他の人がそれをどのように解決しているか疑問に思っています。この質問については承知していますが、実際には、より厄介でより現実的なユースケースをカバーしていません。

WordPressのライブWebサイトがあるとします。すべてをダンプし、開発環境で複製しました。変更を始めました。1週間後、更新プログラムを展開する準備が整いました。それまでの間、本番サイトのデータベースは変更されました（新しい投稿、新しいコメントなど）。ロールアウト中に本番と開発の間で変更を同期する方法と、このプロセスを（少なくとも少なくとも）自動化することは可能ですか？

私が欠けているより良い方法があるかもしれませんが、私はあなたに2つのオプションを与えます

1. XMLエクスポートを使用して、新しい投稿とコメントをエクスポートします。次に、WordPressインポーターを使用して、新しい投稿とコメントをdevデータベースにインポートします

devにインポートしてから本番にデータベースを移動することをお勧めします。インポートすると、本番からすべての新しいメディアファイルがダウンロードされるためです。

その間に生産が変更されました（新しい投稿、新しいコメントなど）

これにより、変更されたコンテンツを取り込むという問題が解決されます。

2. INSERT IGNORE INTO MySqlコマンドを使用して、devから新しいテーブルを追加します。または、同じテーブル内の重複行を上書きするREPLACEコマンド。

MySqlを使用する前に、両方のデータベースのバックアップを作成し、gzデータベースを運用サーバーに移動し、ダンプをアップロードします（運用と同じ場合はdevの名前を変更します。

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

私はMySqlコマンドに慣れていないので、オプション1を選びます。

まったく同じ種類のデータ（新しいブログ投稿、新しいコメントなど）だけの場合は、なぜ本当に同期する必要があるのか​​わかりません。サイト上のコードの動作が変わるのではなく、それは同じだからです。新しいタイプのデータでない限り、私は通常それについて心配しません。

ライブサイトからのすべての投稿、ページ、コメントではなく、サイトのデータの良いサンプルがあることを常に確認しています。

並行して変更を行うというトピックに触れるとすぐに、構成管理の領域に触れます。多くのパターン、独自のコミュニティ（http://www.cmcrossroads.com/）、およびツール（バージョン管理用（svn / gitなど）ではなく、クリアケースなどの構成管理（パターン）のサポート用）。（まったく異なる領域）。

この場合、それはまだ単純な状況であり、いくつかの制限といくつかの手動作業といくつかのリストで動作することがわかります。

理想的なソリューションをよりわかりやすく説明するために考えているシナリオ：同じコードベースで作業する複数の開発者、複数のテスト環境、複数の受け入れ環境、世界の隅々にある複数の生産受け入れ環境。

これをもう少し専門的にしたい場合：

a）遭遇するすべての構成アイテムのリストを書き留めます。これは、WordPressコード自体、外部からのプラグイン、コンテンツ、メタデータであり、これらのどれを何らかの「管理」の下に置くかを決定します。

b）発生する可能性のあるワークフローを説明します。たとえば、修正により発生すること、新しい開発中に発生すること、どのような場合に自分の側でコンテンツを変更するか、何を呼び出すか、誰がそれを所有するかたとえば、新しい投稿または新しいプラグイン。

c）並行作業では、最初にどのCIを管理するかを説明し、フローが常に開発から本番への流れであるか、またはすべてを2つの方法で行う必要があるかを決定します。

d）（a）の下の各CIタイプについて、解決策を記述します。たとえば、すべてのテキスト（またはphpファイルのようなエクスポートされたテキストですが、XMLファイルのプレーンテキスト）のマージが可能です。これは実際には問題ありませんが、適切なマージツールが必要です。たとえば、ClearCaseを使用すると、3つの方法で以下の状況をマージできます。1）自明なマージ：これらは自動的に実行されます。2）非自明な自動：これらは自動的に実行されますが、チェックする必要があります3）非自明な非自動：これ競合です。たとえば、1行でいくつかの変更が行われました。自明ではない部分は、手作業で扱う必要のある最小限の部分です。適切なマージツールは、これを導きます。たとえば、クリアケース（ワードマージを行い、特定のファイルの他の商用または非商用のマージにリンクできます）タイプ）。さらに（a）の下でコピーのみが必要なファイルを特定した場合、それらの動作はマージされず、マージせずに他のバージョンを上書きするようにコピーされます（たとえば、変更していないプラグイン）。これらのタイプの多くは、異なる動作で可能です。しかし、CI間の関係を書き留め、

次に、非テキストベースのマージの場合、2つの場所で変更された画像など、それらの処理方法を決定する必要があります。ここでは、生産には常に優先順位があると判断できます（少なくともそれは私が思うことです）。

したがって...この問題を解決するには、さまざまなストリームをサポートするバージョン管理ツールが必要です。各ストリームは1つの部分を表します。（これはニーズによっては非常に複雑になる可能性がありますが、この場合は非常に単純だと思います）。

これらのストリームをWordPressインストールで管理し、データベースのコンテンツなどと同期できるようになった場合、CM /バージョン管理ツールでマージを実行し、他の環境にエクスポートして戻すことができます。

事は...最初にこれを書き留める必要があります。これは技術的なハックではありません。これはConfig Managementのデフォルトのパターンなので、ここでも奇妙なことは何もありませんが、書き留めておく必要があります。たとえば、インストールされたプラグインが別の環境とは異なるデータを使用してデータベースに変更を加える場合があるため、これについて追加の手順が必要です。

技術的にはほぼすべてが可能です。http：//www.cmcrossroads.com/forumsで、常に同じアプローチを使用し、同じCMパターンのセットを使用しているにもかかわらず、数十倍または数百倍複雑なシナリオを確認してください。

要するに、バージョン管理レイヤーをその下に置き、マージを自動化し、競合を処理してから、ターゲット環境にインポートします。ここに適合するストリーム戦略を考えて書き留めてください。ちょっとしたCM管理を実行します。それ以外の場合は、dbコピーハック、スクリプトなどをインストールするプロのソリューションになります。

実稼働データをステージングに同期する方法についての投稿をしたばかりです。それについてのブログ投稿をチェックしてください：http : //blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database -本番環境からステージング環境/

コードやその他のものも同期したい場合は、関連する無視ファイルでgitまたはmercurialリポジトリを作成することをお勧めします。

ステージングからprodへの差分更新を行いたい場合、移行スクリプトの作成が最も安全で最良の方法だと思います。