ソフトウェアの依存関係アップデートはRenovateにした理由
ソフトウェアの依存関係アップデートはRenovateにした理由
DBREグループで、DevSecOps担当を自称している栗原です。
タイトルの通り、ソフトウェア依存モジュールのアップデートにRenovateを採用しました。GitHub Dependabotと迷い続けましたが、この記事で紹介するDependabotにはない3つの利点が非常に魅力的だったため、Renovateを採用するにいたりました。Renovateを紹介している記事はよく見かけるので、あまり語られていないおすすめの実行方法についてと、私が惹かれた3つのポイントについて説明します。
Renovateとは
Renovateは、ソフトウェアの依存関係を自動でアップデートしてくれるOSSツールです。Dependabotと同様に、リポジトリのルートに設定ファイル（renovate.json）を配置して、Renovateを実行すると、依存関係のアップデートPRを自動で送ってくれます。
2026年3月現在は無料で利用可能ですが、Mend社による買収後、将来的に有償化される可能性がある点は留意しておく必要があります。ただし、現時点ではOSSとして活発に開発が続いており、セルフホスティングも可能なため、柔軟な運用が可能です。
類似機能である、Dependabotとの詳細比較は公式のbot比較ページに譲りますが、Dependabotより高機能なのは間違いないです。個人的には設定の柔軟性が圧倒的に高く、複数リポジトリでの設定の共通化など、エンタープライズでの利用に適していると感じています。
ちなみに、この記事ではSCMはGitHubであることを前提にしておりますが、GitLabなど他のSCMを使われている方にも参考になるかと思います。
おすすめの実行方法
他社さんの記事などをみかけると、Mend Renovate App（一番手っ取り早い）、公式のGitHub Actionsが紹介されていることが多いですが、私がおすすめしたいのは、CLIでの実行です。
Renovateは依存定義ファイル（package.json）だけではなく、lockfile（package-lock.json）も更新してくれますが、その際に実行環境にインストールされているパッケージマネージャ（npm）を実行して実現します。つまり実際の開発環境と同じツールを使えるのがベストなわけです。前者の2つは、プレビルドされた環境はあるものの、厳密にやろうとすると、Renovate実行用のコンテナをカスタマイズするなどが必要ですが、CLI実行であれば、他のワークフローで使っている環境セットアップの処理がそのまま転用できます。
特に我々はMonorepoを採用しており、複数の言語、パッケージマネージャ（Go、Python uv、Node.js yarn等）を使っているプロジェクトでは、それぞれのツールのバージョンを揃える必要があるため、CLI実行の恩恵が大きいです。
こちらは実際に我々が使っているGitHub Actionsです。
name: Update Deps Via Renovate
on:
schedule:
- cron: '0 * * * *'
workflow_dispatch:
concurrency:
group: "${{ github.event.repository.name }}-update-deps-via-renovate"
cancel-in-progress: false
env:
LOG_LEVEL: ${{ vars.RENOVATE_LOG_LEVEL || '' }}
jobs:
renovate:
runs-on: ubuntu-latest
steps:
# 他のワークフローとも共通化しているセットアッププロセス
- name: checkout codebase and setup runtime
id: setup-runtime
uses: kinto-dev/action-dbre-setup-runtime@v3
with:
# 後ほど紹介しますが、共通renovate設定ファイルを利用するため、
# 通常のGITHUB_TOKENではなく、GitHub Appのインストールアクセストークンを利用
github-app-id: ${{ vars.GH_APP_ID }}
github-app-private-key: ${{ secrets.GH_APP_PRIVATE_KEY }}
go-project: "true"
python-uv-project: "true"
# GitHub Actionsであれば、Node.jsランタイムがデフォルトでインストールされているので、npxで直接renovateを実行可能。
- name: run renovate
run: npx --yes --package renovate -- --token="${{ steps.setup-runtime.outputs.github-app-install-token }}" "${{ github.repository }}"
以上がおすすめの実行方法です。それでは次章からおすすめの機能を紹介していきます。
おすすめ機能1: インラインスクリプトもアップデートの対象にできる
Dependabotでは基本的に設定ファイル（package.jsonやgo.mod等）に定義された依存関係のみがアップデート対象になりますが、RenovateはCustom Manager機能により、正規表現でマッチさせた任意の文字列をアップデート対象にできます。
例えば、以下のようにnpm scriptとしてDocker Hubのイメージをタグ指定して実行しているケースを考えてみます。
// package.json
{
"scripts": {
"gha_lint": "docker run -i --init --rm -v $INIT_CWD/.github/workflows:/workflows rhysd/actionlint:1.7.7 -color $(ls .github/workflows/*.yml | awk -F '/' '{print \"/workflows/\"$NF}')"
}
}
このようなインラインスクリプトに依存モジュールのバージョンがハードコードされるケースも、Renovateはアップデートの対象にしてくれます。renovate.jsonに以下の設定を追加するだけで実現できます。
"customManagers": [
{
"customType": "regex",
"fileMatch": [
"^package\\.json$"
],
"matchStrings": [
"docker run [^;]*? (?<depName>[^:\\s]+):(?<currentValue>[^\\s]+)"
],
"datasourceTemplate": "docker",
"versioningTemplate": "docker",
"depTypeTemplate": "shell-script-docker-inline"
}
]
この設定により、rhysd/actionlint:1.7.7の部分が検出され、新しいバージョンがリリースされると自動でPRが作成されます。正規表現でマッチングするため、Dockerfile、シェルスクリプト、CI/CDの設定ファイルなど、あらゆるファイルに対して適用可能です。Dependabotではカバーできない領域まで自動アップデートの対象にできるのは、運用負荷の軽減に大きく貢献します。
おすすめ機能2: ローカルで設定ファイルをデバッグできる
アップデートPRのグルーピングなど、ファインチューニングをしようと思うと、設定ファイルのトライアンドエラーがつらいです。これはDependabotでも同じだと思いますが、Renovateは開発PCでも動かせるCLIがあるため、手元でカジュアルに設定ファイルとにらめっこが可能です。
$ LOG_LEVEL=debug npx renovate --platform=local --dry-run=full | tee renovate-dryrun.txt
この--dry-runオプションを使うと、実際にPRを作成せずに、どのような更新が検出されるかをローカルで確認できます。設定を変更して即座に結果を確認できるため、トライアンドエラーのサイクルが非常に高速です。
設定ファイルのvalidatorも付随しています。
$ npx --yes --package renovate -- renovate-config-validator
このコマンドで、renovate.jsonの構文エラーや設定の妥当性をチェックできます。CI/CDに組み込んでおけば、設定ミスによる実行エラーを事前に防ぐことができます。
えっ...しょぼくない？と思われたかもしれませんが、Dependabotの場合は設定を変更するたびにGitHubにpushして結果を待つ必要があり、フィードバックループが長いです。Renovateはローカルで即座に確認できるため、スピーディーに設定ファイルを完成させることができました。個人的には大きなメリットであると考えます。
おすすめ機能3: 設定ファイルを共通化できる
苦労して完成させた設定ファイルをSSOT（Single Source of Truth）にしたいですよね。RenovateにはConfig Presetsという、設定ファイルの共通化機能があります。
共通設定リポジトリにdefault.jsonを配置し、そこにベースとなる設定を記述します。例えば、PRのラベル設定、スケジュール設定、グルーピングルールなど、組織として統一したい設定をまとめておきます。
利用側の設定ファイルはこれだけで済みます。
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["github>kinto-dev/dbre-renovate-config"]
}
github>プレフィックスでGitHubリポジトリを指定するだけで、共通設定を読み込むことができます。ブランチやタグを指定することも可能です（例: github>kinto-dev/dbre-renovate-config#v1.0.0）。
もちろん、利用側リポジトリ特有の設定を拡張することもできます。
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["github>kinto-dev/dbre-renovate-config"],
"ignorePaths": [
"backup/**"
]
}
この機能により、複数リポジトリで共通の設定を使いつつ、各リポジトリ固有の要件にも対応できます。組織で管理するリポジトリが増えれば増えるほど、この機能の恩恵は大きくなります。
まとめ
以上、Renovateのおすすめの実行方法と、Dependabotにはない3つの魅力的な機能を紹介させていただきました！
改めてまとめると以下の通りです。
- CLI実行で開発環境と同じツールを使える - 既存のCI/CDワークフローを流用できる
- インラインスクリプトもアップデート対象にできる - Custom Managerで正規表現マッチング
- ローカルでデバッグできる - 高速なフィードバックループで設定を洗練できる
- 設定ファイルを共通化できる - 複数リポジトリで一貫した運用が可能
最近全部AIでいいんじゃないかと思うことも多々ありますが、決められた定型作業であれば非AIツールもまだまだ有益だと信じて、ツールボックスを拡充していければと思います。お読みいただきありがとうございます。
関連記事 | Related Posts
イベント情報
![[Mirror]不確実な事業環境を突破した、成長企業6社独自のエンジニアリング](/assets/banners/thumb1.png)
