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

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


始めに

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

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

基本的に全部のdependabotの生成したPull Requestに関して、CHANGE LOGとコードレベルのdiffを読むようにした。 CHANGE LOGだけでも良かったのだが、多くの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はいれたいなーと思5つ、CIを圧迫するのだけはなんだかなぁと。