放置されがちなライブラリのアップデートを定期的にきちんと行おうという志の元、Renovateを設定したときのメモ
導入した感想としては、とてもいい感じで運用できそうである。
定期的にアップデートできる仕組みが整ったしPR作成も自動でやってくれるので諸々のわずらわしさがなく、非常に便利だなという印象。
同じようなことができるものにdependabotがあって、当初はこれを使おうとしていたんだけどいくつかの理由からRenovateを使うことにした。
この辺は後で比較する
Renovateとは
ライブラリなど諸々の依存関係のバージョンを定期的にチェックしてくれて、バージョンアップのためのPR作成などを自動で行ってくれるツール。
これを導入することでたとえば、週一や月一でライブラリのバージョンアップデートができるようになる
PRの自動作成がとても便利で、PR上でリリースノートを表示してくれるのでそれを見て問題がなければそのPRをマージするだけ、という運用にすることができる。
たとえばメジャーバージョンアップデートの時に破壊的変更がないかの確認もPR上で確認できる
こまめにライブラリをアップデートするモチベーションとしてはたとえば以下のようなものがあると思う
1. 差分の大きいバージョンアップはリスクが高い
2. ライブラリに脆弱性が見つかった際はバージョンアップが必要
3. 使いたい最新の機能をすぐに使えるようになる
ライブラリの新しい機能を使いたいと思ってアップデートしようと思っても、最後にアップデートしたのがかなり前だと他のライブラリもいくつか一緒にアップデートしなきゃいけないみたいな事態になったりする
そういったライブラリの数が多いとリスクも高くなるし新しい機能を使うまでがスムーズにいかなくなるので、ライブラリは定期的にアップデートしておきましょうということだと認識している
Renovateの設定
まず公式ページからinstallして対象のリポジトリを選択する
そうするとそのリポジトリで設定用のPRが作成されるのでそれをマージするのみ
これだけで設定が終わる。とても簡単。
このPRによってrenovate.jsonという設定用ファイルが作成されるのでこの中身をいじれば好きな設定にできる
んで、この設定項目が非常に多い！
詳細は公式ドキュメント参照として、ここでは実際に設定した項目だけ見ていく
{
"extends": ["config:base"],
"schedule": "before 9am on the first day of the month",
"timezone": "Asia/Tokyo",
"prHourlyLimit": 0,
"rangeStrategy": "bump",
"packageRules": [
{
"matchUpdateTypes": ["patch", "minor"],
"groupName": "update all minor and patch dependencies",
"excludePackageNames": ["typescript"],
},
{
"matchPackageNames": ["react", "@types/react", "react-dom", "@types/react-dom"],
"groupName": "react"
}
],
"enabledManagers": ["github-actions", "npm"],
"ignoreDeps": [
...
]
}初期設定だとextendsにconfig:baseだけが設定されていてこれによってある程度の設定が行われる。
それ以外のカスタマイズをその下でやっている
以下に簡単に列挙する
schedule
毎月1日の午前9時くらいにPR作成するようにしている
daily, weeklyの設定も可能
prHourlyLimit
デフォルトだと1時間に2つしかPRを作成しないような設定になっている
アップデートすべきライブラリ数が多いとPRを何個か作成する必要が出てくるので0を指定してPR数を制限しないようにしている
rangeStrategy
どんなバージョンアップの場合にPRを作成するかという基準
主にバージョンの指定でキャレット(^)などを使っている際に指定するもの
bumpだと^1.0.0 -> ^1.1.0の場合にもアップデートするが、replaceだとこの場合はアップデートの対象にならないなどの設定
packageRules
PR作成する際の細かな設定を行える部分
初期設定だと1つのライブラリで1つのPRを作成するようになっている
メジャーバージョンアップデートではそれでもいいのだが、マイナーバージョンとパッチバージョンのアップデートでそれをすると、PR数がとんでもなく多くなることになる
なのでマイナーバージョン以下のアップデートはまとめて1つのPRにするように設定matchUpdateTypesでminor, patchを指定して、groupNameを設定するとそれらを1つのPRにすることができる
pinというのも指定できて、これはバージョンをキャレット(^)やチルダ(~)を使わずに固定するというもの
それぞれメリットデメリットはあるが、今回はチームで話し合った結果、バージョンの固定はしないこととした
ちなみにRenovate公式では固定推奨
固定しない主な理由としては、pinしてあるものはバージョンアップで不具合があった場合にダウングレードしたなど、意図的にそのバージョンに固定する必要があるということを示唆するものであるべきという意見からそうなった
"excludePackageNames": ["typescript"]で1つにまとめるPRからTypeScriptを除外している。
これはTypeScriptがマイナーバージョンアップデートでも破壊的変更してくることが後に発覚したため除外することとした
まとめるPRはできるだけ気兼ねなくマージできるように変更がないものでまとめておきたいため
あとはReactのアップデートは関連するものをまとめて1PRでアップデートするように設定してある
この他にもdevDependenciesを1つのPRにまとめるとか色々カスタマイズできる要素はあるので、運用しながら適切な設定を探っていくのが良さそう
enabledManagers
npmを指定するとpackage.jsonの中身をチェックしてくれるようになるし、github-actionsを設定するとGitHub Actionsで使用しているコマンドのバージョンアップデートをチェックしてくれるようになる
他にもdockerで使ってるイメージのバージョンとかも管理できるようになる
ignoreDeps
バージョンアップデートをして欲しくないライブラリはここで指定すればPR作成時に無視してくれるようになる
その他設定
今回は設定しなかったが、マイナーバージョン以下をそもそもPR作って勝手にマージしてくれるauto mergeみたいなオプションも設定できる
パッチバージョンは週一でauto mergeとかでも良さそうだなーと思った
運用していく中で変えていくかもしれない
Dependabotとの違い
当初同じようなことができるdependabotを使用しようとしていた
理由としてはGitHubに買収されたしGitHub Actions使っているし何かと連携しやすそうだったしお手軽そうだったから
同じように自動でバージョンチェックしてくれてPR作成してくれるものなんだけど、ちょっと触ってみた感じ微妙なところがいくつかあった
Dependabotと比較してRenovateの方がいいなと思った点は以下
1. GitHub Actionsの中で記述しているsecretsを読み込めるのでCIが通る
2. マイナーバージョン以下のアップデートをまとめて1つのPRにできる
3. 設定項目がかなり多いので細かいカスタマイズができる
1点目に関しては、dependabotはGitHub Actionsの中で記述しているsecretsがセキュリティの都合上読み込めない仕様になっているらしい
なので回避策としてはymlファイルの中でdependabotによるPRなのかどうかを判断してー…みたいな条件分岐を至る所に書かないといけなくなるらしい
それはちょっとめんどくてやってらんないなってなったのがdependabot以外のものを探す理由の大きな要因の１つだった
マイナーバージョン以下を1つのPRにまとめられるのはできるのかもしれないが、設定項目が見当たらなかった
知ってる方いたら教えて欲しいです