開発/ステージングと本番の間のデータベース同期
開発と本番の間のWordPressデータベースの同期に問題があり、他の人がそれをどのように解決しているのか疑問に思います。 この質問について/ /私は知っています しかしそれは実際にはもっと厄介でより現実的なユースケースをカバーしていません。
ライブのWordPress Webサイトがあるとします。私はすべてのものをダンプし、私たちの開発環境にそれを複製しました。私は変更を加え始めました。 1週間後、私は自分のアップデートをデプロイする準備が整いました。その間に、本番サイトのデータベースが変更されました（新しい投稿、新しいコメントなど）。ロールアウト中に生産と開発の間の変更を同期させるにはどうすればよいですか。また、（少なくとも）このプロセスを自動化することは可能ですか？
私は行方不明であるより良い方法があるかもしれませんが、私はあなたに2つの選択肢を与えるつもりです：
1. XMLエクスポートを使用して、新しい投稿とコメントをエクスポートします。それから WordPress Importer を使って新しい投稿やコメントを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://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress -multisite-database-from-production-to-staging-enviorment /
コードやその他のものも同期する場合は、関連する無視ファイルを使用してgitまたはMercurialリポジトリを作成することをお勧めします。
ステージングからprodへの差分更新を行いたい場合、移行スクリプトの作成が最も安全で最良の方法だと思います。
並行して変更を行うというトピックに触れるとすぐに、構成管理の領域に触れます。たくさんのパターンがあるので、独自のコミュニティ（http://www.cmcrossroads.com/）やツールは（svn/gitのような）バージョン管理のためではなく、クリアケースのような設定管理（パターン）のサポートのためのものです。 （全く異なる分野）。
この場合、それはまだ単純な状況であり、あなたはそれがいくつかの制限といくつかの手動作業といくつかのリストで動作することがわかります。
私が考えているシナリオは、理想的なソリューションをもっと説明的にすることです。同じコードベースで作業している複数の開発者、複数のテスト環境、複数の受け入れ環境、おそらく世界中の複数の生産受け入れ環境。
あなたがこれをもう少し専門的にしたいと思うならば：
a）あなたが遭遇したすべての設定項目のリストを書き留めてください、これはWordPressコード自身、外部からのプラグイン、コンテンツ、メタデータであるかもしれません。
b）起こり得るワークフローを説明する。修正で何が起こるか、開発中の新しいもので何が起こるか、どのケースであなたはあなたの側でコンテンツを変更しますか、それが呼ばれるもの、そしてそれを誰がするか、誰がそれを持ちますか。新しい投稿または新しいプラグイン.
c）並行作業では、まずどのCIを管理したいのかを記述し、フローが常に開発から本番への流れであるのか、それとも2つの方法をすべて実行する必要があるのかを決定します。
d）（a）の各CIタイプについて、解決策を記入する。例えば。テキスト（またはphpファイルのようにエクスポートされたテキストですが、XMLファイルのプレーンテキスト）のすべてに対してマージが可能です。これは本当に問題ありませんが、優れたマージツールが必要です。例えばClearCaseでは、3つの方法で以下の状況をマージできます。1）自明なマージ：これらは自動的に実行されます2）非自明な自動：確認する必要があります3）非自明で非自動：これは衝突など1行にいくつかの変更が加えられました。自明でないことは手動で気をつける必要がある最低限の部分です、良いマージツールはこれであなたを導くでしょう。クリアケースのもの（これはWordのマージも行い、特定のファイルタイプに対して他の商用または非商用のマージをリンクできる場所もあります）。さらに、（a）の下にコピー専用のファイルを指定した場合、それらの動作はマージされず、マージされずに他のバージョンに上書きされることになります（変更されていないプラグインなど）。これらの種類の多くは異なる動作で可能です。しかし、CI間の関係を書き留めて、
それから非テキストベースのマージのためにあなたはそれらをどのように扱うかについて決定をする必要があります。 2か所で変更された画像ここでは、プロダクションが常に優先されることを決定できます（少なくともそれが私の考えていることです）。
だから...この問題を解決するには、さまざまなストリームをサポートするバージョン管理ツールが必要です。各ストリームは1つの部分を表します。 （これはあなたのニーズによっては非常に複雑になることがありますが、この場合は非常に単純だと思います）。
あなたがWordPressのインストールの下にこれらのストリームを持つことができ、データベースのコンテンツとも同期させることができたら... CM /バージョン管理ツールでマージを実行してから他の環境にエクスポートすることができます。
事は...あなたは最初にこれを書き留める必要があります。これは技術的なハックではありません。これは構成管理に関するデフォルトのパターンなので、ここでも奇妙なことは何もありませんが、それを書き留める必要があります。あなたは見つけるかもしれません。インストールされたプラグインは他の環境とは異なるいくつかのデータでデータベースに変更を加えるので、あなたはこれの周りに追加の手順が必要です。
技術的にはほとんどすべてのことが可能です。常に同じアプローチを使用し、同じCMパターンのセットを使用しますが、数十倍から数百倍複雑なシナリオについては、 http://www.cmcrossroads.com/forums を参照してください。
つまり、バージョン管理レイヤをその下に配置し、マージを自動化して競合を処理してから、ターゲット環境にインポートします。ここに収まるストリーム戦略を考え出して、それを書き留めます。 10代のちょっとしたCM管理を実行します。それはそうでなければいくつかのDBコピーハック、スクリプトなどをインストールする専門的な解決策になるでしょう...