🤖
Renovateについてまとめる

2024/11/09に公開
 背景フロントエンドのエンジニアとして新卒入社して1年以上が経過した。
保守運用業務に携わる中で、「動けばとりあえず良い」という個人開発や、ユーザーがほとんどいない立ち上げたてのプロダクトとは異なり、品質を担保するための周辺ツールを数多く学んだ。
こういった知見は実務に携わってみないと得られない知識だった。そこで、自分の学びをまとめるとともに、企業に入って初めてRenovateに触れる方々のために、この知見を整理しておくことにした。

 Renovateとは何か？https://docs.renovatebot.com/
公式サイトには次のように記載されている：「Automated dependency updates. Multi-platform and multi-language.」
和訳：「依存関係の自動更新。マルチプラットフォーム、マルチ言語対応。」
つまるところ、ソフトウェアプロジェクトの依存関係（ソフトウェアが動作するために必要な外部ライブラリやパッケージ）を自動的に更新するためのオープンソースツールである。

 どのように便利かプロダクトには多数の外部パッケージが含まれており、これらは日々更新されている。これらの更新には以下のような重要な内容が含まれているため、放置することは潜在的な問題を見過ごしたり、得られるはずだった利益を逃すことに等しい。
脆弱性修正
バグ修正
パフォーマンス向上
新規機能の追加
サポート終了・サポート追加
他のライブラリとの依存関係のアップデート
依存関係を手動で更新する作業には、以下のようなステップが考えられる：
リリースノートをチェックして更新を把握する
更新作業を行う（主にpackage.jsonなどの依存関係管理ファイルを編集）
プルリクエスト（PR）を作成する
CI/CDによる自動テストを実行する
リリースノートに記載されている更新内容に基づき、プロダクトへの影響を確認する
必要に応じて修正を加える
PRをマージする
しかし、プロダクトには無数の依存関係が含まれている。さらに、依存関係の更新によって既存のプロダクトに変更が必要（つまり工数が発生する）な場合もあるため、どの依存関係を優先的に更新するかを選択しなければならない。これらすべてを日々監視し続けるのは現実的ではない。
それなら、依存関係が更新された時にPRを自動化してしまおう！というのがRenovateである。
上記のうち、
リリースノートをチェックして更新を把握する
更新作業を行う（主にpackage.jsonなどの依存関係管理ファイルを編集）
プルリクエスト（PR）を作成する
CI/CDによる自動テストを実行する
の作業を自動でやってくれる。
また、設定によっては軽微な変更であれば自動でマージしてもらう設定もできるため（これについては別途説明）、
リリースノートをチェックして更新を把握する
更新作業を行う（主にpackage.jsonなどの依存関係管理ファイルを編集）
プルリクエスト（PR）を作成する
CI/CDによる自動テストを実行する
リリースノートに記載されている更新内容に基づき、プロダクトへの影響を確認する
必要に応じて修正を加える
PRをマージする
全ての作業を行なってもらえる。
これにより、大幅に工数を削減したまま、プロダクトの品質を保つことができる。

 DependaBotとどう違うか上記を行ってくれるツールで最初に思い浮かぶものにDependabotがあると思う。GitHubにデフォルトでついている。ざっくりとした違いとしては以下のような感じであろうか（比較検討は公式ドキュメントを参照のこと）。
Renovate：多機能で高いカスタマイズ性を持ち、複数のプラットフォームやエコシステムに対応している
Dependabot：GitHubに特化しており、シンプルで使いやすい。GitHubリポジトリを使用しており、とりあえず導入するならおすすめ
RenovateはDependabotとは違い以下のメリットがある
カスタマイズ性
グループで依存関係を更新する系のカスタマイズ（dependabotも出ている（https://github.blog/changelog/2023-06-30-grouped-version-updates-for-dependabot-public-beta/
自動マージの条件、スケジュールなど

GitHub、GitLab、Bitbucketなど複数のプラットフォームに対応している
逆にDependabotにしかできないこともある**：**
Dependabot security updates
GitHubが提供するセキュリティ脆弱性に関する情報を集約したデータベース（https://github.com/advisories）

を参照して、脆弱性が発見された場合に自動的にセキュリティアップデートを提案する機能。
また、詳細は省くがGitHubが提供しているツールであるため、GitHub固有の機能や統合に関してはDependabotが優れてことがあると考えられる。

 やってみるまずは環境を作る
mkdir renovate-sample
npm init
試しに古いパッケージを入れてみる。なんでもいいが、axiosと、huskyとかにしてみる。

axiosは2024年11月9日現在、最新が https://github.com/axios/axios/releases/tag/v1.7.7 である。なんとなく1.6.2を入れてみる（マイナーバージョン単位で古い）。

husky、9.1.6が最新である。9.1.5を入れてみる（パッチバージョン単位で古い）。
npm i axios@1.6.2
npm i husky@9.1.5

一旦これをpushする（node_modulesのignoreとか忘れないように）。
echo "node_modules/" > .gitignore
git remote add origin https://github.com/hogehoge/hogehoge.git
git add .
git commit -m "first commit"
git push origin main
renovateのインストール

https://github.com/marketplace/renovate#marketplace-plans-container　にアクセスして「install it free」を押す

$0であることを確認して次に

全部のリポジトリにインストールされると厄介なので検証用のリポジトリを選ぶ

手順に従ってインストールすると、renovate/configureというPRができているはず


設定を変更したいのでpullして書き換える
git pull orgin renovate/configure
{
  "extends": [
    "config:base"
  ],
  "packageRules": [
    {
      "updateTypes": ["patch"],
      "automerge": true,
      "automergeType": "branch"
    },
    {
      "updateTypes": ["minor", "major"],
      "automerge": false
    }
  ],
  "automergeStrategy": "auto",
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "labels": ["renovate"]
}

説明
パッチバージョンの更新は自動でマージ。
マイナーとメジャーバージョンの更新はPRを作成するけど、自動マージはしない。
自動マージは、条件が全部そろったときにだけ実行。
同時に開くPRの上限は5つ。
1時間あたりに作成するPRの上限は2つ。
PRには「renovate」ラベルが付く。
以上でPRができていると思う。

 運用自分のチームではパッチバージョン（x.x.xの3つ目の最も軽微なアップデート）に関しては、automergeをし、それ以外はモブで手動マージをする。リリースを行った翌日にRenovateを確認するモブプロを行うと決めている。ここで、automergeされたものが本当に問題ないのかを確認し、Renovateによって生まれたマイナーアップデート以上のPRを混ぜる
理由は以下である。
リリース日の翌日に行うことで次のリリースまで最長の期間、社内検証を行うことができる。これにより依存関係の更新によるデグレを検知しやすい。特に依存関係の更新は影響範囲が計り知れない部分があるため。
リリースノートを読むことは慣れが必要なことであり、各々のスキルにばらつきがあるチームではこれに対応できるメンバーが偏る可能性がある。マージ会という形でお互いに教えあうことで、スキル差を小さくする。
背景

Renovateとは何か？

どのように便利か

DependaBotとどう違うか

やってみる

運用

Discussion
