はじめに
こんにちは！オープンワークの室永です。最近、お酒の瓶の蓋の下部のリングでハートを作るのにはまっています（割と上手く作れるようになりました）。
当社では定期的に言語・フレームワークのバージョンアップを行っています。去年、2025年1月頃、OpenWorkのバージョンアップを行ったので実施内容などについての紹介をしようと思います（記事執筆が大変遅くなり反省です...）。
過去のバージョンアップについての記事は以下を御覧ください。
今回の対応内容
| 言語 | before | after |
|---|---|---|
| PHP | 8.1 | 8.3 |
| Symfony | 5.4 | 6.4 |
公式の移行ガイドに廃止機能や新機能についての説明などがあるので、バージョンアップ時には大変重宝します。
PHP
Symfony
- https://symfony.com/doc/6.4/setup/upgrade_major.html
- https://github.com/symfony/symfony/blob/6.4/UPGRADE-6.0.md
- https://github.com/symfony/symfony/blob/6.4/UPGRADE-6.1.md
- https://github.com/symfony/symfony/blob/6.4/UPGRADE-6.2.md
- https://github.com/symfony/symfony/blob/6.4/UPGRADE-6.3.md
- https://github.com/symfony/symfony/blob/6.4/UPGRADE-6.4.md
各種バージョンのサポート期間やEOL（End Of Life）や、ベースイメージで利用可能な言語のバージョンを事前把握しておくことも重要です。当社の場合は、バージョンアップに伴いAmazon Linux 2からAmazon Linux 2023に移行しました。
サポート期間
- https://www.php.net/supported-versions.php
- https://symfony.com/releases
- https://docs.aws.amazon.com/ja_jp/linux/al2023/ug/release-cadence.html
バージョンアップの進め方
バージョンアップ作業ですが、ざっくりと以下のような順序で進めました（同時並行で行っていた箇所もあります）。
- 前回バージョンアップでの暫定対応箇所の修正
- 現行の非推奨コード・ライブラリの洗い出し
- 現行の非推奨コード・ライブラリの修正
- バージョンアップ環境の作成
- バージョンアップ環境の検証
- 本番リリース
1. 前回バージョンアップでの暫定対応箇所の修正
前回バージョンアップではスケジュールが非常にタイトだったため、暫定対応で凌いだ箇所が残っていました。
影響範囲や使用箇所の非常に多い項目だったため、各プロジェクトに担当領域を依頼しつつバージョンアッププロジェクト主導で順次修正リリースしていきました（ここはバージョンアップ作業が本格開始する以前から徐々に潰していっていました）。
2. 現行の非推奨コード・ライブラリの洗い出し
いきなりバージョンを上げると大量のエラーが発生し原因の切り分けなどが困難になるため、現行バージョンで動作するが次バージョンで削除される機能（非推奨コード）を事前に洗い出しました。
非推奨コード検出について、過去執筆したものがあるので興味がある方は御覧ください。
ライブラリについては、一旦PHP8.3とSymfony6.4にバージョンアップしてみて、依存関係でインストールできなかったものや削除する必要があったものなどを洗い出しました。
3. 現行の非推奨コード・ライブラリの修正
洗い出した非推奨コードの置き換えや、古いライブラリの削除や代替を実施しました。この修正作業では、前述の公式の移行ガイドが役立ちました。
前回よりは比較的スケジュールに余裕があったため、先行リリース可能なものは先んじてリリースするようにしていました。
ログインやセッション周りの修正に関しては、ビジネス的に非常に影響が大きい箇所のため特に重点的に検証しました。
また、RectorというPHPやSymfonyのリファクタリングツールを使える箇所があったため、自動修正できる箇所はRectorにお任せしました。
4. バージョンアップ環境の作成
Amazon Linux2 → Amazon Linux2023に移行、PHP8.1 → 8.3にバージョンアップ、テストコードがすべて通るようにする。
その後、Symfony5.4 → 6.4にバージョンアップ、テストコードがすべて通るようにする、と切り分けをすることで、問題があった際の調査などを簡易化しました。
このタイミングで新規で非推奨となったコードの削除、新機能の導入などができると良かったのですが、スケジュールの問題で見送りました。
以前執筆した以下の記事を貼って供養しておくこととします。
5. バージョンアップ環境の検証
テストコードをすべて通し、ざっと主要画面の結合テストを実施した後、ホワイトボックステストと負荷検証を進めました。
ホワイトボックステストは他プロジェクトに担当領域の機能を割り振り検証依頼をしました。
目安程度ではありますがアクセス数やカバレッジなどをスプレッドシートに記載し、重要度や優先度判断の参考にしていただきました。
負荷検証では、Grafana Cloud k6にてアクセス負荷を擬似的に再現し、パフォーマンス劣化していないかの確認をしました。
6. 本番リリース
リリース当日は、不測の事態に備えて切り戻し手順を策定した上で臨みました。
（前日まで通っていたdeptracが落ちたりといったトラブルに肝を冷やしつつも）無事リリースすることができました。
振り返り
以下、今回のバージョンアップを通して継続したい点と上手く行かなった点です。
良かった点
要修正箇所の先行リリース
要修正箇所や廃止ライブラリ修正を順次先行リリースしたりすることで、バージョンアップ当日の影響範囲や修正規模を抑えることができました。検証時のエラー修正なども少なかった印象です。
結果、特段大きな不具合などなく、無事リリースすることができました。
ブルーグリーンデプロイの有効化
インフラエンジニアの方にブルーグリーンデプロイを有効化していただきました。
結果として切り戻しすることはなかったとはいえ、即時切り戻し可能という安心感が非常に大きかったです。
非推奨コードの周知
バージョンアップ前と後での非推奨コードについての共有や勉強会などを実施することで、新しく非推奨コードがコードベースに混入することを防ぎました。
とはいえ知識依存ではなく、GitHub ActionsのPHPStanなどを用いてルールベースで仕組み化できると更に良かったと思います。
反省点
バージョンアップ前後比較ツール
バージョンアップ前後でのデグレーション検知のため、過去作成されていたHTML/RDBの前後状態の比較ツールをブラッシュアップしました。
ただ、flaky由来で結果が安定しない、冪等でない表示要素を誤検出したりと期待した通りに上手く活用できませんでした。
検知できなかった残骸が残ってしまった
切り戻す必要のある大きな不具合はなかったですが、バージョンアップ完了後に不要なスキーマ差分や大量の不要ログが発生していました。
何かしらこのあたりを検知できる仕組みを作り、次回以降の資産にできると良いと思いました。
パフォーマンス検証
検証初期、バージョンアップ後環境でパフォーマンス劣化があったように見えたのですが、検証環境のスペック不足が原因でした。低いスペックではオーバーヘッドなどの影響で劣化して見えましたが、本番相当のスペックでは逆にパフォーマンスが向上することを確認できました。
結果として問題なかったものの、原因追求の追加検証に金銭的、時間的コストを使ってしまいました。
その他
今であれば、AIエージェントに思い付いた使い捨てツールの作成やブラッシュアップ、非推奨コードの修正やテストコード修正などを任せたり、進め方などで改善できる箇所も多いと思います。
次回以降のバージョンアップでは更に積極活用していきたいですね。
最後に
当社ではバージョンアップは定期的に実施されていますが、過去の知見や反省を活かしつつより良い方法などを模索しています。
この記事を読んで少しでもオープンワークに興味を持っていただけたら採用サイトを覗いていただけると嬉しいです！
