はじめに

レバウェルでは現在50近いサービスを運用していますが、そのうち20を超えるサービスをLaravelを利用した共通基盤で実装しています

このため多くの共通機能を社内向けのプライベートなLaravelパッケージとして実装していますが、今回は運用中苦労した点をから社内パッケージを運用・保守する際に意識するポイントを紹介したいと思います

1. テストを実装する

ユニットテスト実装しましょう！
当たり前といえば当たり前なんですが、とても重要なポイントです

レバウェルで初めてLaravelのアップグレード対応を行った当時、30近くあったパッケージのうち、行カバー率で90%以上のパッケージが5パッケージしかなく、必要なユーザテストが膨大ですぐに着手出来ない状態でした

この問題に対し当時ユニットテストのカバー率を上げる対応を行い、行カバー率90%以上で10パッケージ、全体のユニットテスト自体も増やすことでなんとかアップグレード自体は遂行できました

ただ現状も十分なテストが実装出来ていないためバージョンアップ対応するたびに苦労してます

バージョンアップ時のことだけ意識する場合、PHPUnitであれば行カバー率を上げることを進めると良いです

パッケージ全体で平均的に上げていくよりモジュール単位で100%に近づけることを目指したほうが、実際のバージョンアップ対応時にラクになります

パッケージを実装していると他のパッケージを利用して実装する事があると思います

特にLaravelパッケージを作る場合Laravelの機能に依存することが多いと思いますが、その際の依存関係が無駄に大きくならないようにしましょう

運用している中で目にしたのは、初期開発時に広めに依存関係を指定しその後もそのままになっているケースや、不要になった際にcomposer removeしていないケースでした

これらに気づいた経緯が、不具合対応でパッケージを調査した際なのですが、これによって無駄な調査と対応で結構な時間を使うことになってしまいました

同時に社内パッケージ同士の循環的な依存も発生しており、この対応がさらに大変でした

単純なコードだけじゃなく依存パッケージなども小まめに整理する意識をしておくのが良いでしょう

チームによっては外部パッケージへの依存度を減らすために自社で再開発する方針のところもあると思いますが、その辺はチームで判断すればよいかと思います

言語やFWのバージョンアップについての話ですが、社内パッケージを利用しているアプリケーションが増えると、アプリケーション毎のアップデート対応の進捗にズレが出てくることがあります

あるアプリケーションの利用している言語バージョンが古すぎるとき、公開パッケージであればサポート対象から外すという判断が可能なケースでも、社内パッケージの場合サポートしなくてはいけないとなることがままあります

レバウェルでは現在PHP/Laravelともに複数バージョンのサポートが必要なため、ユニットテストを実行する際はそれらをカバーするよう環境を変えつつ複数回実行する必要があります

また、3つのパッケージではPHP8系の3.xと7系の2.xのように複数バージョンを保守している状態で、こちらも変更の度に複数のPRを作成する必要があり大変です

アプリケーション側のアップデート対応は足並み揃えつつしっかり対応し続けることをおすすめします

社内パッケージの場合、非公開かつ自社で利用していることから公開パッケージとは違った苦労も出てきますが、健全に運用されてる他社さんの話も多く聞こえてきます

これから社内パッケージの開発をしようという方が、同じ様な苦労をしないですむことをお祈りしています