WordPressステージングをデータ損失なしで本番環境にプッシュする方法
John Turner
ジョン・ターナー
ステージングの変更を本番環境に反映させた回数は数え切れないほどありますが、うまくいかなかったときはすべて同じ根本原因がありました。それは、上書きしようとしているものを確認せずにプッシュを急いだことです。
過去数時間(または数日)をステージングサイトでの変更構築に費やしたなら、おそらくそれらを本番環境に反映させる準備ができたでしょう。新しいテーマ、更新されたプラグイン、再設計されたページなど、何であれ、テストして動作することを確認しました。
それを本番サイトにプッシュするところで、事態は危険になります。
私はこのためにDuplicatorを使用しています。なぜなら、プロセス全体を完全に制御できるからです。ステージングから移行パッケージを構築し、どのデータベーステーブルを含めるかを正確に選択し、単一のボタンを信頼して正しい判断を任せるのではなく、自分の条件で本番環境にインストールできます。
その制御が重要です。不注意なプッシュは、新しい注文を消去したり、すべてのユーザーをログアウトさせたり、訪問者の前で本番サイトを壊したりする可能性があります。その間、あなたはそれを修正するために奔走しなければなりません。
このチュートリアルでは、WordPressのステージングサイトを本番環境にプッシュするために行うこと、そして人々を不意打ちする間違いについて説明します。
主なポイントは次のとおりです:
- ホストによって2つの主な方法があります。ホスティングプロバイダーの組み込みプッシュが利用可能であればそれを使用するか、利用できない場合はDuplicatorのバックアップと移行方法を使用します。これはホストに関係なく機能するためです。
- 完全なデータベースプッシュは、本番環境でのアクティビティを消去する可能性があります。ステージングを作成した後にサイトに追加された注文、コメント、またはサインアップは、プッシュ前にそれらのテーブルを除外しない限り上書きされます。
- タイミングは、人々が予想する以上に重要です。ステージングの作成とプッシュの間のギャップが長ければ長いほど、本番環境のデータはより危険にさらされるため、できるだけ早くプッシュしてください。
目次
ステージングを本番環境にプッシュする必要があるのはいつですか?
ステージングで行ったすべての変更を本番環境に反映させる必要はありません。違いを知ることで、不要なリスクを負うことを避けることができます。
本格的なプッシュが必要なのは次のとおりです。
- メジャーなテーマまたはプラグインのアップデートをテストし、正常に動作することを確認した
- 公開する準備ができた新しいページまたはコンテンツを作成した
- 構造的またはコードの変更を行った
- WordPressコアのアップデートを実行し、何も壊れていないことを確認した
見た目を確認するためだけに行った、どうせやり直す予定の互換性テストを実行した、または保持する予定のない変更を行った場合は、本格的なプッシュは必要ないでしょう。
私はステージングを意図的に壊す場所として扱っています。
本番環境へのプッシュは異なります。それはあなたがコミットする瞬間です。
すべてのプッシュには、データのオーバーライト、数分間のダウンタイム、または特定に時間のかかるURLの不一致など、いくつかのリスクが伴います。まだテストが完了していない変更に対して、それらのどれも価値はありません。
そのため、何かを触る前に、ステージングにあるものが実際に完了していることを確認してください。
開始する前に必要なもの
何かをプッシュする前に、これらを準備してください。このステップをスキップすると、20分のタスクが数時間のスクランブルに変わります。
- プッシュを開始する直前に取得した、本番サイトの新鮮なバックアップ
- 手動でファイルをアップロードしたり、何かを手作業で修正したりする必要がある場合に備えて、FTPまたはSFTPアクセス、またはホスティングアカウントのファイルマネージャー
- 手動での修正が必要な場合のフォールバックとして、phpMyAdminまたはホストのデータベースツールを介したデータベースアクセス
- ステージングで何が変更されたかの明確なリスト。これにより、プッシュしているものを正確に把握し、正しく反映されたかを確認できます。
- ステージングサイトにDuplicator Proがインストールされていること。次のセクションで移行パッケージを作成するために使用するためです。
本番サイトのバックアップは、このリストの中でスキップできない唯一の項目です。「プッシュは常に機能する」という理由でスキップする人がいますが、常に機能するわけではありません。
機能しない場合、そのバックアップは、サイトをゼロから再構築するのとあなたを隔てる唯一のものです。
ステージングを本番環境にプッシュするためのさまざまな方法
すべてのWordPressセットアップで同じツールが利用できるわけではなく、あるサイトで機能することが別のサイトに存在しない場合があります。ステップバイステップに入る前に、ホストやプラグインに応じて、利用可能なものを紹介します。
ホスティング提供のステージングプッシュ
WP Engine、Kinsta、SiteGround、Flywheelなどのホストは、ステージングプッシュツールをダッシュボードに直接組み込んでいます。ホストがこれを提供している場合、サーバーのセットアップに合わせて構築されているため、通常は最も速いオプションです。
トレードオフは、ホストのプランティアに含まれるものに限定され、一部のプランではまったく提供されないことです。
専用ステージングプラグインプッシュ
ステージング専用に構築されたプラグイン(WP Stagingなど)には、ファイルとデータベースの選択機能を備えた独自のプッシュボタンが含まれています。ステージングがすでに主なユースケースであった場合は、これはうまく機能します。
トレードオフは、この1つのタスク専用のプラグインをもう1つ追加することです。
バックアップと移行方法
これは私が使用する方法であり、このチュートリアルで詳細に説明する方法です。
ステージングサイトから移行パッケージをビルドし、含めるものを正確に選択して、本番環境にインストールします。Duplicatorのようなツールはこれをうまく処理します。
シングルプッシュボタンよりもいくつかの手順が必要ですが、ホストに関係なく機能します。また、上書きするものを最も細かく制御できます。
手動方法(FTPとphpMyAdmin)
ファイルとデータベーステーブルを手作業で1つずつコピーします。これは、他のツールが利用できない場合の最後の手段です。機能しますが、遅く、エラーが発生しやすいです。
ホストがステージングプッシュをサポートしているかどうかに依存せず、上書きしても安全なものをテーブルごとに決定できるため、バックアップと移行方法を好みます。
WordPressステージングサイトを本番環境にプッシュする方法
ステップバイステップで実行することを示します。
- 本番サイトをまずバックアップ:万が一問題が発生した場合でも、数分で本番環境を復元できるセーフティネットを作成します。
- プッシュする内容を決定:サイト全体をプッシュするか、注文やコメントなどの本番データを保護する選択的なプッシュを行うかを決定します。
- ステージングから移行パッケージを作成:ステージングサイトのファイルとデータベースを、Duplicatorが本番環境にインストールできるファイルにパッケージ化します。
- パッケージファイルを本番サーバーに転送:インストーラーとアーカイブを本番サーバーに転送し、インストールを実行できるようにします。
- 本番サイトでインストーラーを実行:ステージングの変更を本番環境にインストールし、データベースを一致するように更新します。
- 本番サイトを確認:離れる前にすべてが正しく機能していることを確認します。
ステップ1:まず本番サイトをバックアップする
バックアップは任意ではありません。本番環境に触れる前に、何か問題が発生した場合に戻れる方法が必要です。
この作業に私が最もよく使うツールはDuplicatorです。移行プラグインでもあるため、サイトを保護し、ステージング環境をセットアップし、必要に応じて変更を元に戻すのに役立ちます。

本番サイトでDuplicatorを開き、バックアップ画面に移動します。新規追加ボタンをクリックします。

後で認識できる名前、例えば「ステージングプッシュ前のバックアップ」でバックアップに名前を付けます。すべてをバックアップするために、サイト全体のバックアッププリセットを選択します。

次へをクリックします。スキャンからの通知を確認したら、バックアップを作成します。

両方のバックアップファイルをダウンロードします。サーバー外のどこか、例えばクラウドストレージやローカルコンピューターに保存します。
深刻なエラーでサイトがオフラインになった場合でもサイトを復元できるため、Duplicator Cloudを使用することをお勧めします。

ステップ2:プッシュするデータを選択する
全体プッシュは、ファイル、テーマ、プラグイン、およびデータベース全体をすべて置き換えます。新しいテーマや大幅な構造更新などの大きな変更を行った場合は、これを使用してください。
選択的プッシュは、特定のファイルまたはデータベーステーブルのみを更新します。ステージングを開始してから本番環境で行われた新しい注文、コメント、またはユーザー登録などの本番データを保護するため、少数の変更のみを行った場合はこれを使用してください。
データベース全体をプッシュすると、ステージング作成後に本番サイトで行われたことはすべて消去され、ステージングの古いデータに置き換えられます。
次のステップで移行パッケージを作成する前に、どのテーブルが重要かを決定してください。
ステージングを開始してから本番環境で何が変更されたかわからない場合は、今すぐ確認してください。プッシュ後に復元するよりも、プッシュ前に「このテーブルは必要か?」と尋ねる方がはるかに簡単です。
ステップ3:ステージングから移行パッケージを作成する
ステージングサイトで、Duplicatorを使用して新しいバックアップを作成します。これはステップ1で使用したのと同じプロセスですが、今回はステージングで行います。
バックアップセクションで、バックアッププリセットを使用して含めるデータをカスタマイズします。ファイルおよびデータベーステーブルフィルターも使用できます。

Duplicatorでは、データベースビルドからwp_woocommerce_ordersやwp_commentsなどの特定のテーブルを除外できます。
バックアップの作成を完了し、ダウンロードします。インストーラー(installer.php)とアーカイブ(サイトのファイルとデータベースを含むzip)の2つのファイルが生成されます。

ステップ4:ステージングファイルを本番サーバーに転送する
FTP、SFTP、またはホストのファイルマネージャーを使用して、ライブサーバーに接続します。
installer.phpファイルとアーカイブファイルをライブサイトのルートディレクトリにアップロードします。これは、サイトのメインのwp-config.phpファイルが存在するのと同じフォルダです。

ステージングサイトが同じサーバーのサブフォルダ(例:yoursite.com/staging/)にある場合、この転送は多くの場合、完全なアップロードではなく単なるファイルコピーであり、時間を節約できます。
次に進む前に、両方のファイルがライブサイトのルートディレクトリに表示されていることを確認してください。

ステップ5:本番サイトでインストーラーを実行する
ブラウザで yoursite.com/installer.php にアクセスします。「yoursite.com」はライブドメインに置き換えてください。
データベース接続の詳細を再確認してください。ライブサイトのデータベースを指している必要があり、ステージングのデータベースではありません。

インストールを続行します。完了したら、管理ログインボタンで再度ログインします。

ステップ6:本番サイトを確認する
ライブサイトを開き、まずホームページを確認します。
いくつかの重要なページをクリックして確認します。ステージングで変更したページと、変更していないページをいくつか確認して、関係のないものが壊れていないことを確認します。
通常の認証情報でwp-adminにログインしてみてください。サイトにフォームやチェックアウトフローがある場合は、それらをテストします。
キャッシュをクリアします(サーバーレベルのキャッシュと実行中のキャッシュプラグインの両方)。キャッシュされたページは、プッシュが成功した後でも古いコンテンツを表示することがあります。
最後に、ステージングサイトがまだ稼働している場合は、表示設定でnoindexに設定されていることを再確認してください。忘れがちですが、検索エンジンに重複サイトをクロールされたくはありません。
トラブルシューティング:ステージングを本番環境にプッシュする際の一般的なエラー
プッシュ直後のホワイトスクリーン
ライブサイトをロードすると、エラーメッセージなしの空白の白いページが表示されます。
これは通常、ステージングでは正常に機能していたプラグインがライブサーバーの環境(多くの場合PHPバージョンの違い)と互換性がないことを意味します。
ホストのPHPバージョンとステージングで実行されていたバージョンを比較します。一致しない場合は、本番環境のPHPバージョンをステージングのバージョンに合わせるか、ステップ1のバックアップを使用して競合の原因となっているプラグインをロールバックします。
プッシュ後のwp-adminへのログイン不可
通常のログイン認証情報を入力しても、「ユーザー名またはパスワードが正しくありません」と表示されます。正しいことはわかっているのに。
データベース全体をプッシュすると、ライブサイトのユーザーテーブルがステージングのものに置き換えられるため、ライブログインがデータベース内の情報と一致しなくなります。
phpMyAdminまたはホストのデータベースツールを直接使用して管理者パスワードをリセットするか、ステップ1のバックアップを復元し、ユーザーテーブルを除外する選択的プッシュとしてプッシュをやり直します。
REST APIエラーまたはブロックエディターの破損
ブロックエディターがロードされないか、ブラウザコンソールにREST APIエラーが表示されます。
データベース内のシリアライズされたデータが、ライブドメインではなくステージングURLを参照しており、DuplicatorのURL置換ですべてのインスタンスをキャッチできませんでした。
Duplicatorは検索と置換を実行します。ただし、Search & Replace Everythingのようなプラグインを使用して、シリアライズされたフィールドに残っているステージングURLをターゲットにすることができます。
注文、コメント、または新規登録が見つからない
顧客が最近の注文が消えた、またはここ数日のコメントが消えたと報告しています。
これは、ステージングが作成された後に発生した新しいアクティビティを持つライブテーブルをフルデータベースプッシュが上書きした場合に発生します。
すぐに最初のバックアップを復元し、次にwp_woocommerce_orders、wp_comments、およびライブアクティビティを持つその他のテーブルを除外する選択的プッシュとしてプッシュをやり直してください。
転送中にプロセスが停止またはタイムアウトする
インストールが途中でハングするか、ブラウザに明確な失敗メッセージなしでタイムアウトエラーが表示されます。
特に共有ホスティングでは、大きなアーカイブファイルがサーバーのアップロード制限または実行時間制限を超える可能性があります。
ホストの最大アップロードサイズとPHP実行時間設定を確認し、プラグインがサポートしている場合はパッケージをより小さなピースに分割するか、プッシュ中に制限を一時的に引き上げるようにホストに連絡してください。
ホストのプッシュボタンが無効になっているか、表示されない
ホスティングダッシュボードでステージングプッシュオプションを探すと、無効になっているか、まったく存在しません。
これは通常、ステージング作成自体が含まれていても、ホスティングプランのティアにステージングプッシュ機能が含まれていないことを意味します。
代わりにDuplicatorのバックアップと移行方法を使用してください。これはホストのプランがサポートするものに依存しません。
よくある質問(FAQ)
Duplicatorにはライブへのワンクリックプッシュ機能がありますか?
いいえ、しかしそれは必要ありません。Duplicatorのバックアップと移行ツールを使用すると、ステージングからパッケージを構築し、含めるものを完全に制御して本番環境にインストールできます。これは、ホスティングのセットアップやプランのティアに関係なく機能します。
ステージングをライブにプッシュすると、最近の注文やコメントが削除されますか?
ステージングを作成した後にライブサイトでアクティビティが発生した場合、フルデータベースプッシュを行うと削除される可能性があります。パッケージを構築する前に、wp_woocommerce_ordersやwp_commentsなどのテーブルを除外する選択的プッシュを行うことでこれを回避してください。
データベース全体を上書きせずに、特定のファイルのみをプッシュするにはどうすればよいですか?
ステージングサイトのバックアップを作成する際に、保護したい特定のテーブルをパッケージを構築する前に除外します。これにより、実際に変更したファイルとテーブルを更新しながら、本番環境でこれらのテーブルを変更せずに保持できます。
ステージングをライブにプッシュするためにFTPアクセスが必要ですか?
メインの方法で必要なくても、フォールバックとして必要です。ステージングとライブが同じサーバーを共有している場合、手動転送を完全にスキップできる可能性がありますが、何かを手動で修正する必要がある場合は、FTPまたはホストのファイルマネージャーが不可欠です。
プッシュが途中で失敗した場合はどうなりますか?
ライブサイトが部分的に更新された状態になる可能性があります。サイトを再度機能させるために、ステップ1で作成したバックアップをすぐに復元し、再度試す前に原因(通常はファイルサイズまたはサーバータイムアウトの問題)をトラブルシューティングしてください。
ステージングをライブにプッシュした後、オフラインにする必要がありますか?
オフラインにする必要はありませんが、検索エンジンがクロールしないように、noindexに設定されていることを確認してください。多くの人は、毎回再作成するのではなく、次の変更のためにステージングを実行し続けます。
ホストがステージングプッシュを提供していない場合は、どの方法を使用する必要がありますか?
Duplicatorのバックアップと移行方法を使用してください。自分でパッケージを構築してインストールするため、ホスティングプランにプッシュ機能が含まれているかどうかに関係ありません。
すべてのプッシュを移行として扱う。なぜなら、それは移行だからです。
これで、ステージングの変更をライブサイトに適用するための完全なプロセスができました。何かが壊れるかどうかを推測する必要はありません。
今後もいくつかの点に注意してください。
ステージングで作業している間もライブアクティビティは発生するため、ステージングを作成してから変更をプッシュするまでの時間が長くなるほど、完全なプッシュで上書きするデータのリスクが高まります。最初のプッシュだけでなく、すべてのプッシュの前にライブで変更されたものを確認してください。
他の場所ではカバーされていないヒントを1つ紹介します。サイトが小さい場合でも、トラフィックが最も少ない時間帯にプッシュをスケジュールしてください。アクティブな訪問者が少ないほど、プッシュにかかる数分間に受信した注文やコメントを上書きする可能性が少なくなります。
次のプッシュの前にサイトを保護する
ステージングからライブへのすべてのプッシュには、すべての手順を注意深く実行した場合でもリスクが伴います。開始直前に取得したバックアップは、簡単な修正とサイトの再構築との違いです。
Duplicator Proは、まさにこの目的のために構築されています。フルサイトのバックアップ、選択的なデータベース制御、およびホストがサポートするものを問わず機能する移行プロセスを提供します。すでに150万以上のWordPressの専門家が、これと同様の変更を通じてサイトを保護するために使用しています。
最後のバックアップが1週間前のものであることが判明するまで、プッシュが失敗するのを待たないでください。
このチュートリアルがお役に立った場合は、これらのガイドもブックマークする価値があります。