ステージングサイト、どのようにしてDB内の同期更新を管理しますか？
開発者はライブサーバーにリリースする前にステージングサイトで更新をテストすることが広く受け入れられていますが、開発の更新でWordpress DBの変更が必要になると、ライブサイトのユーザーもDBを更新するため作業が複雑になります。
私が想像できる唯一の（混乱した）流れは以下の通りです：
- ローカルサーバー（WAMP、XAMPなど）でテストする
- 展開する準備ができたら、ライブサイトをメンテナンスモードにします。
- バックアップライブサイト（Duplicator、sqldumpなど）
- ステージングサイトにロックされたライブサイトのクローンを作成する
- ローカル環境からステージングサイトに変更をアップロードする
- ステージングサイトをテストする
- ステージングサイトをプッシュして生きます。
- メンテナンスモードを解除
上記の流れの欠点：
- 開発者がステージングサイトで更新を慎重にテストしている間、ダウンタイムはユーザーの予想よりも長くなる可能性があります。
- たとえばsiteorigin pagebuilderのレイアウトはdbに格納されるため、レイアウトを変更した場合はステージングサイトに手動でインポートする必要があります。この場合、単にステージングサイトにページをドロップしてインポートし、作業している場合はライブサイトにインポートするだけで十分です。
これを達成するためのより良く、より自動化された方法があるのだろうか。
どう思いますか？
要求に応じて、EDITは過去にいくつかの解決策を提案してきましたが、決定的な解決策を提供するものはありません。
- 9/2010 - dev/stagingとproductionの間のデータベース同期
- 12/2011 - wp_optionsテーブルを変更する更新または新規プラグインのデプロイ
- 9/2014 - 新しい投稿やページを上書きせずにローカルの変更をライブサーバーにアップロードする方法
- 1/2015 - ワードプレスサイトのブログをプロダクションとステージングで管理するには？
WordPressに特化した新しいホスティングプロバイダは通常、この問題を軽減するためのツールを用意しています。私は、クライアントがPantheonに きちんとしたGit対応のワークフロー を持っていることを示しました。プロダクションからステージングへデータベースをコピーすることは、それらのインターフェースでワンクリックです。このワークフローが尊重されていれば、本番データベースをめちゃくちゃにするという問題がほとんどなくなり、開発段階でどちらの段階でも本番DBデータの新しいクローンで自分の変更をテストできるようになります。
Pantheonを使用する必要はありません。独自のツールを使用して、プロセスに同様のアプローチを採用できます（Git + WP Migrate DBなどのDBクローニングプラグイン）。私はこの方法が私にはうまくいくと思います。
質問：ステージングのテスト中に、なぜ本番サイトをメンテナンスモードにするのですか？ほとんどの場合、その必要はありません。私が考えることができる唯一のケースは、追加のユーザーデータに非常に敏感なある種の非常に脆弱なシステムを持っていて、起動するのに致命的なバグがあることです。自社製品のアーキテクチャ全体を再考する。
VersionPress を見てください。これはGITのバージョン管理をプロセス全体にもたらします（ファイルとデータベース）。
彼らのサイトに記載されているように：
VersionPressは痛みのないステージングを提供します 。つまり、変更に対して安全なテスト環境を簡単に作成し、準備が整ったときにのみそれらをマージすることができます。ここで重要なのはMergeです - VersionPressはあなたのライブサイトがその間に新しいコンテンツを持っている状況をシームレスに扱います。