dependabotでのgem更新運用体制

2 min read読了の目安(約2100字

Railsなプロジェクトにといてdependabotを利用してgemを定期的に更新する場合の運用方法・パターンについてまとめてみました。

dependabotでgem更新を管理する理由

  • 個別gemごとにみた場合、バージョンアップでバグ修正や機能追加が期待できる
  • プロジェクト全体でみた場合、Ruby / Railsのアップグレードに備えて日頃からgemのアップグレードを行っておく必要がある

どこかの時点でまとめて上げる方法もあるが、バージョンが一気に上がるとその都度の動作確認が大変になりがち。特に脆弱性修正が発生した場合に芋づる式に複数のgemについてバージョンアップする作業はシビアな時間との勝負になりがち。

よって、特に自社サービス運営の場合は日常的にgemを上げていくことが望ましいことが多いでしょう。一方で、受託開発の場合は保守契約の内容次第で対応は変わってくると思います。

PR毎にやるべきこと

Changelog の確認

gemのメンテナが正式に出している変更点なのでまずはこれをチェックします。非常によくメンテナンスされているプロジェクトであればChangelogを見るだけで主要な変更点を把握することができます。

しかし、Changelogに書かれていることがすべてではないです。一般的にテスト関連の修正などはgem利用者にはあまり関係が無いこともあってか、Changelogに記載されないことが多いです。反対にChangelogに書かれていないけど重要な変更が加えられていたり、Changelogにさらっと触れられてるけどプロジェクトに大きな影響を与える変更もあったりします。

コミット群の確認

GitHub Releasesを使って管理されている場合は直前バージョンとのコミット差分がわかりやすく確認出来きます。そうでない場合は前回バージョンリリース時のコミットハッシュ値を取得してcompare viewで確認するなどが必要になります。

また、aws-sdkselenium のようにmonorepoで管理されているプロジェクトの場合は手元にチェックアウトして特定ディレクトリの変更を追うほうがいいこともあります。

前回バージョンからの差分コミット群を見ることが出来れば、すべての変更を把握することができますが、たとえば rails など非常に大きなgemではすべてのコミットに目を通すというのは現実的ではないです。このようなケースでは公式に出されているchangelogやアップデートガイドなどを頼ることになります。

反対に小さいgemであればすべての変更を見ることは容易なことが多いです。issueやPRの内容を確認してどのような変更がなされたかを追うことで自信を持ってmergeできます。

issue / PRの確認

新しいリリースに対してバグが発見されてissueやPRが出ている場合があるので、必ず目を通しましょう。リリース直後にdependabotがPRを出してきたgemで、特に急いでmergeする必要がない場合はとりあえず時間をおいてみるという手段もありです。ただし、なんでもかんでも様子見にしてしまうとdependabotのPR上限数に引っかかることが考えられるため、溜めすぎに注意です。

Gemfile.lockの確認

Changelogなどに記載があることもありますが、gem本体以外にも依存関係を持つgemのバージョンが上がっていることがあります。その場合はそれらのgemについても確認が必要になります。

CI実行結果の確認

変更内容によっては実行結果だけでなく、CIの実行ログを確認してwarningなどが出ていないかを見る必要があります。

ステージング環境等での確認

本番環境相当で確認が必要なgemの場合、ステージング環境などを準備して確認する必要があります。監視系や本番でだけ利用しているサービス向けのライブラリなどが該当します。

チーム構成

担当者1名の場合

2,3人の小チームだったり、プロジェクトが立ち上がったばかりでまだ運用に入っていないようなケースでは1名で回すほうが合理的な場合が多いかもしれません。

担当者がすでに十分な経験を積んでるエンジニアである場合、1名で回すのがもっとも効率が良いかもしれません。しかし、担当者がSPOFになっていること、他のエンジニアがdependabotお守り業の経験を積めないなどがデメリットになってきます。

担当者2名以上の場合

担当者が2名以上だと1名のときより時間がかかるというメリットはありますが、担当者全員で経験値を稼ぐということができます。主担当・副担当構成を取ることで経験の浅いエンジニアの育成が可能です。

一方で、担当者の誰かが最終的に責任を持つようにしておかないと「実はみんなあまりよく変更点を確認していなかった」という問題が起きます。