コネヒト開発者ブログ

コネヒト開発者ブログ

既存プロダクトのCakePHPのアップグレード戦略

既存プロダクトのCakePHPのアップグレード戦略

こんにちは。サーバーサイドエンジニアをやっている西中です。

花粉症に悩まされているので最近空気清浄機を購入しました。こころなしか症状が緩和している気がしています。

前回はCakePHP4.3にアップグレードする際に躓きがちなphpunitの変更ポイントをいくつか紹介させていただきました。

実はこのCakePHPのアップグレード対応は段階的に行っていました。

CakePHP段階的なアップグレード対応

私が携わっているこのプロダクトは2018年11月にリリースされました。 リリースした時点ではCakePHPのバージョンは3.6でした。

いきなりCakePHP3.xからCakePHP4に上げてしまうとアップグレード対応の差分が大きくなってしまい、対応に時間がかかってしまうという問題があるため、段階的にアップグレード対応しようという判断になりました。

少し話が逸れてしまいますが、弊社では各開発チームごとにスクラムを組んでアジャイル開発を行っています。アジャイル開発と言っても実際の運用はチームごとに異なりますが、当プロダクトでは1スプリントの中で何度もリリースすることがあります。

f:id:satoshie:20220323174103p:plain:w300
GitHubフローにおけるブランチ開発

また、弊社ではGitHubフローに沿って開発を行っています。 このアップグレード対応という「保守対応」と、アウトカムを支えるための「施策運用対応」を並行で進めることになるため、ブランチ運用としてはアップグレード対応用のFeatureブランチとそれぞれの試作用のFeatureブランチが必要になってきます。

施策運用対応のためのブランチは都度都度mainブランチにマージされていくため、保守対応のためのブランチとの差分が増えていき、定期的にmainブランチを取り込みアップグレード版に合わせた形に都度都度修正する必要が出てきます。 (最新のパッチを保守対応用ブランチに適用させていくバックポート対応のイメージです)

この都度都度修正の対応が大きめの施策になればなるほどCakePHPのバージョンの差異に合わせた修正の規模が大きくなってしまう問題もあり、その分工数が余計にかかってしまいます。

これらの事情から、保守対応ブランチをmainブランチへマージするまでの時間を短くするために、あえて段階的にアップグレード対応を行うということになったのです。

また、以前CakeFestで紹介されたスライド(CakePHP - The Road Ahead)でも、2.xから3.0.0にアップグレードしたときに変更量が多くて大変だったということが述べられています。

実際にサービス提供しているプロダクトの場合、安全に倒すためにも段階的なリリースを計画するのが良さそうですね。

CakePHP3.6から3.10へ

まず、CakePHPのバージョンを3.6からCakePHP3.xの最新のバージョンである3.10にアップグレードしました。 実はこの3.6から3.10にアップグレードする際の変更量が一番多かったのではないのかと思っています。

一番大きな影響が受けたのがテストのFixture周りです。

今までは Model クラスをテストケース内で使用する際には TestCase のメンバ変数内で実際の DBに格納されているテーブル名に合わせてModel名を以下のように Snake Caseで記述していましたが、CakePHP3.6以降ではModel名をUpper Camel Caseで記述する必要があります。

TestCase::$fixtures にてアンダースコアー形式のフィクスチャー名を使用することは非推奨です。 代わりにキャメルケース形式の名前を使用してください。例えば、 app.FooBar や plugin.MyPlugin.FooBar です。 3.7 移行ガイド - 3.10 より引用

public $fixtures = [
    'app.cities',
    'app.countries',
    'app.country_languages',
];
public $fixtures = [
    'app.Cities',
    'app.Countries',
    'app.CountryLanguages',
];

ロジックの変更対応ではないので、一つ一つ対応していけば良いのですが、テストケースの数が多ければその分対応する場所も多くなってしまいます。

変更量が多いということはテストファイルによって、ある程度テストの網羅性が担保されているとも考えられるので、この変更は喜んで進めていきましょう。

さいごに

どこの会社・プロダクトでも保守対応は置いてけぼりになりがちになってしまい、フレームワークのバージョンが置いていかれてしまうことが多いと思います。 セキュリティパッチが当てられたりと、フレームワーク側で対応が進められている中で、古いバージョンのまま放置しておくとセキュリティリスクも上がってしまいます。

アウトカムのリリーススケジュールと並行して計画的にバージョンアップを行えるようにしていきたいですね!

あわせて読みたい