WordPressのrelease candidateはthemeとpluginを本番と同じ組み合わせで確認する

WordPressのrelease candidateを試すなら、本番と同じthemeとpluginの組み合わせをtest siteへ置きます。WordPress本体だけを新しくしても、実際のsiteで問題になる組み合わせは見つかりません。更新候補を試すことと、公開siteへ入れることは別です。

WordPress 4.5 Release Candidateの公式案内は、release candidateが公開されたこと、正式版までに問題が残っている可能性があることを説明しています。themeとpluginの開発者へは、4.5に対するcompatibility testを求めています。

test siteを用意する目的は、本番と同じ外見を眺めることだけではありません。管理画面で投稿を保存する、画像をuploadする、formを送る、検索や一覧を開くといった操作が、組み合わせを替えた後にも続けられるかを確かめます。本番にあるthemeとpluginの名前だけをまねても、設定やcontentが違えば、実際に使うtemplateまで通りません。

一方で、本番のdataや外部送信をそのまま複製することも避けます。本番の問い合わせ先へtest mailを送ったり、test閲覧を通常の解析へ混ぜたりすれば、確認のために運用dataを汚します。本番を再現する範囲と、切り離す範囲を同時に決めます。themeとpluginは近づけ、mail、広告、決済、解析などの外部へ出る設定は安全に扱える状態へ変えます。

本番と違うtest siteでは確認範囲が狭い

広告tagやmail送信先まで本番と同じにする必要はありません。testから本番の問い合わせや計測へ影響を出さないように分けます。確認したい構成と、外部へ送ってはいけない情報を分けることが必要です。

本番siteをコピーするときは、利用者の情報を含むdataの扱いも確認します。testする人だけが見られる場所に置くのか、実在の利用者情報を含まないdataへ置き換えるのか、確認後にどのように片付けるのかを決めます。release candidateの動作を見るために、必要以上の情報を広げる必要はありません。制作担当へ渡す範囲も、本番dataの全量ではなく、再現に必要なものへ絞ります。

cacheを使うsiteでは、更新後に古いHTMLやCSSが残っていないかも見ます。管理画面では新しい設定に見えても、公開側では以前のassetが出ていることがあります。cacheを消すこと自体が確認の目的ではなく、更新後の表示を誰がどの状態で見たかをそろえるために行います。本番とtestでcacheの設定が異なる場合は、違いを記録しておきます。

代表操作を決めてから更新する

1. 本番のWordPress version、theme、pluginを記録する。
2. 本番と同じ組み合わせをtest siteへ置く。
3. release candidateへ更新する前に、代表pageと代表操作を決める。
4. 更新後にトップ、記事、固定page、form、投稿画面を確認する。
5. 問題があればURL、操作、表示、errorを記録して再現できるようにする。

themeやpluginを複数使うsiteでは、すべての設定を一度に変えません。問題が見つかったとき、WordPress本体、theme、plugin、設定のどれが関係するか分けて確かめます。

代表操作は、pageを開くだけでは足りません。問い合わせformなら、入力、確認、送信後の案内まで進みます。投稿なら、下書き保存、公開前のpreview、公開後の個別pageまで見ます。画像なら、upload、本文への挿入、一覧での見え方を確認します。siteごとに毎日使う操作は違うため、一般的なchecklistをそのまま流用せず、本番で止まると困る操作を選びます。

画面の崩れを見つけた場合は、スクリーンshotだけで終えません。どのURLを開いたか、どの画面幅か、ログインしていたか、どの順に操作したかを残します。errorが出たなら、その文言と時刻も書きます。themeのCSSを直した直後にpluginを止めて表示が戻ったとしても、原因がthemeだけとは限りません。変えたものを一つずつ戻せるようにして、再現する条件を探します。

問題が見つからなかった場合も、確認した範囲を記録します。「大丈夫だった」だけでは、どのpage、どのform、どの管理操作を見たのかが残りません。トップ、投稿、固定page、検索、404のようにsiteで重要な入口を列挙し、確認した日と担当を残します。確認していない機能まで問題がないと判断しないためです。

release candidateを正式版と同じに扱わない

release candidateは、正式版に近い状態で確認する機会です。正式版の公開時刻や仕様を保証するものではありません。testで問題がなければ、正式版が出たあとも更新前のbackupと公開後の確認を省かずに行います。

release candidateでthemeやpluginが動いたことは、正式版の更新手順まで自動で決めるものではありません。更新する人、backupを確認する人、公開後の問い合わせを受ける人が別なら、担当と順序を先にそろえます。更新中にsiteを見られない時間があるなら、利用者への案内も決めます。技術的な確認と、公開siteをどう運用するかを一つの判断にしないことが大切です。

正式版へ更新する日は、testの記録を見て、何をもう一度確認するかを決めます。release candidateで確認した投稿、画像、formを、正式版でも同じ順に見ます。本番ではmailや外部serviceを切り離せないため、送信先や計測へ影響がないかをより慎重に確認します。更新を急ぐ事情があっても、問題が出たときに戻る手順を持たないまま進めません。

最初に作るのは長い試験表ではなく、本番で止められない三つの操作です。それぞれについて、正常なら何が表示されるか、失敗なら誰が判断するか、記録をどこへ残すかを書きます。release candidateを試す作業は、WordPressの新機能を先に使うためではなく、正式版の更新で業務を止めないために行います。

最初の一手は、本番siteで欠かせない操作を三つ選ぶことです。たとえば問い合わせ、記事閲覧、管理画面からの投稿です。その三つをrelease candidateのtest siteで同じ順に試します。