半年間毎週dependabotをmergeしたので知見を纏める

本業のRailsプロジェクトのdependabotをひたすら毎週月曜日の11時にmergeし続けて半年以上たったのでそろそろ知見をまとめておこうと思う。


はじめに

世の中のライブラリには大きく分けて3種類ある。

フレームワークと開発支援ツールと通常のライブラリだ。

基本的に全部のdependabotの生成したpull requestに関して、CHANGELOGとコードレベルのdiffを読むようにした。CHANGELOGだけでも良かったのだが、多くのOSSのライブラリのversion upはどういう場合に起こるのかなど傾向を掴むためだ。

diffの読み方

変更頻度の高かった順(takeokunn調べ)に並べるとこんなかんじ。

  • テストの追加
  • CI関連の記述の追加
  • ドキュメントの整備
  • 命名の修正
  • 関数の分離や引数の整理
  • 新機能の実装

業務では有名ライブラリ使っていた影響か、保守的な変更が多かった。

最近だとblacklistが駄目だとかその辺の変更がめちゃくちゃ多かった印象。

事故るとしたら「命名の修正」と「関数の分離や引数の整理」の部分だけなのでそれ以外は読み飛ばしても基本的には大丈夫だ。

フレームワークの場合

RailsやLaravelなど。

必ずRELEASE NOTEを読んで注意深くあげるようにする。

マイナーバージョンアップの場合(ver5.1.1→ver5.1.2)はそこまで神経質にならなくても良い。

メジャーバージョンアップの場合(ver5.2→ver6.0)はテストを充実させる、ステージング環境での十分な検証が必要だ。それでも細かいバグがでるので本当に神経質に確認を取る必要がある。

こう時にphpstanなどの静的解析でぱぱっと検証できるのが理想だよなぁと思う。Railsにはそういうのがないから辛い。

通常のライブラリの場合

FaradayやらDeviseなど。

CHANGE LOGをみてBreaking Changeがなければmergeしちゃって良い。

そんなに破壊的変更を入れるライブラリはなかったし、事故もおきなかった。

テストで検知できるようにはしておきたい。

開発支援ツールの場合

RubocopやらEsLintなど。

基本的にノールックマージして良い。事故ってもCIが落ちるだけなので別にオッケー。

Rubocopはよくconfigの書式がかわったりするのでなるべく頻度高く上げておかないと後々しんどくなる。


おわりに

あたりまえのことしか書いてないが、あたりまえのことをあたりまえにやろう(自戒)

開発ツールだろうがフレームワークだろうがバージョンを一気にあげるのは本当にきついので普段から上げることをサボらないようにしないとしんどい(しんどい)

どのプロジェクトにも必ずdependabotはいれたいなーと思うようになったが、CIを圧迫するのだけはなんだかなぁ....