tags
development
frontend
author
category
frontend
mainImage
publishedAt
Aug 4, 2023
published
published
slug
frontend-library-update
authorDisplayName
Yasuyuki Matsumoto
こんにちは。令和トラベルで「NEWT（ニュート）」のWeb開発を担当している松本（@_yamatsum）です。NEWTではアプリだけでなくWebにも力を入れており、ブラウザからでも海外旅行をかんたんに予約できるように日々改善しています。
Web開発チームは4人のフロントエンドエンジニアで構成されており、チームとして開発を進める中でビジネス要件のタスクだけでなく、エラー監視やテストなどプロダクトの改善に向けた開発や運用も増えてきました。
限られたリソースの中でチームとして最大限のパフォーマンスが発揮できるように、自動化できる業務は自動化し、効率的な運用を心がけています。そこで今回はチームでのライブラリの運用とその自動化についてご紹介いたします。
今のNEWT-Webのライブラリ運用について
現在のNEWTのフロントエンドの技術スタックは、Next.js(React)、TypeScript、GraphQLと比較的モダンな開発環境となっています。
※弊社エンジニアのNEWTのフロントエンド技術スタックに関する記事
その中で、自作できるものは自作して、ライブラリを極力入れないという運用方針となっています。自分がPP（※令和トラベルでは副業で携わってくれている方をPP=プロ・パートナーと呼んでいます。）として参画した最初のタスクが、つまみが2つの<input type="range">を作成するというものでした。公開されているライブラリを利用すればすぐに作れるものを、自作することで以下のメリットがあります。
- 学習の機会: ライブラリを自作することは、その領域の深い理解を得るための学習の機会になります。ライブラリを作るためには、問題の解決に必要なアルゴリズムやデザインパターン、ベストプラクティスについて学ぶ必要があります。
- パフォーマンスの最適化: 自作のライブラリを利用することで、特定のニーズに合わせて最適化を行うことができます。外部のライブラリは一般化されているため、自分のプロジェクトに必要以上の機能やリソースを持っていることがあります。自作のライブラリは、パフォーマンスやメモリ使用量の最適化を行うことができ、プロジェクトの要件に合わせて最適な解決策を見つけることができます。
- カスタマイズ性: 自作のライブラリは、自分のプロジェクトに完全に合わせてカスタマイズすることができます。外部のライブラリを利用する場合、そのライブラリが提供する機能やインターフェースに制約されることがあります。しかし自作のライブラリならば、必要な機能を自由に追加・変更することができます。
- 依存関係の管理: 外部のライブラリを利用する場合、そのライブラリに依存することになります。しかし、ライブラリのバージョンのアップデートや互換性の問題が発生する可能性があります。自作のライブラリを利用することで、依存関係の管理が容易になり、プロジェクトの安定性を確保することができます。
もちろん開発時間が必要以上にかかることや、バグを考慮する必要性が発生するなどデメリットもあるため、プロジェクトの要件や目標、時間枠などを総合的に考慮して判断する必要があります。しかし車輪の再開発は悪いことばかりではなく、チームで車輪の仕組みを理解し、メンテナンスをすることで長い目で見ればプラスになることもあります。
技術的負債について
とは言いつつもすべての機能を自作できるわけでもないため、いくつかのライブラリは導入しています。
そこで次に問題になってくるのが導入しているライブラリの更新です。普段の案件のタスクをこなしつつ定期的にライブラリの更新も行わないといけなくなり、更新が滞ると脆弱性が発生したり、大規模なリファクタリングが発生したり、最新の機能が利用できなかったりと技術的負債が発生します。
また最新のライブラリを利用することは開発者体験を高めることができ、他社から見たときにプロダクトチームの魅力を高めることもできます。実際、私が入社を決めた要因の一つは、モダンな開発環境であるという点でした。
ライブラリの更新に向けて
ライブラリ更新に向けて行ったこととして
- 不要なライブラリの削除
- メジャーアップデートについては、日々のスプリントに組み込む
- dependabotを利用してpatchバージョンアップの自動化を図る
があります。
1については、そもそも利用されていないのにpackage.jsonに記載があるライブラリや、すでに導入済みのライブラリ間で機能が重複しているものについては削除を行います。フレームワークのアップデートにより新機能が追加されることで、他のライブラリが不要になることもあります。またNEWT-Webではモノレポを採用しており、ライブラリを各アプリに導入するのではなく、root配下で導入することで重複をなくすことができるものもあります。（この場合は、実際にダウンロードされるライブラリサイズが減るわけではないです）
2については、メジャーアップデートではBREAKING CHANGEを含むものもあるため、案件としてスプリントに組み込みます。リリースノートを確認してアップデートの概要をつかみ、必要であれば修正を行います。自分のチームではテスト環境がまだ整っていないですが、アップデート後はQAを通すことでインシデントを未然に防いでいます。
![[QA] ReiwaTravel Engineering | 株式会社 令和トラベル](https://engineering.reiwatravel.co.jp/img/website-card.png)
3についてDependabotを利用して、ライブラリアップデートのPRの自動作成を行ってもらいます。
Dependabotについて
Dependabotとは、GitHub上で自動的にプロジェクトが依存しているライブラリのバージョンを上げたPRを作ってくれるボットです。
Dependabotには大きく3つの機能があります。
機能 | 概要 |
脆弱性が検知されたとき、アラートの通知を行う | |
検知された脆弱性に対して、対策を提案する | |
各種パッケージのバージョンの更新をチェックし、通知および対策を提案する |
この中でDependabot version updatesを利用して、バージョンアップの更新を行います。
ここでよく課題として上がるのが、Dependabotが作成してくれるPRがライブラリごとになるため、PRがDependabotで埋め尽くされてしまうという問題です。
そのためある程度のリスクを受容して、自動マージを行います。2019年にGithubに買収される前のDependabotでは、自動マージ機能が搭載されていたのですが、Github NativeなDependabotになってからは自動マージ機能が存在しないため、Github Actionsを利用します。
公式ドキュメントに自動マージのためのサンプルの記載があるため、こちらをベースに実装しています。
Dependabotの実行タイミングは、自動マージ後にQAを挟めるようスプリントプランニングの次の日としています。自動マージによって運用が一部減らせることができました。
まとめ
NEWTのフロントエンドの開発における、ライブラリへの向き合い方の紹介でした。
今回はpatchバージョンのみの自動アップデートを導入しましたが、運用の中で問題がなさそうであれば、devDependenciesのminorバージョンに関しても自動アップデート対象としても検討したいと考えています。
そんな令和トラベルでは、一緒にNEWTを発展させていく仲間を募集しています。ご興味がある方はぜひ採用ページをご覧ください。
また、8/29（火）にはFrontendエンジニアによるLT会を予定しています。今回は令和トラベルオフィス・オンラインのハイブリッド開催です！エンジニアリングの最前線で働く令和トラベルのエンジニアたちの話を聞きに、ぜひお越しください。LT会後は懇親会をオフィスにて開催します。オフライン参加が可能な方は、夏祭り気分を味わえるごはんを囲みながら、ネットワーキングをお楽しみいただきたいと考えているので、ぜひお気軽にご参加ください！
それでは次回のブログもお楽しみに！Have a nice trip！！
