既存アプリケーションのPHPバージョンを更新する作業は、コンテナイメージやサーバー設定を変更するだけではありません。ランタイムはコード、拡張機能、Composerライブラリ、スケジュール実行タスクやバックグラウンドジョブを動かすプロセスと相互に作用します。手動テストではアプリケーションが正常に動作しているように見えても、変更がそのいずれかに影響する可能性があります。
不確実性を減らすには、更新を互換性に関する変更として扱います。実行されるものを棚卸しし、非互換性を探し、代表的な経路を検証したうえで、デプロイを続行するかロールバックするかの判断方法をあらかじめ定めます。目的は、新しいランタイムに必要な作業を切り分けることであり、更新をプロダクトの全面的な書き換えに変えることではありません。
ランタイムはアプリケーションの互換性の一部
PHPのバージョンによって、インタープリターが受け付ける構文や、特定の関数・型の動作が決まります。また、インストール可能な拡張機能や依存関係のバージョンも左右します。そのため、現在の環境でコードが動作していたからといって、新しい環境でも動作するとは限りません。関数、インターフェース、型の挙動、拡張機能の利用可否が変わる可能性があります。
アプリケーションコード、サードパーティ依存関係、環境設定の3つを区別することが重要です。これらを同時に変更すると、障害の原因を特定しにくくなります。計画的な更新では、可能な限り変更を分け、各調整をどのコンポーネントが必要としたのか明確にします。
ランタイム、依存関係、プロセスを棚卸しする
変更を始める前に、プロジェクトの設定ファイルに記載された環境だけでなく、実際の実行環境を記録します。リクエストを処理するコンテナやサーバーだけでなく、スケジュール実行タスク、キューコンシューマー、保守コマンドを実行する環境のPHPバージョンも確認してください。これらのプロセスでは、異なるイメージ、環境変数、拡張機能が使われている場合があります。
- ランタイムと拡張機能: 有効な拡張機能と、該当する場合はそのバージョン、依存するシステムライブラリを特定します。本番、CI、開発環境の要件を比較してください。
- Composer依存関係:
composer.json、ロックファイル、パッケージが宣言するPHPのバージョン制約を確認します。静的解析ツールやテストランナーなどの開発ツールも確認してください。 - 設定:
php.iniの値、メモリ・実行時間の上限、エラー設定、サーバー固有の設定を棚卸しします。新しいランタイムにしただけで、関連する設定が引き継がれるとは限りません。 - Webリクエスト以外の処理: cron、キュー、コンソールコマンド、インポート、エクスポート、長時間実行タスクを含めます。Web経路が正常でも、これらのフローが検証されたことにはなりません。
- 連携とデータ: 外部サービス、やり取りするデータ形式、データベースやストレージへの書き込みを記録します。ロールバック時に特別な注意を要する操作の特定に役立ちます。
環境を比較し、差異を見つけられるなら、棚卸し結果はリポジトリ内のリストでも運用ドキュメントでも構いません。棚卸しが不十分な場合によく見られる兆候は、CIは通るのに、デプロイ後にworkerやスケジュール実行タスクが失敗することです。
複数の手がかりで非互換性を探す
まず、自動化ツールを使います。Composerのプラットフォーム制約を確認し、対象のPHPバージョンで依存関係のチェックを実行してください。依存関係の解決に失敗した場合、開発ツールを含むいずれかのパッケージが、そのプラットフォームとの互換性を宣言していないことを示します。どの要件を回避するのか理解しないまま、競合を隠すためにインストールを強行するべきではありません。
この分析に加えて、プロジェクトで利用できる静的解析ツールや、スタイル・互換性のテストも実行します。疑わしい使い方、非推奨API、見直すべきパターンを見つける手がかりにはなりますが、それだけでアプリケーション全体が動作する証明にはなりません。同様に、分析で問題が見つからなくても実際の実行に代わるものではありません。一般的でない分岐を通ったときや、拡張機能を読み込んだときにのみエラーが現れることがあります。
本番環境で想定するランタイムと拡張機能を使ってテストを実行します。テストスイートが限定的なら、認証、書き込み処理、該当する場合は決済、ドキュメント生成、重要な連携など、影響の大きいフローを手動または自動で確認します。エラーや警告も記録してください。警告が例外に変わる変更により、テストで検出される前に処理経路が中断する可能性があります。
リスクを切り分けられるよう作業を進める
実践的な順序として、まず候補となるイメージや設定と拡張機能を確認し、次に依存関係の制約を解決し、最後にテストの実行を妨げるコードや設定を修正します。変更の各グループはレビュー可能な状態に保ちます。ライブラリの更新が必要な場合は、変更を必要とする要件を記録し、そのライブラリを使うアプリケーションの領域をテストしてください。
同じ作業で依存関係を無差別にすべて更新するのは避けてください。広範な更新が必要な場合もありますが、リグレッションが発生したときの原因候補が増えます。分離できない場合は、変更したパッケージを記録し、それらに依存する機能を対象としたテストを追加します。また、ロックファイルがCIと本番環境で一貫して生成・インストールされることを確認してください。
設定は実際の移行先を反映する必要があります。CIだけにインストールされた拡張機能を使って検証すると、誤解を招く結果になります。バックグラウンドタスクが古いランタイムで動き続ける場合も同様です。結果をコードの影響と判断する前に、テスト環境と本番環境のイメージ、起動コマンド、環境変数、設定を比較してください。
本番を再現した環境で検証し、合否基準を定める
CIでは、現在のランタイムだけでなく対象のランタイムを使って、インストール、分析、テストを実行します。アプリケーションが複数のランタイムとの互換期間を維持する必要がある場合に限り、別のランタイム向けジョブを追加します。その場合、サポート対象の組み合わせをそれぞれ明示的に検証する必要があります。CIマトリックスでテスト対象の組み合わせは可視化できますが、本番環境固有の条件まで自動的に網羅されるわけではありません。
起動、重要な経路、連携、キュー、スケジュール実行タスクを確認できるよう、本番環境に十分近いステージング環境を使います。前後のログ、エラー、応答時間、リソース消費を確認してください。デプロイを中止すべき挙動、判断を下す担当者、システムを監視する期間を事前に定めます。しきい値は一般的な値ではなく、アプリケーションの要件と利用可能なシグナルに基づいて設定してください。
有用な合否基準には、再現可能なインストール、合意したテストスイートの成功、重要なフローの検証、説明できない新たなエラーがないこと、バックグラウンドプロセスを運用できることが含まれます。既知の例外と担当者も記録します。重要な連携がテスト対象外だったり、チームが監視すべきメトリクスを把握していなかったりするなら、「テストが通った」だけでは不十分です。
データと互換性のあるロールバックを備えてデプロイする
アーキテクチャとプラットフォームが許すなら、新しいランタイムへの切り替えは段階的に行います。まず制御された環境で、その後にトラフィックまたは実行能力の一部へ適用します。段階的な適用はデプロイ戦略であり、情報公開ではありません。状態を持つプロセスや内部プロトコルの差異などにより、バージョン間でリクエストを分散できない場合もあります。その場合は、連携した移行を計画し、メッセージのコンシューマーとプロデューサーを明示的に確認してください。
デプロイ前に、障害発生時に旧コードを再び実行できることを確認します。ロールバックはイメージを戻すだけではありません。データベースのマイグレーション、新しいメッセージ形式、互換性のない書き込みによって、新ランタイムが作成したデータを旧ランタイムが読み取れなくなる可能性があります。段階的な互換性を保つスキーマ変更を優先してください。まず拡張し、両方の形式と共存できるコードをデプロイし、不要になった形式を使うコンシューマーがいなくなってから旧形式を削除します。不可逆な各手順について、個別の復旧方法と停止判断を定めてください。
デプロイ中は、アプリケーションとランタイムのエラー、workerの失敗、キューの遅延、スケジュール実行タスク、業務上重要なシグナルを監視します。ロールバック基準に該当した場合は、変更の拡大を止め、検証済みの手順に従ってください。原因を特定するために必要なログを保持します。診断せずに戻すだけでは、次の試行で同じ障害が再発する可能性があります。
更新の準備が整っているか判断するチェックリスト
- すべての環境とプロセスで、ランタイムと拡張機能を特定できているか？
- Composerの制約と開発ツールを確認したか？
- 対象の設定で分析とテストを実行しているか？
- 重要な経路、連携、キュー、スケジュール実行タスクをテストしたか？
- CI、ステージング、本番環境の差異を把握しているか？
- 継続または停止の判断に使う運用シグナル、担当者、明確な基準があるか？
- 旧コードは、新コードが生成するデータやメッセージを処理できるか？
- ロールバックをリハーサルし、自動では元に戻せない変更を把握しているか？
チームがこれらの問いに証拠をもって答えられるなら、既存アプリケーションのPHPバージョン更新は、より確かな判断になります。テストや棚卸しが不足している場合、次の作業は全面的な書き換えである必要はありません。まず不足を埋め、変更の規模を小さくする方法もあります。そうすれば、潜在的な障害をユーザーに影響する前に検出でき、デプロイの各判断に検証可能な基準を設けられます。
