Laravelグレードアップ に躓いた前職での小話

Transcript

1. 2026.3.7 CAMPFIREグループ Livefor株式会社開発室 須藤 拓也 Laravelグレードアップ に躓いた前職での小話
2. 自己紹介 須藤 拓也 / Takuya Sudo Livefor株式会社（CAMPFIREのグループ会社） - 北海道室蘭市出身 - モバイルアプリ開発が主戦場（iOS開発は3GSの頃からスタート） - 現在はFlutter, SAM, Svelte, AWSでアプリ開発 - 最近の興味は量子コンピューター - 今年から結婚を機にやめていたキックボクシング（ムエタイ）を再開 - 肩書はアマチュアソフトクリーマー（自称） https://github.com/someone-said-so
3. 話すこと 1. そもそも前職の話なので結構記憶が曖昧、、 2. 前職で経験したプロジェクト 3. Laravelグレードアップ 4. パッケージの制約 5. 結局どうなったのか 6. まとめ 全部前職当時の話です。 3年前の話なので記憶が曖昧で、退職しちゃった ので現状確認手段がありません。 面白半分で聞いてください 🙇🙇
4. 先日のSEB Summitの休憩時間に食べたソフトクリーム - よつ葉のソフトクリームミックス - Nisseiのサーブマシーン - 北の森珈琲店 - なぜかハングルを話す客が大勢いた
5. プロジェクトの概要 - 退職しちゃったのですごいボカします - ある道内メディア業界向けのアプリ - クーポン表示 - ニュースのプッシュ通信配信 - クラウド環境はAzure - 2022年当時、Laravel 6.x/PHP 7.2 - 2021年稼働開始の割に古い - 当時のBE担当者が退職済み - まもなくEOLを迎えていた - 軽い気持ちでメンテ引き受け やる人いないからお願 い！ ラジャー (CakePHP経験したし 大丈夫っしょ！)
6. グレードアップの手順 「Laravel6.x -> 10.x / PHP7.2 -> 8.2 への移行をゴールに据える」 1. Laravel10.xの機能要件はPHP8.1↑ 2. PHP8.1からenumがサポートされる 3. まずはPHPからアップしてその後Laravelをあげる 4. 最後に新しい言語仕様やライブラリ仕様に基づくコードを修正する - UnitTestのFactoryの書き方も結構変わる この手順でおそらくいける でしょう
7. ところが、、、 - 現行のプロジェクトでは laravel-enum がインストールされていた - ↑がLavavel10.xに対する互換性がないことが判明 - これ以外にも幾つかで互換性が問題があるパッケージが発覚 「PHPはLaravelの制約であげられない」 「逆で然りでLaravelもPHP verの機能要件であげられない」 「サクッとアップデートして破壊的変更箇所のコードを直し、いくつか のコードを現代風に書き直せばいい」 それだけだと思ってたのに、、
8. 「急がば回れ」戦略に切り替え 1. Laravel7.xにあげる 2. 破壊的変更の箇所やLaravel7.xで導入されたコードスタイルに修正 3. 許される範囲でPHPをバージョンアップし、テストグリーンになるまで修正 4. …これを繰り返しテストケースを増やしながら... 5. PHP8.1まで上がったら laravel-enum をアンインストールしてenumに書き換える 6. 同じように下位互換性のないパッケージを別のパッケージにする 7. そうして一歩ずつ着実に進めて無事にゴールまで到達！ Yeahhh!!!
9. その他にも - Azure AppServiceのCentOSサポート終了に向けた対応 - AppServiceがRuntimeがApacheからNginxに変更 - .htaccessが使えないので、nginx + php-fpmの設定 - FE/BEを完全分離 - laravel-mixで/bladeの下にあったreactのプロジェクトを完全に分離して独立でローカルホスト起動でき るにする - Dockerfileを整備 - FE/BEに伴い別のコンテナ / mysqlのデータベースを永続化 / 各サービスの仮想環境導入 (e.g. azurite) - コスト削減 - 管理画面用にVMを1つ起動していたが、運営・開発側しかアクセスしないので Blob Storageのホスティ ングに切り替える（管理画面は SPA）
10. まとめと教訓 - 結果、当初の計画より時間がかかってしまった - ただしランニング・メンテナンスコストが低減できた - プロジェクト作成時にはできるだけその時の最新版で作る - enumのような拡張が予想される言語機能はフレームワークのパッケージではなく PHPのパッケージだったらもっと楽だったかも - https://github.com/paillechat/php-enum とか - FE/BEやゲートウェイなどは独立して動くと開発しやすい - グレードアップやリファクタの時はテストがあると安心感が全然違う - EOLは現状の構成を見直すいい機会 「こうしたらよかった」の意見は後出しジャンケン。経緯は知りませんが、このプロジェ クトに関わった人はその当時のリソースの制限の中で努力したはず。むしろ反省を 「ヒト」ではなく「コト」と捉えてそれを原動力に常によくする努力することができる開発 文化こそが一番。
11. ご清聴 ありがとうございました