🫠

Dependabotでライブラリを日常的にバージョンアップする文化を作った話

2023/11/15に公開

最近、チーム内にライブラリを日常的にバージョンアップする文化と仕組みを形成しました。
その中でいくつかの工夫を行ったので、記事にしようと思います。

背景

私のチームでは、Ruby on Railsを用いてプロダクトを運用しています。
プロダクトリリースからこれまで一度もRailsのバージョンアップが行われておらず、Railsのアップデートを行うことになりました。その過程で、各種Gem(ライブラリ)を大量にアップデートする必要があり、これがまた骨の折れる作業でした。将来も同じ苦労をするわけにはいかないので、これを機に、チーム内で日常的にバージョンアップを行える仕組みと文化を形成することにしました。

そもそもなぜ日常的にバージョンアップするべきか

空いた時間にまとめてライブラリを一気にアップデートするでもいいのでは、という意見もあるかと思います。
しかし、この手法は以下のデメリットがあると思っています。

① 脆弱性が解消されない

ライブラリは脆弱性が見つかると、セキュリティ対策の修正が加えられます。しかし、アップデートを行わないと、この修正は取り込まれないため、脆弱性が残った状態になってしまいます。当然、危険なのでなるべく早くバージョンアップをするべきです。脆弱性の中にもアラートレベルがあるので、それを基準にバージョンアップの判断をするのもありかもしれません。

② 新機能が使えない

ライブラリは日々改善されていき、新機能がリリースされることもあります。いざ使いたい新機能があったときに、すぐにバージョンアップを行える文化がないと、なかなか採用できません。その結果、開発効率を下げることになるかもしれません。

③ バージョンアップ時のリスクが大きい

一気に古いバージョンから新しいバージョンに上げようとすると、リスクを伴います。
CHANGELOGなどで変更内容を確認する際に、バージョン間の差分が大きいと認識すべき変更内容が膨大になります。その結果、仕様変更などに気づけずにバグを起こしてしまうかもしれません。この点は、テストが充実していれば安心感は違いますが、それでも小さい差分でバージョンアップをするに越したことはありません。

④ 開発者の心理的ストレスが大きい

安全にバージョンアップを行うには、きちんとCHANGELOGで変更内容を認識し、プロダクトにどのような影響があるかを確認する必要があります。CHANGELOGの差分が大きいと、不安も大きくなります。また、バージョンアップ作業は楽しいものではないので、たくさんのライブラリを一気にあげようとするとストレスが大きいのも事実です。心理的ストレスを人と時間に分散させることはいい戦略だと思います。

以上のデメリットから、バージョンアップは日常的に行うほうが良いと思っています。

どうやってバージョンアップ文化を形成したか

ポイントはバージョンアップの頻度を人と時間に分散させることです。

① Dependabotによる自動PR作成

まず、GithubのDependabotを用いてバージョンアップPRを週に1回自動生成するようにします。
詳細の方法は、公式ドキュメントがわかりやすいです。
https://docs.github.com/ja/code-security/dependabot/working-with-dependabot

設定内容

どのような戦略でDependabotを組むかですが、以下の記事を参考にしつつ、プロダクトの特性に合わせて設定しました。
https://zenn.dev/sumiren/articles/ffe6c0bd772718

オートマージはしない

上記の記事では、パッチバージョンをオートマージするように設定されています。
しかし、担当プロダクトでは、テストが不十分であるためオートマージはしない判断をしました。
今後、テストを充実させてからオートマージしていく方針にしようと思っています。

OpenするPRの数は最大チームの人数分までにする

デフォルトでは5つまでOpenする設定だった気がしますが、チームの人数より多い数をOpenしてしまうと、一人で2つ以上のPRを担当することになってしまう可能性があります。
ストレスの軽減という観点で、最大1人あたり週に1つまでのPRを担当するようにしました。

② バージョンアップPRのレビュワー自動アサイン

PRの自動生成までは行ったのですが、なかなかメンバーにバージョンアップPRを担当してもらえませんでした。これでは文化を形成したとは言えません。
主な原因としては、責任の所在が不明確だったことです。
誰がどのバージョンアップを担当するかを明確にしていなかったため、有志で担当するという状態になり、きちんとチームとして文化が形成されませんでした。
そこで、バージョンアップPRに自動でレビュワーをアサインする仕組みを導入しました。

設定内容

Github Teamでレビュワーの自動アサイン

まず、Github Teamにバージョンアップを担当するメンバーを入れたチームを追加します。
そして、バージョンアップPRのレビュワーを自動で割当てるよう設定します。
ルーティングアルゴリズムには平等性を担保するためにラウンドロビンを設定しました。

https://docs.github.com/ja/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team

上記の設定を行うことで、メンバー全員でバージョンアップを行うようになり、文化を形成することができました。
導入してすぐはバージョンアップの頻度は高いかもしれません。しかし、徐々にバージョンアップの頻度が低くなっていき、ライブラリ数とメンバー数に依存しますが、1人あたり月に1回とかになればかなり幸せになるのではないでしょうか。

Discussion