WordPress更新直前は機能追加を止めて変更と検証の責任を分ける

WordPressを更新する直前は、新しい機能や文言修正を重ねないほうが安全です。更新で起きた問題なのか、同時に入れたthemeやpluginの変更なのかを分けられなくなるからです。更新日を決めたら、必要でない変更を一度止め、更新と確認の担当を分けます。

WordPress 4.5 RC2の公式案内は、正式版を前にしてもthemeとpluginの互換性を試すよう求めています。WordPress本体では表示文言を追加しないstring freezeの段階に入り、正式版までに問題が残る可能性も示されています。

変更停止は、siteを一切触らないという意味ではありません。確認できない変更を、更新作業と同じ時間帯へ持ち込まないための区切りです。新しいcampaign用のpage、headerの見た目、pluginの設定、翻訳文の差し替えを同じ日に入れると、公開後に違いを見つけても戻す対象が増えます。更新の目的と無関係な変更を別日にするだけで、原因を追う時間を減らせます。

小さなsiteでは一人が更新、確認、問い合わせ対応を行うことがあります。その場合も、頭の中で同時に進めません。更新前に行うこと、更新の直後に行うこと、翌日に見直すことを紙やfileへ分けます。作業者が一人でも、変更を実行する役割と結果を見る役割を別の順番にすることで、見落としを減らせます。

更新と同じ日に別の変更を入れない

更新前後に起きやすい変更を、役割ごとに分けます。

たとえば、WordPressを更新した日にheaderのmenuも直すとします。表示が崩れたとき、themeの編集、pluginとの組み合わせ、WordPress本体のどれを確認すべきかが分かりません。急ぐほど、作業を小さく分けたほうが復旧は速くなります。

同じことは、pluginの更新にも当てはまります。WordPress本体の更新後にformが送れなくなったとしても、その日にform pluginの設定を替えていれば、どちらを戻すか判断しにくくなります。必要なsecurity updateや障害対応まで待たせる必要はありませんが、例外で入れた変更は通常の更新と別に記録します。何をいつ誰が変えたかが分からなければ、復旧は勘に頼る作業になります。

更新前のbackupも、fileを作っただけで終わりにしません。どの時点のdataとfileを保存したか、どこに置いたか、戻す作業を誰が行えるかを確認します。復旧する可能性があるのはWordPress本体だけではなく、theme、plugin、uploadした画像、databaseの内容です。問題が起きてから保存先を探すのでは遅いため、更新前に戻す対象をそろえます。

変更停止は仕事を止めることではない

変更を止める期間にも、公開前の確認と記録は進められます。止めるのは、確認対象を増やす変更です。問い合わせ内容の修正や障害対応のように、公開を待てない作業まで止める必要はありません。

更新前に、次の三つを決めます。

1. 更新対象のWordPress、theme、pluginのversionを記録する。
2. 更新当日に変更しないfile、設定、pageを決める。
3. 更新後に確認するURLと操作を決める。

この三つが決まれば、更新後に問題が出ても、誰が何を変えたかを追えます。担当者が一人の場合でも、更新する作業と確認する作業を別のchecklistにします。

確認するURLは、トップpageだけにしません。検索から直接開かれるservice page、記事、固定page、問い合わせpageのように、templateやpluginの影響が異なる場所を選びます。管理画面では、投稿の編集、画像upload、設定画面の保存など、本番で使う操作を通します。見た目が正常でも、保存や送信が失敗すれば、更新を完了と呼べません。

checklistには、正常なら何が起きるかも書きます。「formを確認する」だけでは、buttonを押すだけで終わる人と、完了画面まで見る人が出ます。たとえば問い合わせなら、入力欄が読める、必須項目の案内が出る、送信後に案内が表示される、受ける側へ届くかを順に決めます。どこまでをtest siteで確認し、どこからを本番で確認するかも分けます。

更新の開始と終了を周囲へ伝えるかも決めます。作業中に問い合わせが来るsiteなら、更新する人だけが状況を知っていても足りません。更新中の表示が利用者に見える可能性、連絡を受ける人、問題が出たときの判断者を決めます。技術的な更新と、siteを使う人への対応は別の仕事ですが、同じ日に影響します。

確認結果は成功だけで終わらせない

更新後に問題がなければ、確認したURLと操作を残します。問題があれば、表示だけでなく、発生した時刻、URL、操作順、browser、error messageを残します。後から別の人へ引き継ぐとき、更新したという事実だけでは直す場所が分からないためです。

正式版の公開予定が近くても、release candidateは正式版ではありません。test siteで確認することと、本番siteを更新することは別に扱います。本番更新は、backupと復旧方法を確認できる日に行います。

確認結果は、成功した項目と未確認の項目を分けて残します。たとえばトップと記事は見たが、mail送信はtest環境で確認していないなら、そのまま書きます。未確認の部分を「問題なし」に含めると、本番で問題が出たときに誰も想定していなかったことになります。確認範囲を狭く始めても、範囲が明らかなら次の担当者が続きから見られます。

問題が出たときは、直す前に再現条件を残します。URL、操作順、ログイン状態、画面幅、表示されたerror、更新したversionを記録します。急いでtheme fileを直して表示が戻ると、原因が更新だったのか修正だったのかが消えます。復旧を優先する場合でも、戻したものと直したものを分けて書きます。

変更停止の期間を長くしすぎる必要はありません。更新前後に確認できるだけの短い期間でよく、通常のcontent更新や業務を止めるためのルールではありません。大切なのは、更新の影響を見ている間に、別の差分を増やさないことです。例外として入れる作業があるなら、理由、影響範囲、確認する人を決めます。

最初に決める三つは、更新日に入れない変更、更新後に開くURL、異常が出たときの連絡先です。この三つを先に書けば、WordPressのversionを上げる作業を、原因の分からない画面修正へ広げずに済みます。

最初の一手は、次回のWordPress更新日に行わない変更を三つ決めることです。更新日に画面修正や機能追加を重ねなければ、確認すべき差分を小さくできます。