12
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 3

ラクス Advent Calendar 2025

@oohira
in

じわじわ始めるRenovate

12
Posted at

この記事は、ラクス Advent Calendar 2025 の3日目の記事です。いつも前半担当なのでクリスマス感はあまりないのですが、今年もやっていきます :christmas_tree: :santa_tone2:

2025年はようやく担当プロダクトに Renovate を導入することができました。もう数年前から（何なら前のプロダクトから）導入したいと思ってはいたのですが、そこまで頻繁にライブラリ更新をする開発プロセスでもなく、Renovateの運用フローを整備する前に他にもやることがあるだろうというので、ずるずると後回しになってしまっていました。

しかし、今年はサブシステムを開発するために別の開発リポジトリが増えたり、アプリケーションの機能追加とともにGitHub Actionsや依存ライブラリもさらに増えたりと、いよいよ手動だけでライブラリ更新する手間に耐えられなくなり、Renovateを導入するよいきっかけになったのでした。

この記事では、「Renovateは設定が多すぎるくせに、ローカルで確認しづらく、どういう設定でスタートしたらいいんだ…」と迷子になった私が当時教えてほしかった、とりあえずこういう順番で気軽に導入していったらいいよ、という手順を紹介したいと思います。

前提

  • Renovate や Dependabot のようなツールが何かはそれとなくわかっている前提
  • GitHubリポジトリとRenovateを連携させて使用する（そして連携設定は完了している）前提

ステップ1: 更新検知だけ任せる

RenovateやDependabotを使ったことがなく、急にポンポンPRを出されても運用が回るか不安、というチームにおすすめなのは、まずここ。とりあえず以下の設定を読み替えて、デフォルトブランチにコミットしましょう1。

インラインコメントを使うため、以降の例では JSON5 を使用しています。Renovateは、renovate.json でも renovate.json5 でも解釈してくれるので、好みで選択してください。保存場所も、リポジトリルートだけでなく、.github/ 直下もサポートされています。

renovate.json5
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "local>my-org/renovate-config"  // 組織固有の共通設定がある場合
  ],
  // Renovateに監視＆更新してほしい対象がデフォルトブランチと異なる場合
  // この設定ファイル自体はデフォルトブランチにコミットする必要があるので注意
  "baseBranchPatterns": ["develop"],
  "packageRules": [
    {
      // すべてのライブラリ更新で、明示的に許可するまでPRを作成しない
      "matchPackageNames": ["*"],
      "dependencyDashboardApproval": true
    }
  ]
}

人間が許可するまでは勝手にPRを作らず、ライブラリの更新検知だけをやらせます。Dependency Dashboardという管理用のIssueが1つだけ作られ、更新のあったライブラリが一覧されるようになります2。

image.png

  • Renovateがライブラリ更新を自動検知してくれるので、人間が個別サイトへ確認しにいく手間が減らせます
  • Dependency Dashboardのチェックボックスをクリックすれば、Renovateにそのライブラリの更新PRを作らせることができるので、今までローカルで git commit & git push していた手間も減らせます
  • 組織固有の共通設定がある場合は、細かい設定をいろいろ書かなくてもお決まりのルールを実現できます。弊社だと、サードパーティGitHub Actionsのバージョンをpinしたり、社内コンテナレジストリからのベースイメージ更新に対応したりするルールが共通化されています

更新対象や更新タイミングを完全に人間がコントロールできるので、現状の開発フローを大きく変えることなく、細かい手間の部分だけRenovateへ委譲できるといえます。

ステップ2: PR作成まで任せる

なんとなく雰囲気がわかってくると、チェックボックスをポチポチやってPRを作るのも面倒になってくるでしょう。そうなったら、次はPR作成まで自動でRenovateに任せてしまうのがおすすめです。

GitHub Actionsなど、本番アプリケーションにあまり影響せず、レビュー＆マージするコストも小さいとわかっているものから試してみるとよいでしょう。PRがたくさん作られないか不安な場合は、同時作成数の上限を小さめにして試してみるとよいです。

renovate.json5
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "local>my-org/renovate-config"
  ],
  "baseBranchPatterns": ["develop"],
+ "prConcurrentLimit": 3,
  "packageRules": [
    {
      // すべてのライブラリ更新で、明示的に許可するまでPRを作成しない
      "matchPackageNames": ["*"],
      "dependencyDashboardApproval": true
+   },
+   {
+     // GitHub Actionsの更新は直ちにPRを作成する
+     "matchManagers": ["github-actions"],
+     "dependencyDashboardApproval": false
    }
  ]
}

image.png

もう少しいけそうだねとなったら、アプリケーションの依存ライブラリなども対象に加えてみましょう。例えば、Java系のプロジェクトだとして、Dockerfileのベースイメージも随時PR作成、Gradle管理している依存ライブラリはマイナーバージョンアップまでなら随時PR作成としたい場合は、以下のようになります3。メジャーバージョンアップは破壊的な変更が入ることも多く、リリースノートの確認やDeprecatedへの対応などやることも多いので、最初は除外しておいた方が無難かなと思います。

renovate.json5
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "local>my-org/renovate-config"
  ],
  "baseBranchPatterns": ["develop"],
  "prConcurrentLimit": 3,
  "packageRules": [
    {
      // すべてのライブラリ更新で、明示的に許可するまでPRを作成しない
      "matchPackageNames": ["*"],
      "dependencyDashboardApproval": true
    },
    {
-     // GitHub Actionsの更新は直ちにPRを作成する
-     "matchManagers": ["github-actions"],
+     // GitHub Actions, Dockerfileのイメージ更新は直ちにPRを作成する
+     "matchManagers": ["github-actions", "dockerfile"],
      "dependencyDashboardApproval": false
    },
+   {
+     // Gradle Wrapper自身とGradle管理のライブラリはマイナーアップデートまでは直ちにPRを作成する
+     "matchManagers": ["gradle-wrapper", "gradle"],
+     "matchUpdateTypes": ["minor", "patch"],
+     "dependencyDashboardApproval": false
    }
  ]
}

matchManagers に何が指定できそうかは、Dependency Dashboardの Detected dependencies 欄を見るとわかると思います。ライブラリ単位で細かく条件を設定したいときのパッケージ名もここで確認できます。

image.png

  • Dependency DashboardでチェックボックスをクリックしてPRが上がってくるまで待つ手間を減らせます
  • Renovateが有無を言わさず更新PRを出してくれるので、ともすれば放置しがちなライブラリ更新作業に強制力を働かせることができます（PRを無視し続ける強い心があれば別ですが…）

これで、小さくこまめにライブラリ更新していく第一歩を踏み出したといえます。作成されたPRを放置しすぎないように、がんばってマージしてください。

ステップ3: PR作成の対象を調整する

しばらく運用を続けていると、更新頻度が高すぎて追従するのが大変なライブラリや、semverに従っておらず破壊的な変更を入れてくるライブラリ、既存の自動テストだけでは品質担保があやしいライブラリなど、イレギュラーなものがあることに気づくはずです。チームの運用や歩幅にあわせて、難しいものはわりきって自動PR作成対象から除外しましょう。

私のいるチームだと、jOOQは互換DBバージョンが変わる可能性を懸念して対象外にしたり、AWS SDKが毎日リリースをキメてくるのでさすがに都度追従するのはあきらめたりしています。

renovate.json5
{
  ...（略）
  "packageRules": [
    {
      // すべてのライブラリ更新で、明示的に許可するまでPRを作成しない
      "matchPackageNames": ["*"],
      "dependencyDashboardApproval": true
    },
    {
      // GitHub Actions, Dockerfileのイメージ更新は直ちにPRを作成する
      "matchManagers": ["github-actions", "dockerfile"],
      "dependencyDashboardApproval": false
    },
    {
      // Gradle Wrapper自身とGradle管理のライブラリはマイナーアップデートまでは直ちにPRを作成する
+     // （ただし、jOOQやAWS SDK関連のライブラリを除く）
      "matchManagers": ["gradle-wrapper", "gradle"],
      "matchUpdateTypes": ["minor", "patch"],
+     "matchPackageNames": ["!nu.studer.jooq", "!/^software.amazon.awssdk:/"],
      "dependencyDashboardApproval": false
    }
  ]
}

この調整をしばらく繰り返していくと、RenovateがPRを作ってくれたものは比較的短時間でマージできると自信があるものだけになるはずです。逆に、手間がかかるとわかっているライブラリ更新だけがDependency Dashboardに承認待ちで累積していくので、これらのライブラリ更新を溜めすぎず、いかに定期的に片付けていくかが主戦場になります。

ステップ4: PRマージまで任せる

さて、CIが通ったことを確認して、ただMergeボタンを押すマシーンと化していることに気づいたら、いよいよマージもRenovateに任せるときです。"automerge": true の設定を導入しましょう。

…が、私のプロジェクトはまだその域に達していないので、ここは来年の課題にしたいと思います。

まとめ

長くなってきたので、先にまとめます。

この記事では、Renovateを少しずつ段階的に導入していく方法を説明しました。必ずしもすべてを自動化できなくても、Renovateの豊富な機能を使いこなせなくても、とりあえずGitHub Actionsなど小さなところから始めて、細かいところは運用しながら調整していけそうだな、と思ってもらえたならさいわいです。

落ち穂拾い

Q: ほかにどんな設定をしている？

renovate.json5
{
  ...（略）
+ // RenovateのPRを1つマージするたびに残りのPRがすべてrebaseされてCI時間を消費するので、
+ // コンフリクトしない限りは作成済みのPRはrebaseさせない
+ "rebaseWhen": "conflicted",

+ // Renovateが作ったPRを一覧で識別しやすいように適当なラベルを設定する
+ "labels": ["dependencies"],

+ // コミットメッセージの接頭辞を担当チームのルールにあわせて常に「chore:」固定にする
+ "semanticCommits": "disabled",
+ "commitMessagePrefix": "chore:",

  "packageRules": [

Q: レビューが漏れないか？

二重に対策しています。1つ目は、RenovateがPRを作るときにレビュアーを自動的に設定して、通知がいくようにしている点。2つ目は、未マージのRenovateのPRを定期的に棚卸ししている点です。

renovate.json5
{
  ...（略）
  "packageRules": [
    {
      "matchPackageNames": ["*"],
+     "reviewers": ["developer1", "developer2"],
      "dependencyDashboardApproval": true
    },

for repo in ${REPO1} ${REPO2} ...; do
    gh pr list --repo "$repo" --author app/renovate
done

Q: 頻繁に更新するのつらくない？

新しめのプロダクトを担当していることもあり、ユニットテストをかなりがんばって書いているので、「CIが通ればまぁ大丈夫だろう」という安心感が一定あります。なので、Renovateが自動作成するPRを毎日ベストエフォートでマージしていくのはそこまで大変ではないです。むしろ毎朝のウォーミングアップ作業的な感じになっていて、個人的には結構好きです。

Dependency Dashboardに溜まったその他のライブラリ更新は、2,3ヶ月に1回プロダクトのメジャーバージョンアップにあわせて原則最新化するという方針にしています。こちらも、Renovate導入前から定期的にライブラリ更新する運用ルール自体は根付いていたので、今のところ特に困らずやれているかなと思います。今後何らかの理由で更新できないライブラリが溜まってくると大変になるかもしれません。

Q: Renovate高機能すぎない？あんなことやこんなことできないの？

多分できるので、AIに聞いてください。もはやこの手のタスクは人間よりAIの方が優秀です。そのまま動かなかったとしても、リファレンスで何を検索すべきかのキーワードは入手できるでしょう。

  1. リポジトリのRenovate連携が完了していれば、初期設定用のPRをRenovateがすでに出してくれている可能性が高いです。その場合は、そのPRの内容を書き換えてマージしてあげればOKです。 ↩

  2. 実際には、更新候補のライブラリだけでなく、PR作成済みでマージ待ちのライブラリや、ユーザーがPRをクローズして更新を見送ったライブラリ、Renovateが監視対象として検出しているファイルなど、その他の情報も集約されて表示されます。そのため、最初はIssueをピン留めするなどして定期的にのぞいてみると、Renovateの状態や動作を理解する助けになるでしょう。 ↩

  3. packageRulesは、上から順に評価され、マージしながら後勝ち になります。例えば、GitHub Actionsの更新があった場合、1つ目の条件にマッチしてまず "dependencyDashboardApproval": true となり、2つ目の条件にマッチすることで "dependencyDashboardApproval": false に上書きされます。同じ設定値しか使っていないので分かりづらいですが、1つ目の条件に "automerge": true など別の設定がある場合は、2つ目の条件の方で上書きしない限りその設定は残ったままになるので注意が必要です。 ↩

12
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
12
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?