ストアの更新は、メンテナンスボタンを押すことと同義ではありません。WordPressコア、WooCommerce、拡張機能、テーマ、独自コード、連携は、依存関係を持つシステムを構成します。一見小さな変更でも、税計算を変えたり、決済を妨げたり、webhookを重複させたり、在庫同期タスクを停止させたりする可能性があります。
そのため、WordPressとWooCommerceを安全に更新するには、各作業枠を運用変更として扱う必要があります。何が変わるのか、どの業務フローが影響を受け得るのか、誰が判断するのか、検証に失敗した場合にどう機能する状態へ復旧するのかを把握します。
変更前にインベントリを作成する
インベントリは、運用を支える実際の構成を記述し、開始時点を再現できるものでなければなりません。現行バージョンと目標バージョン、各コンポーネントの入手元、責任者、変更理由を記録します。
- プラットフォーム：PHP、Webサーバー、データベース、WordPress、WooCommerceのバージョン、および関連するキャッシュ設定。
- 拡張機能：有効・無効のプラグイン。特に決済、配送、税、サブスクリプション、予約、請求、セキュリティ、パフォーマンスに関するもの。
- 表示：有効テーマ、子テーマ、オーバーライドされたWooCommerceテンプレート、カスタマイザーまたはビジュアルビルダーによるカスタマイズ。
- 独自コード：社内プラグイン、snippet、mu-plugin、コマンド、連携。直接変更は特定・文書化し、可能な場合は保守可能なコードへ移し、変更前にその影響を個別に評価します。
- 外部システム：決済ゲートウェイ、ERP、CRM、物流、メール、検索エンジン、分析、カタログAPI。
- 非同期プロセス：cron、アクションキュー、インポート、エクスポート、feed、webhook。
依存関係マトリクスを追加します。決済ゲートウェイは、プロバイダーのAPI、checkoutのフィールド、独自の不正利用ルールに依存することがあります。失敗時の影響は見た目にとどまらず、収益を止めたり、誤ったステータスの注文を作成したりする可能性があります。
リスクを分類し、範囲を定義する
すべての変更に同じ手順が必要なわけではありません。各更新を、コンポーネントの重要度、宣言された互換性、注文への影響、ロールバックの容易さで評価します。
- 高リスク：コア、WooCommerce、決済ゲートウェイ、checkout、税、サブスクリプション、在庫同期、データ移行、PHPの変更。
- 中リスク：テーマ、ページビルダー、配送、プロモーション、検索、キャッシュ、重要ではない連携。
- 低リスク：管理画面の個別調整、または購入フロー外の拡張機能。ただし、機微な依存関係を共有しない場合に限ります。
可逆性には独自の評価が必要です。拡張機能の無効化は容易な場合がありますが、テーブルを作成したりメタデータを変換したりする移行は、古いファイルを復元しても必ずしも元に戻りません。変更するデータと、以前の状態を復旧する方法を特定します。
原因を切り分けるために作業枠の範囲を限定しますが、既定で固定の順序を適用してはいけません。インフラストラクチャ、PHP、WordPress、WooCommerce、拡張機能、テーマの順序は、互換性マトリクスと各コンポーネントの更新ノートに基づいて決定する必要があります。組み合わせによっては、先に依存関係の更新が必要です。また、特定バージョンを一時的に維持することや、文書化された順序で移行を実行することが必要な場合もあります。互換性が確認されたコンポーネントだけをグループ化し、各グループの後に検証します。
代表性のある環境で重要フローを再現する
有用なテスト環境は、PHP、データベース、WordPress設定、有効な拡張機能、テーマ、キャッシュ、cron、連携の非機密設定など、挙動に影響する要素について本番環境に似ています。代表性を持たせるために個人データをコピーする必要はありません。
匿名化データまたは合成データを使用し、プロバイダーが提供する場合は、認証情報、キー、機微な宛先をテスト設定に置き換えます。制御のないクローンは、実際のメール、請求書、webhook、通知を送信する可能性があります。
業務を観測可能なケースに変換する
テストはトップページが読み込まれることを確認して終えてはいけません。初期条件、手順、期待結果、証跡を含むフローを定義します。実際の販売ルールを反映するバリエーションを優先します。
- カテゴリーを閲覧し、商品を検索し、バリエーション、価格、割引、税が正しい商品詳細を開く。
- カートに商品を追加、変更、削除し、クーポンを適用してプロモーションまたは配送しきい値を確認する。
- 各プロバイダーが認可した仕組みを用い、関連する各決済ゲートウェイ、配送方法、顧客タイプでcheckoutを完了する。
- 注文の作成とステータス、在庫の減少または引当、帳票、トランザクション通知を確認する。
- 運用に含まれる場合は、キャンセル、返金、返品を処理する。
- 外部同期を確認し、webhookが重複も滞留もしていないことを確認する。
PHPエラー、WordPressとWooCommerceのログ、保留中または失敗したスケジュール済みアクション、APIレスポンス、重要ページの応答時間、キャッシュといった技術テストを含めます。ストアは注文を受け付けながら、そのERPへの送信が静かに失敗していることがあります。個別の画面よりも、フロー全体が重要です。
制御とトレーサビリティを伴ってデプロイを実行する
デプロイは変更を本番環境へ移し、releaseはその機能をユーザーが利用可能な状態にします。両者は一致することもありますが、機能が段階的な有効化を許容する場合には、この二つの判断を分けることが役立ちます。
開始前に作業枠を告知し、変更の実行者と、進行または停止を承認する者を指名します。ファイルとデータベースのコピーを作成しますが、完全であり、復旧可能であり、制御された環境で復元できることを確認するまでは、ロールバック計画と見なしてはいけません。
時刻、コンポーネント、旧バージョンと新バージョン、実施したアクション、各検証の結果を記録します。変更が決済または注文データに影響する場合、不整合を悪化させ得る自動プロセスの一時停止を検討します。ただし、再開方法と保留分の照合方法を把握している場合に限ります。
各ブロックの後に、必須ページ、カート、テストcheckout、管理画面、注文作成、ログについてスモークテストを実行します。その後も、注文、エラー、キュー、webhook、決済プロバイダーのアラートを重点的に監視します。
顧客に影響を与えずに非互換性を検出する
非互換性が必ずしも白紙画面として現れるわけではありません。フィールドの欠落、古いテンプレート、誤った計算、重複プロセス、廃止予定機能の警告として現れることがあります。テーマによってオーバーライドされたテンプレートをWooCommerceが想定するものと比較し、互換性警告を確認します。ただし、それらがテストの代わりになると考えてはいけません。
障害時には、変更を追加してはいけません。再現することを確認し、エラー時刻周辺のログを確認し、最後に変更したコンポーネントを特定し、テスト環境で結果を照合します。本番環境で無差別に拡張機能を無効化すると、問題を隠し、必要な機能を取り除く可能性があります。
問うべきなのは、更新が互換性を持つように見えるかではなく、注文を生成、処理、通知するフローが期待どおりの結果を引き続き出すかどうかです。
脆弱なカスタマイズは、hooks、内部構造、文書化されていないフィールド、または以前にコピーされたテンプレートに依存しがちです。配送可否や注文検証のような重要な業務ルールは、snippet、プラグインオプション、テーマ変更に分散させるよりも、テストと明確な責任者を備えた、バージョン管理された独自コードとして実装する方が保守しやすくなります。
進行、延期、ロールバックを判断する
作業枠を開く前に基準を定義します。重要テストに合格し、関連する新規エラーがなく、キューが機能し、連携が期待どおり応答する場合に進めます。checkout、決済、注文作成、在庫、重要な通知が失敗した場合、または理解されていないデータ移行が現れた場合は、変更を停止します。
ロールバックは意図ではなく、運用です。復元ポイント、責任者、診断の最大時間、社内連絡チャネルを定めます。インシデント中に注文が作成された場合、古いコピーの復元によって有効な情報が削除される可能性があります。照合が必要となる注文、決済、返金、同期をあらかじめ特定します。
再利用可能なチェックリスト
- インベントリ、互換性マトリクス、更新ノート、リスクが文書化されている。
- 代表性のあるテスト環境があり、不要な機微データなしで重要ケースが実行されている。
- 検証可能なコピーがあり、復元手順が把握されている。
- 責任者、作業枠、進行基準、停止条件が合意されている。
- 互換性のあるグループごとに更新し、バージョンと結果を記録している。
- スモークテストと、ログ、注文、キュー、webhook、決済の監視を行っている。
- 影響を受けた取引または同期に備え、照合計画が準備されている。
このプロトコルは、拡張可能なエコシステムの不確実性を排除するものではありません。しかし、それを観測可能で可逆的な判断に変えます。目的は、顧客をテストチームとして使うことなく、ストアを安全かつ進化可能な状態に保つことです。
