プラグインを更新したい、デザインを変えたい、フォームの項目を増やしたい。どれも本番でいきなり試すわけにいかない作業です。かといって自分のパソコンの中に環境を作っても、サーバーのPHPバージョンや .htaccess の効き方が違うため、本番でだけ壊れることがあります。そこで、本番と同じレンタルサーバーの中にテスト環境を用意する方法をまとめます。追加のドメインを買わずに済ませる構成、複製直後にログインできなくなる原因、そして最も見落とされる「テスト環境からのメール誤送信」まで扱います。
置き場所は3つ。どれを選ぶかで手間が変わります
ひとつめは、サーバー契約に最初から付いてくる初期ドメインを使う方法です。契約時に割り当てられる、サーバー会社のドメインの一部を借りる形のアドレスがそれにあたります。追加のドメインを取得する必要がなく、本番のドメイン設定にも一切触らないので、いちばん事故が起きにくい構成です。テスト環境の定番はこれです。
ふたつめは、本番ドメインのサブドメインを切る方法です。見た目は分かりやすいのですが、ここで先に確認することがあります。ドメインをどこの会社で管理しているか、です。サーバーがA社でもドメインの管理が別会社なら、A社の管理画面だけではサブドメインを切れないことがあります。DNSレコードを追加する権限がどちらにあるのかを最初に確かめてください。ここを飛ばすと、方式そのものをやり直すことになります。
みっつめは、本番とは別のサーバーに置く方法です。制作側が自分で契約している環境に置けば、本番ドメインにも本番サーバーにも依存しません。ある案件ではこの形で作り、その後の追加開発でもそのまま使い回しています。2回目以降は環境構築の相談も費用も発生しないので、継続的に手を入れるサイトなら結果的に安上がりです。サーバーを選ぶ段階の考え方はレンタルサーバーのプラン選び、費用と性能のどこを見るべきかにまとめています。
| 置き場所 | 費用 | 準備の手間 | 注意点 |
|---|---|---|---|
| 初期ドメイン | 追加費用なし | 小さい | URLが本番と大きく異なる |
| 本番のサブドメイン | 追加費用なし | DNSの管理権限しだい | 本番のDNS設定を触る。検索に拾われる恐れ |
| 別サーバー | 月額が別途かかる | 中くらい | PHPやMySQLの版が本番と揃わないことがある |
| 固定ページの複製 | なし | ごく小さい | 1ページの見た目確認まで。プラグイン更新の検証には使えない |
作る手順
- テスト用のデータベースを新規に作る。本番と同じデータベースを共有させない
- 本番のファイル一式と、データベースのダンプを取得する
- コピーしたファイルをテスト側へ配置し、
wp-config.phpの接続先を新しいデータベースへ書き換える - データベース内のURLを置換する。シリアライズされた値を壊さないよう、WP-CLIの
wp search-replaceなど専用の手段を使う - ディレクトリ全体にBasic認証をかける
- SSLを有効にする。無料SSLは発行から反映まで1時間ほどかかることがある
- 管理画面の表示設定で、検索エンジンにインデックスさせない指定を入れる
Basic認証の書き方と、担当者に渡すときの注意は公開前のサイトをBasic認証で隠す設定と、担当者に渡す時の注意に書きました。手順としてはここまでで、実作業は3時間ほどで終わります。時間がかかるのはSSLの反映待ちなので、着手前に「証明書の反映に約1時間かかります」と伝えておくと、待ち時間への不満は出ません。
複製したのにログインできない。まず疑うのはreCAPTCHAです
本番をそのままコピーすると、テスト側の管理画面にログインできなくなることがあります。パスワードは合っているのに弾かれる、送信しても画面が戻ってくる。この症状の第一容疑はreCAPTCHAです。
reCAPTCHAは登録したドメインでしか検証が通らない仕組みです。複製先のドメインは登録されていないため、ログインフォームの認証は必ず失敗します。同じようにドメインへ依存して問題を起こすのは、ログインURLを変更したりIPで制限したりするセキュリティ系プラグイン、キャッシュ系プラグイン、SSLを強制的にリダイレクトする系のプラグインです。テスト環境を作る作業項目の中に、最初から「ドメイン依存プラグインの無効化」を入れておくと、この足止めは起きません。
ひとつ補足すると、無効化ではなく削除してしまうと構成の差分になります。テスト側で検証した内容をあとで本番へ反映するとき、テスト環境にだけプラグインが存在しない状態になっているからです。無効化に留めるか、削除したなら差分として記録に残してください。
あわせて、本番のログインURLがカスタマイズされている場合、複製先でも同じURLになります。あるサイトでは管理画面のパスもユーザー名も独自のものに変えてあり、通常の /wp-login.php では入口にすら辿り着けませんでした。複製の前に、ログイン方法を本番の運用者から聞いておいてください。
URLを置換しても書き換わらない場所がある
データベースの一括置換を通しても、変わらない箇所が残ります。代表的なのは、テーマの functions.php やテンプレートに直接書かれたドメイン、フォームプラグインに設定された送信先メールアドレス、そして外部サービス側に登録したコールバックのURLです。地図や決済のように、外部の管理画面でドメインを登録しているものは、データベースをいくら置換しても当然そのままです。
ここは完全に潰しきるより、移行完了の報告と同時に「置換されない場所がある」と伝えておくほうが現実的です。あとから不具合が出ても想定内として扱えます。
いちばん危ないのはメールです
テスト環境のフォームは、本番と同じ設定を引き継いでいます。つまり、動作確認のつもりで送信したテストの内容が、実際の問い合わせ窓口に届きます。自動返信を設定していれば、入力したアドレス宛に返信も飛びます。会員機能や予約機能を複製した場合、条件によっては実在の顧客宛にメールが出る可能性すらあります。
対策は単純で、テスト側のフォームの送信先を自分のアドレスに差し替えるか、メール送信そのものを止める設定を入れることです。この一手間を省いて、実際の窓口へテスト送信を流してしまう事故は珍しくありません。
実際に作った2つの環境
ひとつめは、地域の医療関係団体のサイトです。構成は初期ドメイン＋専用データベースの新規作成＋Basic認証＋無料SSL。作業は3時間半、費用は15,000円でした。複製直後にログインできず、原因は前述のreCAPTCHAでした。この案件では「テスト環境と本番を常に同じ状態にしておきたい」という要望も出ましたが、常時同期させるとテスト環境が本番と同じものになり、検証する場所がなくなります。テスト環境で検証してから本番へ反映する、という一方向の流れに整理して運用フローを決めました。
ふたつめは、制作会社経由で受けた企業サイトです。依頼主の先にエンドクライアントがいる構造なので、テスト→依頼主の確認→クライアントの承認→本番反映、という4段階になります。この承認に6日かかった回もありました。テスト環境のURLは、そのまま社内報告の材料になります。
この案件では失敗もしています。本番へ反映するときに、テスト版のままのファイルを上げてしまい、メニューの項目数が本番と食い違いました。テストと本番の2系統を持つ運用では必ず起きる種類のミスなので、どのファイルを、どの版で、何件上げるのかを書き出してから反映するようにしています。あわせて、CSSやテンプレートを変えた直後の表示崩れはブラウザキャッシュが原因のことが多いため、反映の連絡には最初からキャッシュクリアの案内を添えます。
なお、直したいのが固定ページ1枚の中身だけなら、環境を作るまでもありません。そのページを複製して下書きで作り込み、編集画面のURLを渡して見てもらい、承認後に本番へ移す。これで足ります。ただし複製を残したままにすると、固定ページの一覧に似たタイトルが並び、本番と取り違えて編集する事故が起きます。タイトルに印を付けるか、不要になった時点で削除してもらってください。
作ったあとの扱い
テスト環境は放置すると腐ります。本番だけが更新され、半年後には別物になっているからです。次に使うときは、そのときの本番から作り直すつもりでいたほうが確実です。ずっと同じものを維持したいなら、それは検証用ではなく退避用の環境になります。目的が「壊れたときにすぐ切り替える」ことなら、月数千円で用意するコールドスタンバイ環境の作り方のほうが目的に合います。
もうひとつ、テスト環境のログイン情報は本番と同一のまま作られることが多く、防壁はBasic認証だけという状態になりがちです。何かの事情でBasic認証を外すなら、テスト側のログイン情報を変えるところまでをセットにしてください。更新作業そのものを継続的に任せたい場合の範囲は保守プランのページに整理しています。
よくある質問
本番と同じサーバーにテスト環境を置くと、本番が重くなりませんか
テスト環境へのアクセスは自分たちだけなので、通常の運用で本番の表示速度に影響が出ることはまずありません。影響するのは、データベースのダンプ取得や大量のファイル転送を行っている最中です。数十GB規模のサイトであれば、アクセスの少ない時間帯に作業してください。容量については、同じサーバー契約の中でディスクを二重に使うことになる点だけ意識しておけば十分です。
検索エンジンに拾われないようにするには、どうすればいいですか
Basic認証をかけるのが最も確実です。管理画面の設定で「検索エンジンがサイトをインデックスしないようにする」にチェックを入れる方法もありますが、これはあくまで検索エンジン側への要請であり、強制力はありません。Basic認証であればアクセス自体を拒否できるので、内容が外に出る心配がなくなります。初期ドメインを使う構成なら、URLが本番と無関係になるという点でも安全側です。
テスト環境で確認したのに、本番だけ表示が崩れます
まずブラウザのキャッシュを疑ってください。それでも直らない場合は、キャッシュ系プラグインやサーバー側のキャッシュ機能が本番だけで有効になっていないかを確認します。テスト環境ではこれらを無効化していることが多いため、本番との差分になりやすい部分です。加えて、反映したファイルの版が正しいかも確認します。テストで作り込んだつもりのファイルが上がっていない、というのはよくある話です。
