ライブラリアップデートを継続的に行う文化をチームで作るための取り組み
この記事は LAPRAS アドベントカレンダー 2021 の 1 日目の記事です。
LAPRAS 入社後に行ってきたライブラリアップデート周りの取り組みについてまとめてみました。
経緯
プロダクトが成長して機能が豊富になると、必然的に依存ライブラリが増加し、各ライブラリのアップデートへの追従に苦労しがちですよね。
自分が入社した当時の LAPRAS でもその課題がありました。
当時のライブラリアップデートまわりの環境は、セキュリティアラートに関連する PR のみが定期的に作られ、その PR のレビューも気づいた者がベストエフォートで行うというもので特に何か明文化されたルールはありませんでした。
ライブラリアップデートが遅れると、以下のような問題があります。
- セキュリティリスクの増加
- 新機能が使えないというモチベーションの低下
- より大きなライブラリ・FW（例： Vue, Django 等）のアップデートへの悪影響
さらに、アップデートが遅れれば遅れるだけ差分が大きくなり、よりアップデートがしにくくなるという悪循環も生まれてしまいます。
今後も継続して成長させていくプロダクトにおいて改善すべき点だと考え、ライブラリアップデートを恒常的に行うための仕組みづくりに着手しました。
取り組みの結果
先に結果から。
後述する取り組みを 4 月からはじめ、ライブラリアップデートの PR のマージ数は以下のように推移しました。
※ 主要リポジトリ 2 つの合計値。マージしたもののみ集計
まだまだ波はありますが、以前より平均して高い水準でアップデートを行えるようになったと思います。また以前は、ライブラリアップデートの PR をレビューする人がほぼ固定されていたのですが、最近はチームの皆でレビューするように変わってきました。
やってきたこと
レビュアーアサインの自動化 & レビュー負荷の削減
最初に行ったことは、レビュアーアサインの自動化です。
今までは特にレビュアーが指定されておらず、気づいた人が対応という形だったのですが、そうすると皆忙しいのでアップデートの PR レビューは後回しになりがちでした。
その改善のため、Dependabot の PR 作成時に、GitHub Actions でランダムにレビュアーをアサインし明示的にレビューしてもらう形に変えました。
また、レビュー時の負荷を下げるための施策として、フロントエンドライブラリのアップデートの場合は master と PR 間のビルド差分の検出を行う GitHub Actions を作成したりもしました。
ビルド差分を検出しコメントする GitHub Actions
それらの取り組みの詳細は以下の記事でまとめています。
その他にも、Dependabot の PR をレビューするポイントをまとめた esa を作り、チームへの共有も行いました。
PRマージ状況の可視化
前述の取り組みで、以前よりはライブラリアップデートが行われるようになったのですが、まだまだスムーズに流れているとは言い難いものでした。また、その状況の把握自体が感覚的なもので、何か数値として計測もしていませんでした。
そこで同僚のアドバイスをもとに、PR のマージ状況をひと目で確認できるダッシュボードを作成しました。
GAS で定期的に GitHub の API を叩き、ライブラリアップデート PR のマージ状況をスプレッドシートにまとめ、それをもとに Google Data Studio で可視化するという仕組みです。
- 週別のライブラリアップデートの状況（目標値との比較）
- ユーザー別のマージ件数ランキング
- 長期的に滞留している PR の一覧
などが表示されます。
このダッシュボードを定例ミーティングにてメトリクスとして確認し、今の状況を継続的に追っています。
ライブラリアップデートPRレビュー会の企画・運営
ダッシュボードを作成したことで、継続的にライブラリアップデートの状況を確認することは出来るようになりました。
ただ、それにともないライブラリアップデートをレビューするメンバーに偏りがあるという事実も明確になりました。また、他の皆がどのようにレビューしているのか知りたいという意見もメンバーからもらいました。
そこで、よりライブラリアップデートを恒常化するためのテコ入れが必要と考え、ライブラリアップデート PR レビュー会というものを定期開催することにしました。
会の概要はこちらです。
開催日：毎週水曜 11:00〜11:30
参加者：開発チーム（任意参加）
実施方法：Meetのブレイクアウトルームで2〜3人一組に班分け。それぞれの班で20分間PRをレビューする。
最後の5分でもとの場所に戻りそれぞれ成果を共有。
狙いとしては、ライブラリアップデート PR のマージ数の増加、PR レビュー観点の共有、1 人だと判断が難しいライブラリのアップデート対応の効率化があります。
実際に以下のような esa を作り運営しました。
毎回レビューした内容をログとして記録もしています。
この会自体はかなり機能していて、続けるごとにライブラリアップデートの PR のレビュー数も増加し、皆でレビューするぞというチームの雰囲気が生まれてきました。
今後の課題
これらの取り組みで、ある程度改善してきたのですが、まだ以下のような課題もあります。
Renovate と Dependabot の共存
LAPRAS では主要プロダクトのリポジトリが 2 つあるのですが、それらのリポジトリで片方はDependabot、片方はRenovate を利用するという状態になっています。
Renovate のほうが関連ライブラリのアップデートをまとめてくれたり、ライブラリバージョンの Pin 化をしてくれる機能もあり便利なので、早いうちに統一したいと思っています。
PR レビュー会への依存
PR レビュー会はとても良いのですが、レビュー会があることで、そのタイミングで見ればよいかと、他の時間にレビューすることが少なくなりました（自分も含め）。
流石にレビュー会だけでは、全体としてのアップデート数は賄えないので、また補助的な仕組みが必要かなと考えています。
引き続き今後も改善していきたいです。
終わりに
以上「ライブラリアップデートを継続的に行う文化をチームで作るための取り組み」でした。
どなたかのチームの参考になれば嬉しいです！
つらつらと書いたのですが、それぞれの取り組みはチームの協力があったからこそ出来たものだと思います。新しい取り組みを始めるときに、常に応援・協力してくれるメンバーに恵まれて感謝感謝の毎日です。
明日のアドベントカレンダーは @yktakaha4 です。
お楽しみにー!!
Discussion
ライブラリアップデート会は、普段違うことやってるメンバーと同じコンテキストでサッとペアプロする感じがあってやっててたのしいなと思います