“依存ライブラリ更新めんどい問題”を解決するRenovateを試してみた

依存ライブラリのバージョン管理は既に人間には無理ゲーになっている

　リポジトリが依存しているライブラリのバージョン管理は大変である。比較的シンプルなプロジェクトであっても、pipやらgemやらDockerfileのベースイメージのバージョンやらnpmやらMavenやらGradleやらで複雑な依存関係を整理することになる。当然、多種多様なライブラリはそれぞれのペースでこちらの事情などお構いなしに開発を進めていく。関係する全てのupdateをきちんと見極めて、タイムリーに自分のリポジトリに取り込んでいくのはもはや無理ゲーだ。

　ということで、気づいたベースで対応する、必要になった段階で対応する、やる気が出た瞬間に気合でアップデートする、という運用になりがちだ。だがこれでは継続的に高品質な運用をすることは難しい。

依存関係自動更新ツールのRenovateを使ってみたけどすごくよかった

　最近、Renovateと呼ばれるツールがあることを知り、導入してみたのだがとてもよかったので紹介したい。Renovateはリポジトリが依存しているパッケージのバージョンを監視して、アップデートを自動的に提案してくれるツールだ。まさに前述の問題を緩和してくれる。

　GitHubとの連携も可能で、Pull Requestを自動的に立てるように設定することも可能だ。PRにはUpdateの種類（minor / major / patch)やRelease Note、Commit logなど結構詳細な情報まで載せてくれる。

　かなり柔軟に設定できることも特徴だ。DependabotやGreenkeeper等の類似ツールと比較しても下記のような点が優れているようだ。
・監視対象を自動で検知してくれる
・監視対象を絞ることができる
・PRを出す本数やタイミング、頻度などをかなり柔軟に調整できる
・オートマージをしてくれる

　意図的にupdateをしないことを選択した場合はただ黙ってPull RequestをCloseすればよい。「じゃあこのバージョンは無視するわ、将来に出るバージョンは通知するけど、それもうざかったらここ変更しといて」と丁寧に返してくれる。

Onboardingも非常に丁寧だし、少なくとも今は無料なのも良い。今のところはプライベートリポジトリであっても無料で使えるようだ。

インストールはGitHubで一瞬で終わる

リポジトリとの連携は非常に簡単だ。

　まずはGitHubのマーケットプレイスにいき、「Set up a new plan」であなたのOrganizationやAccountにインストールする。

指示に従ってリポジトリを指定すると、下記のようなConfigure RenovateというPRが自動的に作られる。OnboardingのPRに従って中身を確認し、mergeすればRenovateは動き始める。

上記の例（適当な個人用プライベートリポジトリでやってみた例）では、例えば下記のファイルを監視してくれるとのこと。

containers/docker-compose.yml (docker-compose)
containers/Dockerfile (dockerfile)
terraform/aws/modules/lambda-scheduled-task/lambda/requirements.txt (pip_requirements)
containers/pyproject.toml (poetry)
terraform/aws/provider.tf (terraform)
terraform/aws/tasks.tf (terraform)
terraform/aws/vpc.tf (terraform)

Mergeするとお行儀よくbranchを削除してくれる。細かいところに気づいてくれて嬉しい。オモテナシ精神を感じる。

設定ファイル例

基本的にはrenovate.jsonというファイルにRenovateの設定を書くことができる。お勧めとしては、いきなりいろんなものを監視しはじめるのは敷居がやや高いところもあるので、ミニマムにDockerのベースイメージだけからスタートしてRenovateに慣れる、というやり方がある。その場合は下記の設定が良いのではないだろうか。

{
"extends": [
"config:base"
],
"timezone": "Asia/Tokyo",
"schedule": ["every weekend"],
"enabledManagers": ["dockerfile","docker-compose"]
}

・extendsでは設定を継承できる。基本はbaseのconfigから始めるので良さそう
・timezoneは住んでいるところに合わせたい
・scheduleが毎週末になっているのは、平日にPRを上げて欲しくないから（月曜に仕事をはじめるときに、PRが上がってきている、という形を作りたい）
・enabledManagersでは監視対象のパッケージファイルの種類を設定できる。まずはdockerあたりから始めるのがおすすめなのでdockerfileとdocker-composeをここでは指定している

　セキュリティ意識の高いプロジェクトではこういう設定も役に立つかもしれない。

"vulnerabilityAlerts": {
"labels": ["security"],
"assignees": ["@takahiroanno"]
}

　脆弱性のアラートが検出された場合には、PRに専用のラベルを貼って特定のGitHubアカウントのユーザをアサインされるようになる。

　また、攻めた設定をすると、こういうこともできる。

“automerge”: true

　オートマージをtrueにすることで、PRが勝手にmergeされるようになる。壊れても良い個人開発などではこれでもいいのかもしれない。さすがに全部automergeはやりすぎだとすれば、マイルドな案としてはこういう設定もできる。

“patch”: { “automerge”: true}

　上記を設定すれば、patchのバージョンアップに関してのみ、PRを自動マージするようになる。patchのバージョンアップでは破壊的変更は基本的に含まれないため、より安全だ。

リポジトリのルンバビリティと複利効果

　ルンバビリティという概念がある。自動お掃除ロボットのルンバがどれだけ活躍できる家かということだ。そもそも床にものがおかれていたり、障害物が多い部屋の場合はいくらルンバが自動で掃除しようとしてもできない。ルンバが最大限に活躍できない。なので、人間は部屋のルンバビリティを高め、ルンバブルな部屋を実現することに投資すべきだ、という考え方だ。

　これは非常に面白いと思っている。人間が掃除機で部屋を掃除しはじめた太古の昔から、一応、床に物を置くのはアンチパターンだと認識されてはいた。しかし、ルンバという存在があることによって、より床に物を置かないことのインセンティブが増加するようになった。

　ルンバビリティと同じ考え方はRenovateとリポジトリの間にも成立するだろう。リポジトリでも自動テストがきちんと書かれていれば、Renovateのようなツールで安全にAutomergeができる確率が上がるわけである。なるべくAutomergeができるように、自動テストを書いていくインセンティブや、問題があった時にすぐに戻せる環境を整備するインセンティブが増加するのは面白いなと思う。

　結局、ツールに合わせて複利で効く施策を打てている開発チームと、そうでない開発チームの生産性の差は複利効果でどんどん開いていくということになるのではないかと思う。個人的な予想ではこれから機械学習技術の進展に伴いますます多様な開発自動化ツールが生まれていき、リポジトリのルンバビリティという考え方はより重要になっていくだろうと思う。Renovateのような”広義のCIツール”とどう向き合い、どう使いこなすかは開発組織にとってより重要なイシューになっていくのではないだろうか。

（それっぽい宣伝）

　私が今働いているMNTSQ（モンテスキュー）では、Renovateをはじめとして、CI/CDの活用、ドキュメンテーションの文化など、複利で効く施策を早めに打つ開発文化があります。絶賛ソフトウェアエンジニアを採用中なので、興味がある方がいればお気軽にご連絡ください！

（唐突な宣伝）

　そういえば、昔、広義のCI（コンティニュアスインテグレーション）についてショートショートを書いたので是非読んでみてください。