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

Table of Contents

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

始めに

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

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

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

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

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

最近だと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を圧迫するのだけはなんだかなぁと。