見出し画像

CakePHP 2.x のプロジェクトを Laravel にリプレースした

はじめに

こんにちは、 Zaim でサーバーサイドを担当している naoki85 です。
Zaim は 10 年の歴史があるサービスで、管理しているアプリケーションの中には、PHP のフレームワークである CakePHP で作成、運用していたものもありました。

この度、CakePHP 2 系のサポートが終了したことに伴い、Laravel への移行を実施しました。
今回のリプレースでは、特に以下の点を改善したいと考えていました。

・PHP 系リンターの導入
・テストの拡充
・インフラ構成の改善

本記事では、この 3 点について記載します。

そもそも Laravel を採用した理由

CakePHP の後継プロジェクトとして、 PHP を選択することは自然な流れでした。
当初、 CakePHP 3 系または 4 系へのアップデートを考えていましたが、大部分の書き換えが必要であるため、作業する負荷としては他のフレームワークを選択した場合と大きく変わらないと予想しました。

Laravel は、PHP フレームワークの中ではかなり評判の良いフレームワークです。
私自身は触ったことがありませんでしたが、一昨年の PHP カンファレンスで興味が湧き、「Laravel でやらせてほしい」と意見して決まりました。

PHP 系リンターの導入

Zaim では多くのプロジェクトで Danger という Ruby 製のコード自動チェックツールを使用しています。

このツールでは独自でルールを追加できるので、社内における Pull Request のルールに合致しているかや、不要なループ処理など非推奨なコードが含まれていないかといった確認に使っています。

このような独自ルールの校正チェックはあったものの、リプレース対象としたプロジェクトでは、PHP 関連のリンターは入っていませんでした。

今回、この Danger にて PHPMDPHPStanLarastan)といったメジャーなライブラリも実行するよう修正し、コードの統一化をはかりました。

ちなみに、Zaim の @ktakayama が PHPMD の Danger プラグインを作成したので、よろしければ使ってみてください。

テストの拡充

リプレース対象のプロジェクトでは、テストが不十分でした。
特に計算処理だったり、複数の処理をまとめたりしている場合、一見しただけではコードを理解できないことが多々あります。
テストコードがあれば、計算処理に手を加えたり、この処理がどういった値を期待しているかを判断したりが容易になると考え、テストを追加するよう推奨しました。

責務を分けるため、リポジトリ層とサービス層も導入しました。リポジトリはデータソースとのやり取り、サービスにはロジックを記載し、それぞれでテストを書きます。

リポジトリとサービスの棲み分けはどうするのか、似たようなテストが重複してしまう、といった意見もありましたが、都度ルールを決めて進めました。

なお、E2E テストを導入する場合は、Laravel の Dusk を使いました。

インフラ構成の見直し

Zaim のアプリケーションは Kubernetes 上でコンテナを管理・運用しています。
今までの CakePHP の構成では nginx も静的ファイルもすべて一つのコンテナの中にありましたが、本来であればこれらは役割ごとに分割すべきでした。

画像1

今回、Zaim のインフラチームと相談し、以下のように変更しました。
静的ファイルは Laravel-mix を使用して、S3 にアップロードし、CloudFront を使い配信します。
また、nginx と PHP を別コンテナにして責務を分けました。

画像2

ちなみに ALB を前段に配置しておくと、例えば「特定のページだけ新しい Laravel の方で公開する」といった段階リリースが選べるので、移行が非常に楽になります。

さいごに

Laravel にはフレームワークとして多彩な機能があるため、まだまだ今のアプリケーションを改善できる余地があると考えています。
より効率的な処理フローや安定したアプリケーション運用を目指していますので、Zaim の Laravel 環境の推進に興味がある方、ぜひお気軽に話を聞きに来てください!


いいなと思ったら応援しよう!