WordPressのデプロイで変わるのは、リリースのファイルだけとは限りません。プラグインの更新や独自開発によって、テーブルの作成、オプションの変更、レコードの変換、既存データの解釈方法の変更が行われることもあります。コードとデータベースの状態に互換性がなくなると、ファイルのコピーが完了しているように見えても、サイトが動作しなくなるおそれがあります。
データベース変更を伴うWordPressデプロイでは、変更ごとに影響と可逆性を考慮する必要があります。目的はコードを公開することだけではありません。移行を制御し、重要なフローを確認し、新バージョンが想定どおりに動作しない場合の対応を明確にすることです。
ファイルを戻してもサイトが復旧するとは限らない理由
コードはデータベースに対する処理を実行しますが、データベースの現在の状態を必ずしも保持しているわけではありません。新バージョンがテーブルを作成したり、値の形式を変更したりした場合、以前のファイルに戻しても、その変更は取り消されません。古いコードが新しいスキーマを認識できない場合や、旧バージョンで処理できないデータがサイトに追加されている場合があります。
逆に、新しいファイルを残したまま古いデータベースを復元すると、システムの状態に不整合が生じることもあります。たとえばWooCommerceでは、デプロイ中やデプロイ後も注文などの運用データが更新され続ける場合があります。以前のデータベースバックアップを復元すると、バックアップ取得後に行われた正当な操作が失われるおそれがあります。
そのため、以前のバージョンのファイルに戻すコードのロールバック、特定の変更を修正するデータ修復、バックアップから状態を復元するリストアを区別しましょう。これらは同じ操作ではなく、コストや影響も異なります。
公開前に変更内容と依存関係を棚卸しする
デプロイ前に、何がどこで変更されるかを記録します。次の4つに分けると整理しやすくなります。
- コード：テーマ、プラグイン、独自コード、定期実行タスク、依存関係。
- スキーマ：作成、変更、削除されるテーブル、カラム、インデックスなどの構造。
- データ：挿入、更新、変換、削除されるレコード。オプションやメタデータも含みます。
- 設定とコンテンツ：環境ごとの値、認証情報、ルール、ページ、管理画面から設定する項目。
各マイグレーションの実行者、実行時点、再実行しても安全かどうかを記録します。プラグインの更新時に自動実行されるのか、コマンド、手動タスク、管理操作が必要なのかも確認してください。さらに、新しい構造を必要とするコードのバージョンや、影響を受けるテーブルに書き込む処理など、依存関係を特定します。
WordPressでは、一部の設定がデータベースに保存され、本番環境とテスト環境で異なる場合があります。データベースを環境間でコピーしても問題ないと決めつけないでください。また、シリアライズされたデータやオプションとして保存されたデータは、無差別な文字列置換ではなく、形式に適合した変換が必要になることがあります。
互換性を保ちながら段階的に進める
変更内容が許す場合は、Expand and Contract（拡張・縮小）戦略を使います。まず現行バージョンと互換性のある構造を追加し、次に旧状態と新状態の両方で動作するコードをデプロイします。その後データを移行し、結果を検証します。新バージョンの安定を確認してから、不要になった古いカラム、経路、構造を削除します。
この手順により、ファイルをロールバックした結果、旧コードが必要とする構造が失われるリスクを抑えられます。ただし、すべての変更に適用できるわけではありません。破壊的な変換や互換性のない変更では、メンテナンス時間の確保、書き込みの停止、プラグイン提供元が指定する手順が必要になる場合があります。判断は、処理内容、データ量、見込み所要時間、サービスを維持できる能力に基づいて行います。
チェックポイントなしに、コード変更、マイグレーション、取り消し不能な削除を1つの処理にまとめるのは避けてください。処理に時間がかかったり途中で失敗したりしても、どの手順まで完了したかを把握できる必要があります。安全に再開する方法、二重実行の防止方法、続行を承認する担当者を決めておきましょう。段階的なデプロイでは、同時に稼働する各バージョンが共有データベース上で動作できることを確認します。
本番環境を適切に再現した環境でテストする
テスト環境が役立つのは、PHPとWordPressのバージョン、プラグイン、連携、設定、データの種類など、関連する条件を再現できる場合です。実データをすべてコピーする必要はありませんが、影響を受ける経路をテストできる必要があります。本番データを使う場合は個人情報を保護し、アクセスを制限してください。コピーしたデータにも、元データと同じ注意を払う必要があります。
マイグレーションをリハーサルし、妥当な量のデータで所要時間を測定します。処理が中断された場合の挙動と、レコードの重複や情報の欠落なしに再実行できるかを確認してください。その後、少なくとも影響を受けるデータの読み書きと、該当する業務フロー（購入、決済、確認、注文管理、外部システムとの同期など）を検証します。
互換性、権限、定期実行タスク、連携エラーのテストも含めてください。トップページが表示されても、購入フローが機能する証明にはなりません。テスト環境で連携を再現できない場合は、代替の確認方法と公開後の実施担当者を決めておきましょう。
デプロイ後に確認する項目を定める
開始前に、デプロイ成功の条件と監視期間を定めます。確認項目は、サーバーが応答するかどうかだけではなく、特定したリスクに対応するものでなければなりません。たとえば次の項目が挙げられます。
- PHPエラー、アプリケーションログ、定期実行タスクの失敗。
- マイグレーション結果：想定した構造、対象レコードの件数や整合性。
- 読み書き処理と重要なフローの実行結果。
- 決済、webhook、同期など、関連する連携の状態。
- その状況で想定される動作と比較した、通常のビジネス指標。
これらの項目を確認する担当者を割り当て、一時停止やロールバックの基準値を設定します。エラーが増えた場合は、まずアプリケーション、連携、データのどこに影響しているかを特定してください。対応手順のないアラートだけでは、リスクを管理できません。
復旧を準備し、実施を承認するか判断する
計画では、安全にロールバックできるものと、修復やリストアが必要なものを明示します。バックアップが存在し、復元可能であることを確認してください。復元を試していないバックアップは、運用上の保証にはなりません。復旧ポイントと手順上の依存関係、バックアップ取得後の正当な変更を破棄する影響を定めます。稼働中のストアでは、作業中に受け付けた注文や操作をどう保持するかも検討してください。
公開前に、判断する人、実行する人、検証する人を合意しておきます。マイグレーションのリハーサルが済み、依存関係が特定され、確認項目に担当者が割り当てられ、復旧が実行可能な場合に限り、デプロイを承認してください。バージョン間の互換性に疑問がある場合、重要なテストに失敗した場合、または進行中の処理を保護できない場合は、一時停止します。互換性の回復にコードのロールバックだけで足りるならコードを戻し、問題の範囲が限定されるならデータを修復します。リストアは、後続のどの変更が失われるかを把握したうえでのみ実施してください。
公開前チェックリスト：棚卸しの完了、バックアップの検証、手順と実施時間の確定、テストの合格、確認項目と担当者の割り当て、続行・一時停止・復旧の明確な基準。この規律によって、データベース変更を、古いファイルに戻せば十分だろうという賭けではなく、制御された作業にできます。
