Renovate 依赖自动升级治理实战指南

欢迎你来读这篇博客，这篇博客主要是关于 Renovate 的工程化落地。

它不是“又一个自动发 PR 的机器人”这么简单。更准确地说，Renovate 是一个依赖升级治理系统：它可以扫描项目中的 Maven、Gradle、npm、Docker、GitHub Actions、GitLab CI、Kubernetes、Helm 等依赖声明文件，发现新版本后自动创建 PR/MR，并通过配置规则控制升级节奏、分组策略、自动合并、安全窗口和私服认证。

序言

项目越做越久，依赖越堆越多，pom.xml、build.gradle、package.json、Dockerfile、docker-compose.yml、.github/workflows/*.yml 这些文件很容易变成“祖传配置现场”。

依赖不升级，会带来几个常见问题：

安全漏洞长期存在；
小版本不跟，最后只能硬啃大版本；
框架升级成本越来越高，比如 Spring Boot、Spring Cloud、MyBatis、Lombok、MapStruct；
Docker 基础镜像、GitHub Actions、CI 插件版本长期落后；
团队没人愿意专门盯依赖版本，因为这活儿脏、碎、还容易背锅。

Renovate 的价值就在这里：它把“发现新版本、修改版本号、更新 lock 文件、提交 PR”这部分重复劳动自动化，让人只需要关注：能不能合并、有没有破坏兼容、是否符合团队升级策略。

简单说：

Renovate 负责把依赖升级这件事从“靠人想起来”变成“靠规则持续运行”。

正文

chapter 1：Renovate 是什么？

Renovate 是 Mend 旗下的开源依赖自动升级工具，常被称为 Renovate Bot。它会扫描代码仓库中的依赖文件，识别当前使用的依赖版本，并到对应的数据源或包仓库中查询是否有新版本。如果发现可升级版本，Renovate 会自动创建 Pull Request 或 Merge Request。

官方对它的定位是：

Automated dependency updates. Multi-platform and multi-language.

也就是：自动化依赖升级，支持多平台、多语言。

它支持的代码平台包括但不限于：

GitHub / GitHub Enterprise Server
GitLab / GitLab Self-Managed
Bitbucket Cloud / Bitbucket Server
Azure DevOps
AWS CodeCommit
Gitea
Forgejo
Gerrit，部分能力仍带实验性质

它支持的依赖生态非常多，例如：

Java：Maven、Gradle、Gradle Wrapper、Maven Wrapper
JavaScript：npm、pnpm、yarn、bun
Docker：Dockerfile、Docker Compose、DevContainer、Kubernetes YAML 中的镜像
CI/CD：GitHub Actions、GitLab CI、CircleCI、Azure Pipelines、Jenkins 等
IaC：Terraform、Terragrunt、Helm、Kustomize、Ansible 等
其他：Go Modules、Python pip/Poetry、NuGet、Ruby Bundler、Rust Cargo 等

1.1 Renovate 的核心工作流程

flowchart LR
    A[代码仓库] --> B[Renovate 扫描依赖文件]
    B --> C[识别 Manager]
    C --> D[查询 Datasource]
    D --> E{是否存在新版本}
    E -- 否 --> F[结束本轮扫描]
    E -- 是 --> G[应用 renovate.json 规则]
    G --> H[创建 Branch]
    H --> I[更新依赖声明和 lock 文件]
    I --> J[创建 PR / MR]
    J --> K[触发 CI]
    K --> L{CI 是否通过}
    L -- 否 --> M[等待人工处理]
    L -- 是 --> N{是否允许自动合并}
    N -- 否 --> O[人工 Review 后合并]
    N -- 是 --> P[自动合并]

这里有几个关键词：

概念	含义
Manager	负责识别某类依赖文件的模块，比如 Maven manager、Gradle manager、Dockerfile manager
Datasource	版本来源，比如 Maven Central、npm registry、Docker registry、GitHub releases
Versioning	版本比较规则，比如 SemVer、Maven、Gradle、Docker loose versioning
Package Rules	针对不同依赖设置不同升级策略
Dependency Dashboard	Renovate 创建的依赖升级看板 Issue，用来集中展示 pending/open/error 状态
Automerge	在满足条件时自动合并依赖升级 PR

chapter 2：Renovate 能解决什么问题？

2.1 让依赖升级变得持续化

没有 Renovate 之前，很多团队的依赖升级路径是这样的：

flowchart LR
    A[依赖长期不动] --> B[安全扫描报警]
    B --> C[临时升级]
    C --> D[发现大面积不兼容]
    D --> E[修不完]
    E --> F[延期或跳过]

用了 Renovate 之后，更推荐的路径是：

flowchart LR
    A[每周扫描依赖] --> B[小版本 PR]
    B --> C[CI 自动验证]
    C --> D[低风险更新自动合并]
    D --> E[高风险更新人工 Review]
    E --> F[依赖持续保持较新]

核心思想是：

小步快跑地升级，比一年升级一次全家桶舒服得多。

这就像你每天扫一下地，远比年底拿大锤拆地板轻松。虽然比喻粗暴，但工程上基本如此。

2.2 降低安全风险

依赖长期不升级，很容易积累 CVE、安全补丁和供应链风险。Renovate 不等同于漏洞扫描工具，但它可以配合 GitHub Dependabot Alerts、Snyk、Mend、SonarQube、Trivy、Grype 等工具，把安全更新纳入 PR 流程。

常见策略是：

普通 patch/minor 更新：固定时间窗口创建 PR；
安全更新：随时创建 PR；
高风险 major 更新：不自动合并，必须人工 Review；
Docker digest 更新：CI 通过后可以自动合并；
测试依赖、构建插件：可以更激进一点；
核心框架依赖：保持保守。

2.3 减少 PR 噪音

Renovate 最有价值的地方不是“能自动提 PR”，而是“能控制怎么提 PR”。

比如一个 Spring Boot 项目里有这些依赖：

<spring-boot.version>3.5.0</spring-boot.version>
<spring-cloud.version>2025.0.0</spring-cloud.version>
<mapstruct.version>1.6.3</mapstruct.version>
<lombok.version>1.18.36</lombok.version>
<postgresql.version>42.7.4</postgresql.version>

如果每个依赖都单独一个 PR，开发者会很快疲劳。

Renovate 可以按规则合并：

Spring Boot 相关依赖合成一个 PR；
Spring Cloud 相关依赖合成一个 PR；
测试依赖合成一个 PR；
Maven 插件合成一个 PR；
Docker 镜像合成一个 PR；
GitHub Actions 合成一个 PR。

这样 Review 成本会低很多。

chapter 3：Renovate 和 Dependabot 的区别

Dependabot 和 Renovate 都能做依赖升级，但定位和配置能力不同。

对比项	Dependabot	Renovate
所属生态	GitHub 官方体验更强	Mend 维护，开源核心
配置复杂度	简单	更复杂，但更强
支持平台	GitHub 最顺	GitHub、GitLab、Bitbucket、Azure DevOps、Gitea 等
分组能力	有，但相对有限	非常强，`packageRules` 很灵活
自托管	能力相对有限	非常适合企业自托管
私服支持	能支持，但复杂场景受限	适合 Nexus、Artifactory、私有 Docker Registry 等
Monorepo	可用	更适合复杂 Monorepo
Docker / CI / IaC	支持一部分	支持范围更广
自动合并策略	可做	更细粒度
推荐场景	GitHub 上的小中型项目	企业项目、多语言、多仓库、私服、复杂治理

我的建议是：

如果你的项目只在 GitHub 上，依赖结构简单，用 Dependabot 可以；
如果你有 Java 后端、多模块、Docker、GitLab、私服、CI 插件、内部依赖治理，Renovate 更合适；
如果你想把依赖升级做成“工程治理能力”，Renovate 基本更顺手。

chapter 4：Renovate 的配置文件

Renovate 的仓库级配置通常放在：

renovate.json
renovate.jsonc
renovate.json5
.github/renovate.json
.github/renovate.jsonc
.gitlab/renovate.json
.gitlab/renovate.jsonc
.renovaterc
.renovaterc.json
.renovaterc.jsonc

最常见的是项目根目录下的 renovate.json。

4.1 最小配置

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"]
}

这个配置会启用官方推荐配置。

如果你希望更偏向生产最佳实践，可以用：

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:best-practices"]
}

4.2 推荐的基础配置

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "timezone": "Asia/Singapore",
  "dependencyDashboard": true,
  "labels": ["dependencies", "renovate"],
  "schedule": ["before 8am on monday"],
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "rangeStrategy": "bump",
  "semanticCommits": "enabled"
}

配置解释：

配置	作用
`$schema`	让 IDE 能提示 Renovate 配置字段
`extends`	继承官方或团队预设
`timezone`	设置时间区，避免 schedule 按默认时区跑偏
`dependencyDashboard`	创建依赖升级看板 Issue
`labels`	给 Renovate PR 加标签
`schedule`	控制创建 PR 的时间
`prConcurrentLimit`	限制同时打开的 PR 数量
`prHourlyLimit`	限制每小时创建 PR 数量
`rangeStrategy`	控制版本范围如何修改
`semanticCommits`	使用语义化 commit 信息

chapter 5：核心配置详解

5.1 extends：继承预设

extends 类似 ESLint 的 preset，用来复用一组配置。

常见写法：

{
  "extends": [
    "config:recommended",
    "group:monorepos",
    "docker:pinDigests"
  ]
}

常用预设说明：

预设	说明
`config:recommended`	官方推荐配置，适合大多数仓库起步
`config:best-practices`	更偏最佳实践，适合希望治理更严格的团队
`group:monorepos`	将同一 monorepo 来源的依赖合并升级
`docker:pinDigests`	Docker 镜像固定 digest，提升构建可复现性
`default:automergeDigest`	自动合并 digest 更新
`schedule:weekly`	每周执行升级
`:disableDependencyDashboard`	关闭 Dependency Dashboard

5.2 packageRules：Renovate 的灵魂配置

packageRules 是 Renovate 的核心能力。它可以按包名、manager、datasource、更新类型、依赖类型、文件路径等维度设置不同规则。

示例：

{
  "packageRules": [
    {
      "description": "Spring Boot 单独分组，不自动合并",
      "matchPackageNames": ["/^org\\.springframework\\.boot:/"],
      "groupName": "Spring Boot dependencies",
      "automerge": false
    },
    {
      "description": "测试依赖 patch 更新自动合并",
      "matchDepTypes": ["test"],
      "matchUpdateTypes": ["patch"],
      "automerge": true
    }
  ]
}

常见匹配条件：

字段	作用
`matchPackageNames`	按依赖名称匹配
`matchManagers`	按 manager 匹配，比如 `maven`、`gradle`、`dockerfile`
`matchDatasources`	按 datasource 匹配，比如 `maven`、`docker`、`npm`
`matchUpdateTypes`	匹配更新类型，比如 `major`、`minor`、`patch`、`digest`
`matchDepTypes`	匹配依赖类型，比如 Maven 的 `compile`、`test`、`build`
`matchFileNames`	按文件路径匹配
`groupName`	将多个依赖合并到同一个 PR
`automerge`	是否自动合并
`enabled`	是否启用某类依赖升级
`schedule`	某类依赖单独设置升级时间

5.3 schedule：控制 PR 创建时间

如果不限制，Renovate 可能在任何时间创建 PR。企业项目里建议限制在工作日早上，避免下班后 CI 噪音满天飞。

示例：

{
  "timezone": "Asia/Singapore",
  "schedule": ["before 8am on monday"]
}

也可以按不同依赖单独设置：

{
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "schedule": ["before 8am on the first day of the month"]
    },
    {
      "matchUpdateTypes": ["patch"],
      "schedule": ["before 8am every weekday"]
    }
  ]
}

推荐策略：

更新类型	推荐频率
patch	每天或每周
minor	每周
major	每月或人工触发
security	随时
Docker digest	每天或每周
CI Action	每周

5.4 automerge：自动合并

自动合并不是“闭眼合并”。正确姿势是：

只有低风险更新 + CI 通过 + 分支保护规则满足，才自动合并。

示例：

{
  "packageRules": [
    {
      "description": "自动合并 patch 更新",
      "matchUpdateTypes": ["patch"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "description": "禁止 major 自动合并",
      "matchUpdateTypes": ["major"],
      "automerge": false
    }
  ]
}

更保守一点：

{
  "packageRules": [
    {
      "description": "只自动合并测试依赖 patch 更新",
      "matchDepTypes": ["test"],
      "matchUpdateTypes": ["patch"],
      "automerge": true
    }
  ]
}

生产建议：

核心运行时依赖不要一上来就自动合并；
测试依赖、文档工具、Lint 工具、CI Action 可以逐步放开；
自动合并必须依赖稳定 CI；
没有单元测试的项目，不要急着开 automerge，否则机器人会很勤快地帮你把坑合进去。

5.5 minimumReleaseAge：等待新版本稳定

minimumReleaseAge 用来要求新版本发布一段时间后，Renovate 才认为它稳定。

例如 npm 包可以设置等待 3 天：

{
  "packageRules": [
    {
      "matchDatasources": ["npm"],
      "minimumReleaseAge": "3 days"
    }
  ]
}

对于 Java 项目，也可以对非核心依赖设置稳定窗口：

{
  "packageRules": [
    {
      "matchDatasources": ["maven"],
      "minimumReleaseAge": "3 days"
    }
  ]
}

这个配置适合规避“刚发版就撤回、刚发版就发现严重 bug”的情况。

5.6 dependencyDashboard：依赖升级看板

开启后，Renovate 会创建一个 Issue，集中展示：

等待创建的 PR；
已打开的 PR；
已关闭但未合并的 PR；
查询失败的依赖；
被规则暂时阻塞的升级；
需要人工批准的升级。

推荐开启：

1
2
3

{
  "dependencyDashboard": true
}

如果团队觉得 Issue 太吵，也可以关闭：

1
2
3

{
  "extends": ["config:recommended", ":disableDependencyDashboard"]
}

chapter 6：Java / Maven 项目实战

6.1 场景说明

假设我们有一个 Spring Boot 3.x 后端项目：

finance-service
├── pom.xml
├── Dockerfile
├── docker-compose.yml
├── .github
│   └── workflows
│       └── ci.yml
└── src
    └── main

依赖包括：

Spring Boot
Spring Cloud
Spring Cloud Alibaba
MyBatis-Plus
PostgreSQL Driver
Lombok
MapStruct
JUnit
Testcontainers
Maven 插件
Docker 基础镜像
GitHub Actions

目标：

Spring Boot / Spring Cloud 相关依赖分组升级；
大版本不自动合并；
测试依赖 patch 更新可以自动合并；
Docker digest 更新可以自动合并；
每周一早上创建普通依赖升级 PR；
私服依赖走 Nexus；
PR 数量不能炸。

6.2 Maven 示例 pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.5.0</version>
        <relativePath/>
    </parent>

    <groupId>com.example</groupId>
    <artifactId>finance-service</artifactId>
    <version>1.0.0-SNAPSHOT</version>

    <properties>
        <java.version>21</java.version>
        <mapstruct.version>1.6.3</mapstruct.version>
        <lombok.version>1.18.36</lombok.version>
        <mybatis-plus.version>3.5.12</mybatis-plus.version>
        <testcontainers.version>1.20.6</testcontainers.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>mybatis-plus-spring-boot3-starter</artifactId>
            <version>${mybatis-plus.version}</version>
        </dependency>

        <dependency>
            <groupId>org.mapstruct</groupId>
            <artifactId>mapstruct</artifactId>
            <version>${mapstruct.version}</version>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>${lombok.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.testcontainers</groupId>
            <artifactId>postgresql</artifactId>
            <version>${testcontainers.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Renovate 的 Maven manager 默认会扫描：

pom.xml
pom.template.xml
settings.xml
.mvn/extensions.xml

也就是说，对于标准 Maven 项目，不需要手动告诉 Renovate 去看 pom.xml。

6.3 Maven 项目推荐 renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "group:monorepos",
    "docker:pinDigests"
  ],
  "timezone": "Asia/Singapore",
  "dependencyDashboard": true,
  "labels": ["dependencies", "renovate"],
  "schedule": ["before 8am on monday"],
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "rangeStrategy": "bump",
  "semanticCommits": "enabled",
  "packageRules": [
    {
      "description": "Spring Boot 相关依赖统一升级，禁止自动合并",
      "matchManagers": ["maven"],
      "matchPackageNames": ["/^org\\.springframework\\.boot:/"],
      "groupName": "Spring Boot dependencies",
      "labels": ["dependencies", "spring-boot"],
      "automerge": false
    },
    {
      "description": "Spring Framework 相关依赖统一升级",
      "matchManagers": ["maven"],
      "matchPackageNames": ["/^org\\.springframework:/"],
      "groupName": "Spring Framework dependencies",
      "labels": ["dependencies", "spring"],
      "automerge": false
    },
    {
      "description": "Spring Cloud Alibaba 相关依赖统一升级",
      "matchManagers": ["maven"],
      "matchPackageNames": ["/^com\\.alibaba\\.cloud:/"],
      "groupName": "Spring Cloud Alibaba dependencies",
      "labels": ["dependencies", "spring-cloud-alibaba"],
      "automerge": false
    },
    {
      "description": "MyBatis / MyBatis-Plus 相关依赖统一升级",
      "matchManagers": ["maven"],
      "matchPackageNames": ["/^org\\.mybatis:/", "/^com\\.baomidou:/"],
      "groupName": "MyBatis dependencies",
      "labels": ["dependencies", "mybatis"],
      "automerge": false
    },
    {
      "description": "Lombok 和 MapStruct 分组升级，需要人工 Review",
      "matchManagers": ["maven"],
      "matchPackageNames": [
        "org.projectlombok:lombok",
        "/^org\\.mapstruct:/"
      ],
      "groupName": "Annotation processors",
      "labels": ["dependencies", "annotation-processor"],
      "automerge": false
    },
    {
      "description": "测试依赖 patch 更新自动合并",
      "matchManagers": ["maven"],
      "matchDepTypes": ["test"],
      "matchUpdateTypes": ["patch"],
      "groupName": "Test dependencies patch updates",
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "description": "Maven 插件分组升级",
      "matchManagers": ["maven"],
      "matchDepTypes": ["build"],
      "groupName": "Maven build plugins",
      "labels": ["dependencies", "maven-plugin"],
      "automerge": false
    },
    {
      "description": "禁止 major 自动合并",
      "matchUpdateTypes": ["major"],
      "labels": ["major-upgrade"],
      "automerge": false
    },
    {
      "description": "Maven 依赖增加 3 天稳定等待期",
      "matchDatasources": ["maven"],
      "minimumReleaseAge": "3 days"
    },
    {
      "description": "Docker digest 更新自动合并",
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["digest"],
      "groupName": "Docker digest updates",
      "automerge": true,
      "automergeType": "pr"
    }
  ]
}

6.4 为什么 Spring Boot 不建议一开始自动合并？

Spring Boot 小版本更新通常比较稳，但它牵涉面大：

Spring Framework
Spring Security
Jackson
Tomcat / Jetty / Undertow
Micrometer
Hibernate Validator
Spring Data
自动配置行为
配置属性变更

所以建议：

patch 可以考虑 CI 稳定后逐步自动合并；
minor 建议人工 Review；
major 必须人工升级和回归；
Spring Boot、Spring Cloud、Spring Cloud Alibaba 的兼容矩阵要单独核对。

工程里最怕的不是升级失败，而是“升级成功但线上行为悄悄变了”。这类问题最烦，像 NPE 一样安静，但不讲武德。

chapter 7：Gradle 项目实战

7.1 Gradle 能更新哪些文件？

Renovate 的 Gradle manager 默认会扫描：

*.gradle
*.gradle.kts
gradle.properties
gradle/*.toml
buildSrc/**/*.kt
*.versions.toml
versions.props
versions.lock

Gradle Wrapper manager 会扫描：

1	`gradle/wrapper/gradle-wrapper.properties`

7.2 Gradle Version Catalog 示例

gradle/libs.versions.toml：

[versions]
spring-boot = "3.5.0"
mapstruct = "1.6.3"
lombok = "1.18.36"
postgresql = "42.7.4"

[libraries]
spring-boot-starter-web = { module = "org.springframework.boot:spring-boot-starter-web", version.ref = "spring-boot" }
mapstruct = { module = "org.mapstruct:mapstruct", version.ref = "mapstruct" }
lombok = { module = "org.projectlombok:lombok", version.ref = "lombok" }
postgresql = { module = "org.postgresql:postgresql", version.ref = "postgresql" }

[plugins]
spring-boot = { id = "org.springframework.boot", version.ref = "spring-boot" }

7.3 Gradle 推荐 renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", "group:monorepos"],
  "timezone": "Asia/Singapore",
  "dependencyDashboard": true,
  "schedule": ["before 8am on monday"],
  "prConcurrentLimit": 5,
  "packageRules": [
    {
      "description": "Gradle Wrapper 每月升级一次",
      "matchManagers": ["gradle-wrapper"],
      "schedule": ["before 8am on the first day of the month"],
      "groupName": "Gradle Wrapper",
      "automerge": false
    },
    {
      "description": "Gradle 插件统一升级",
      "matchManagers": ["gradle"],
      "matchDepTypes": ["plugin"],
      "groupName": "Gradle plugins",
      "automerge": false
    },
    {
      "description": "测试依赖 patch 更新自动合并",
      "matchManagers": ["gradle"],
      "matchDepTypes": ["test"],
      "matchUpdateTypes": ["patch"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "description": "生产依赖禁止 major 自动合并",
      "matchManagers": ["gradle"],
      "matchUpdateTypes": ["major"],
      "automerge": false
    }
  ]
}

7.4 Gradle Wrapper 的安全注意点

Renovate 的 Gradle manager 本身使用 JavaScript parser 提取依赖，不会默认执行 gradle。但在某些更新 lockfile 或 verification metadata 的场景中，可能需要执行 Gradle Wrapper。官方文档强调，执行 Gradle Wrapper 存在供应链安全风险，因此自托管管理员需要明确允许相关执行能力。

生产建议：

先只让 Renovate 修改依赖声明；
lockfile 更新放在 CI 环境里验证；
如果允许执行 wrapper，要控制执行环境和网络权限；
只对可信仓库开启相关能力。

chapter 8：Docker / Docker Compose 实战

8.1 Dockerfile 示例

FROM eclipse-temurin:21-jre

WORKDIR /app
COPY target/finance-service.jar app.jar

ENTRYPOINT ["java", "-jar", "app.jar"]

Renovate 可以识别 eclipse-temurin:21-jre 是否有更新。

8.2 docker-compose.yml 示例

services:
  postgres:
    image: postgres:17.4
    environment:
      POSTGRES_DB: finance
      POSTGRES_USER: finance
      POSTGRES_PASSWORD: finance
    ports:
      - "5432:5432"

  redis:
    image: redis:7.4
    ports:
      - "6379:6379"

Docker Compose manager 默认会匹配：

docker-compose.yml
docker-compose.yaml
compose.yml
compose.yaml

8.3 Docker 推荐配置

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "docker:pinDigests"
  ],
  "timezone": "Asia/Singapore",
  "schedule": ["before 8am on monday"],
  "packageRules": [
    {
      "description": "Docker 镜像统一分组",
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["minor", "patch", "digest"],
      "groupName": "Docker image updates",
      "labels": ["dependencies", "docker"]
    },
    {
      "description": "Docker major 更新不自动合并",
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["major"],
      "labels": ["docker-major"],
      "automerge": false
    },
    {
      "description": "Docker digest 更新自动合并",
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["digest"],
      "automerge": true,
      "automergeType": "pr"
    }
  ]
}

8.4 为什么推荐 Docker digest？

Docker tag 不是绝对不可变的。即使是 postgres:17.4，理论上镜像内容也可能变化。Digest 则是内容寻址，更适合可复现构建。

开启 docker:pinDigests 后，Renovate 可以把镜像变成类似这样：

1	`FROM eclipse-temurin:21-jre@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`

这样做的好处：

构建更可复现；
镜像变化会通过 PR 显式暴露；
CI/CD 不会因为 tag 被覆盖而突然行为变化；
安全扫描和审计更清晰。

chapter 9：GitHub Actions 实战

9.1 workflow 示例

.github/workflows/ci.yml：

name: CI

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '21'
      - name: Build
        run: mvn -B clean verify

Renovate 可以升级：

1 2	`uses: actions/checkout@v4 uses: actions/setup-java@v4`

也可以处理部分 with: 中的工具版本，例如 setup-node、setup-go、setup-python 等常见 Action 的版本字段。

9.2 GitHub Actions 推荐配置

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "helpers:pinGitHubActionDigests"
  ],
  "timezone": "Asia/Singapore",
  "packageRules": [
    {
      "description": "GitHub Actions 统一分组",
      "matchManagers": ["github-actions"],
      "groupName": "GitHub Actions",
      "labels": ["dependencies", "github-actions"],
      "schedule": ["before 8am on monday"],
      "automerge": false
    },
    {
      "description": "GitHub Actions patch 更新自动合并",
      "matchManagers": ["github-actions"],
      "matchUpdateTypes": ["patch", "digest"],
      "automerge": true,
      "automergeType": "pr"
    }
  ]
}

生产建议：

CI Action 更新通常风险比业务依赖低；
但 setup-java、docker/build-push-action、云厂商登录 Action 仍要谨慎；
对发布链路 Action，不建议一上来自动合并；
对 actions/checkout、cache、setup-node 这类成熟 Action，可以逐步自动化。

chapter 10：GitLab 自托管实战

很多公司代码放在自建 GitLab，依赖放在 Nexus / Artifactory，镜像放在 Harbor。这种情况下，推荐自托管 Renovate。

10.1 自托管 Renovate 的配置分层

Renovate 有两类配置：

配置类型	位置	作用
仓库配置	项目内 `renovate.json`	控制当前仓库的依赖升级规则
Bot/Admin 配置	`config.js`、环境变量、CLI 参数	控制平台 token、仓库列表、私服凭证、自托管行为

注意：

自托管专用配置不要写进仓库里的 renovate.json，否则 Renovate 可能忽略它们，甚至创建配置错误 Issue。

10.2 GitLab 自托管 config.js

module.exports = {
  platform: 'gitlab',
  endpoint: 'https://gitlab.company.com/api/v4/',
  token: process.env.RENOVATE_TOKEN,
  onboarding: true,
  requireConfig: 'optional',
  repositories: [
    'backend/finance-service',
    'backend/order-service'
  ],
  gitAuthor: 'Renovate Bot <renovate-bot@company.com>',
  hostRules: [
    {
      hostType: 'maven',
      matchHost: 'https://nexus.company.com/repository/maven-public/',
      username: process.env.NEXUS_USERNAME,
      password: process.env.NEXUS_PASSWORD
    },
    {
      hostType: 'docker',
      matchHost: 'harbor.company.com',
      username: process.env.HARBOR_USERNAME,
      password: process.env.HARBOR_PASSWORD
    },
    {
      hostType: 'github-tags',
      matchHost: 'github.com',
      token: process.env.GITHUB_COM_TOKEN
    }
  ]
};

说明：

RENOVATE_TOKEN 是访问 GitLab API 的机器人账号 token；
NEXUS_USERNAME/NEXUS_PASSWORD 用于 Maven 私服查询；
HARBOR_USERNAME/HARBOR_PASSWORD 用于 Docker 私有镜像仓库查询；
GITHUB_COM_TOKEN 常用于查询 GitHub changelog / releases，避免限流；
密码不要写死到代码里，统一走 CI/CD 变量或 Secret 管理。

10.3 Docker 方式运行 Renovate

docker run --rm \
  -v "$PWD/config.js:/usr/src/app/config.js" \
  -e RENOVATE_TOKEN="$RENOVATE_TOKEN" \
  -e NEXUS_USERNAME="$NEXUS_USERNAME" \
  -e NEXUS_PASSWORD="$NEXUS_PASSWORD" \
  -e HARBOR_USERNAME="$HARBOR_USERNAME" \
  -e HARBOR_PASSWORD="$HARBOR_PASSWORD" \
  -e GITHUB_COM_TOKEN="$GITHUB_COM_TOKEN" \
  renovate/renovate

10.4 GitLab CI 定时运行 Renovate

可以建一个专门的仓库，例如：

1
2
3

platform/renovate-runner
├── config.js
└── .gitlab-ci.yml

.gitlab-ci.yml：

stages:
  - renovate

renovate:
  stage: renovate
  image: renovate/renovate:latest
  variables:
    LOG_LEVEL: info
  script:
    - renovate
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'

然后在 GitLab UI 里配置 Schedule，例如每天早上 6 点运行。

生产建议：

不要在每个业务仓库都放一个 Renovate Job；
建议集中放一个 renovate-runner 仓库；
仓库列表放在 config.js 或通过自动发现配置；
机器人账号权限最小化，通常需要读仓库、写分支、创建 MR、评论 Issue/MR；
企业场景下建议先从 2-3 个低风险仓库试点。

chapter 11：私服 Nexus / Artifactory 实战

11.1 为什么私服场景容易踩坑？

企业 Java 项目经常配置 Maven 私服：

<repositories>
    <repository>
        <id>company-maven-public</id>
        <url>https://nexus.company.com/repository/maven-public/</url>
    </repository>
</repositories>

本地 Maven 能下载依赖，不代表 Renovate 就能查到更新。原因可能是：

Renovate 运行环境没有 Maven settings；
私服需要认证，但 Renovate 没有凭证；
私服 URL 没有配置到 Renovate 的 registryUrls；
依赖只在公司私服里，不在 Maven Central；
自托管 Renovate 的网络无法访问 Nexus；
Nexus 证书是内网 CA，Renovate 不信任；
多个 Maven repo 的镜像规则和 Renovate 查询逻辑不一致。

11.2 仓库内配置 registryUrls

renovate.json：

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "description": "Maven 依赖统一走公司 Nexus",
      "matchDatasources": ["maven"],
      "registryUrls": [
        "https://nexus.company.com/repository/maven-public/"
      ]
    }
  ]
}

这个配置告诉 Renovate：Maven 版本查询优先走公司 Nexus。

11.3 自托管配置私服凭证

config.js：

module.exports = {
  platform: 'gitlab',
  endpoint: 'https://gitlab.company.com/api/v4/',
  token: process.env.RENOVATE_TOKEN,
  hostRules: [
    {
      hostType: 'maven',
      matchHost: 'https://nexus.company.com/repository/maven-public/',
      username: process.env.NEXUS_USERNAME,
      password: process.env.NEXUS_PASSWORD
    }
  ],
  repositories: ['backend/finance-service']
};

11.4 私服问题排查清单

问题	排查方向
`Failed to look up dependency`	检查 `registryUrls`、私服网络、凭证
本地能下载，Renovate 不行	本地 Maven settings 没传给 Renovate
401/403	token、username/password、权限范围
证书错误	内网 CA 没配置，或 HTTPS 证书链不完整
依赖查到了但版本不对	私服代理缓存、仓库合并顺序、release/snapshot 仓库混用
查询太慢	私服性能、网络、`hostRules.concurrentRequestLimit`
Renovate 查 Maven Central	检查是否所有 Maven datasource 都覆盖了 `registryUrls`

chapter 12：Monorepo 实战

12.1 场景说明

假设一个仓库里有多个模块：

platform-monorepo
├── backend
│   ├── finance-service
│   │   └── pom.xml
│   └── order-service
│       └── pom.xml
├── frontend
│   └── package.json
├── docker
│   └── docker-compose.yml
└── .github
    └── workflows
        └── ci.yml

Renovate 默认会自动发现相关依赖文件，但需要控制 PR 噪音。

12.2 Monorepo 推荐配置

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "group:monorepos"
  ],
  "timezone": "Asia/Singapore",
  "dependencyDashboard": true,
  "prConcurrentLimit": 8,
  "packageRules": [
    {
      "description": "后端 Maven 依赖统一标签",
      "matchManagers": ["maven"],
      "matchFileNames": ["backend/**"],
      "labels": ["dependencies", "backend"]
    },
    {
      "description": "前端 npm 依赖统一标签",
      "matchManagers": ["npm"],
      "matchFileNames": ["frontend/**"],
      "labels": ["dependencies", "frontend"]
    },
    {
      "description": "Docker 依赖统一标签",
      "matchDatasources": ["docker"],
      "labels": ["dependencies", "docker"]
    },
    {
      "description": "大版本升级都不自动合并",
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "labels": ["major-upgrade"]
    }
  ]
}

12.3 Monorepo 的 Review 策略

推荐按影响范围 Review：

PR 类型	Review 人
后端 Maven	后端负责人
前端 npm	前端负责人
Docker 镜像	DevOps / 后端负责人
GitHub Actions / GitLab CI	DevOps / 架构负责人
Major 更新	对应模块 Owner + 架构负责人

chapter 13：企业落地方案

13.1 推荐落地阶段

flowchart TB
    A[阶段一：只扫描不自动合并] --> B[阶段二：启用分组和 schedule]
    B --> C[阶段三：低风险 patch 自动合并]
    C --> D[阶段四：接入私服和多仓库]
    D --> E[阶段五：建设企业级 Preset]
    E --> F[阶段六：结合安全扫描和发布治理]

13.2 阶段一：试点仓库

选择 2-3 个项目：

有稳定 CI；
依赖不算太复杂；
业务风险较低；
团队愿意配合 Review；
最好有测试覆盖。

配置目标：

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "dependencyDashboard": true,
  "automerge": false
}

先观察：

Renovate 能识别哪些依赖；
是否有依赖查询失败；
PR 数量是否可接受；
CI 是否稳定；
Review 成本是否合理。

13.3 阶段二：分组和降噪

加入：

{
  "timezone": "Asia/Singapore",
  "schedule": ["before 8am on monday"],
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "labels": ["major-upgrade"],
      "automerge": false
    }
  ]
}

目标是让团队觉得 Renovate 是帮忙的，不是来制造 PR 雪崩的。

13.4 阶段三：开启低风险自动合并

可以先从这些依赖开始：

测试依赖 patch；
文档工具 patch；
Lint / formatter patch；
Docker digest；
GitHub Actions patch；
内部工具库 patch，前提是有 CI 和回归。

示例：

{
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "matchDepTypes": ["test"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "matchUpdateTypes": ["digest"],
      "automerge": true,
      "automergeType": "pr"
    }
  ]
}

13.5 阶段四：企业级 Preset

当多个仓库都要用类似配置时，不建议每个仓库复制一大坨 renovate.json。可以建设一个企业级 preset 仓库。

例如：

1 2	`platform/renovate-config └── default.json`

default.json：

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", "group:monorepos"],
  "timezone": "Asia/Singapore",
  "dependencyDashboard": true,
  "labels": ["dependencies", "renovate"],
  "schedule": ["before 8am on monday"],
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "labels": ["major-upgrade"]
    },
    {
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["digest"],
      "automerge": true
    }
  ]
}

业务仓库只需要：

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["local>platform/renovate-config"]
}

这样做的好处：

统一团队规则；
后续策略调整只改一处；
业务仓库配置更干净；
更适合平台团队治理。

chapter 14：完整生产级配置模板

下面是一份偏 Java 后端项目的完整配置模板，可以直接作为起点。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "group:monorepos",
    "docker:pinDigests"
  ],
  "timezone": "Asia/Singapore",
  "dependencyDashboard": true,
  "labels": ["dependencies", "renovate"],
  "schedule": ["before 8am on monday"],
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "rangeStrategy": "bump",
  "semanticCommits": "enabled",
  "major": {
    "dependencyDashboardApproval": true
  },
  "packageRules": [
    {
      "description": "所有 major 更新必须人工处理",
      "matchUpdateTypes": ["major"],
      "labels": ["major-upgrade"],
      "automerge": false
    },
    {
      "description": "Maven 依赖增加稳定等待期",
      "matchDatasources": ["maven"],
      "minimumReleaseAge": "3 days"
    },
    {
      "description": "Spring Boot 相关依赖统一升级",
      "matchManagers": ["maven", "gradle"],
      "matchPackageNames": ["/^org\\.springframework\\.boot:/"],
      "groupName": "Spring Boot dependencies",
      "labels": ["dependencies", "spring-boot"],
      "automerge": false
    },
    {
      "description": "Spring Cloud 相关依赖统一升级",
      "matchManagers": ["maven", "gradle"],
      "matchPackageNames": [
        "/^org\\.springframework\\.cloud:/",
        "/^com\\.alibaba\\.cloud:/"
      ],
      "groupName": "Spring Cloud dependencies",
      "labels": ["dependencies", "spring-cloud"],
      "automerge": false
    },
    {
      "description": "MyBatis 相关依赖统一升级",
      "matchManagers": ["maven", "gradle"],
      "matchPackageNames": ["/^org\\.mybatis:/", "/^com\\.baomidou:/"],
      "groupName": "MyBatis dependencies",
      "labels": ["dependencies", "mybatis"],
      "automerge": false
    },
    {
      "description": "数据库驱动依赖统一升级",
      "matchManagers": ["maven", "gradle"],
      "matchPackageNames": [
        "org.postgresql:postgresql",
        "mysql:mysql-connector-java",
        "com.mysql:mysql-connector-j"
      ],
      "groupName": "Database drivers",
      "labels": ["dependencies", "database"],
      "automerge": false
    },
    {
      "description": "注解处理器统一升级",
      "matchManagers": ["maven", "gradle"],
      "matchPackageNames": [
        "org.projectlombok:lombok",
        "/^org\\.mapstruct:/"
      ],
      "groupName": "Annotation processors",
      "labels": ["dependencies", "annotation-processor"],
      "automerge": false
    },
    {
      "description": "测试依赖 patch 更新自动合并",
      "matchManagers": ["maven", "gradle"],
      "matchDepTypes": ["test"],
      "matchUpdateTypes": ["patch"],
      "groupName": "Test dependencies patch updates",
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "description": "Maven 构建插件统一升级",
      "matchManagers": ["maven"],
      "matchDepTypes": ["build"],
      "groupName": "Maven build plugins",
      "labels": ["dependencies", "maven-plugin"],
      "automerge": false
    },
    {
      "description": "Gradle Wrapper 每月升级",
      "matchManagers": ["gradle-wrapper"],
      "schedule": ["before 8am on the first day of the month"],
      "groupName": "Gradle Wrapper",
      "automerge": false
    },
    {
      "description": "Docker 镜像 minor/patch/digest 统一分组",
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["minor", "patch", "digest"],
      "groupName": "Docker image updates",
      "labels": ["dependencies", "docker"]
    },
    {
      "description": "Docker digest 自动合并",
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["digest"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "description": "GitHub Actions 统一分组",
      "matchManagers": ["github-actions"],
      "groupName": "GitHub Actions",
      "labels": ["dependencies", "github-actions"],
      "automerge": false
    },
    {
      "description": "GitHub Actions patch/digest 自动合并",
      "matchManagers": ["github-actions"],
      "matchUpdateTypes": ["patch", "digest"],
      "automerge": true,
      "automergeType": "pr"
    }
  ]
}

chapter 15：接入 CI 的推荐流程

Renovate 必须和 CI 配合，否则自动升级没有意义。

chapter 16：常见问题与排查

16.1 Renovate 不创建 PR

可能原因：

没有发现可更新版本；
schedule 时间还没到；
prConcurrentLimit 达到上限；
dependencyDashboardApproval 要求先批准；
配置错误；
token 权限不足；
仓库没有启用 Renovate；
依赖版本被 allowedVersions、ignoreDeps 等规则过滤。

排查方式：

查看 Dependency Dashboard；
查看 Renovate 日志；
临时把 LOG_LEVEL 调成 debug；
检查是否有 config error Issue；
检查平台 token 权限；
检查 Renovate 是否真的扫描到了对应文件。

16.2 PR 太多

解决办法：

{
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "schedule": ["before 8am on monday"],
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "Minor and patch updates"
    }
  ]
}

更建议按技术域分组，而不是全部塞进一个 PR：

Spring Boot 一组；
测试依赖一组；
Maven 插件一组；
Docker 一组；
CI Actions 一组。

16.3 PR 合并后又冲突

依赖升级 PR 很容易因为主分支变化而过期。Renovate 通常会自动 rebase 或重建分支。

建议：

限制并发 PR；
不要一次开几十个 PR；
低风险更新自动合并；
高风险更新人工排期。

16.4 Maven 依赖查不到

重点检查：

{
  "packageRules": [
    {
      "matchDatasources": ["maven"],
      "registryUrls": ["https://nexus.company.com/repository/maven-public/"]
    }
  ]
}

以及自托管配置：

hostRules: [
  {
    hostType: 'maven',
    matchHost: 'https://nexus.company.com/repository/maven-public/',
    username: process.env.NEXUS_USERNAME,
    password: process.env.NEXUS_PASSWORD
  }
]

16.5 Docker 镜像更新不符合预期

常见原因：

使用了 latest，不建议；
镜像 tag 不是标准语义化版本；
私有 Registry 没凭证；
需要设置 Docker versioning；
digest pinning 和 tag 更新策略没有理解清楚。

建议：

# 不推荐
FROM openjdk:latest

# 推荐
FROM eclipse-temurin:21-jre

# 更推荐，配合 Renovate 管理 digest
FROM eclipse-temurin:21-jre@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

16.6 自动合并不生效

排查方向：

分支保护是否要求 Review；
CI 是否真的通过；
PR 是否 up-to-date；
automerge 是否只对部分规则生效；
平台是否允许机器人合并；
是否设置了 automergeSchedule；
是否被 CODEOWNERS 卡住；
是否要求 signed commit。

chapter 17：团队治理建议

17.1 建议制定依赖升级分级策略

级别	类型	策略
L1	测试依赖 patch	CI 通过后可自动合并
L2	工具链 patch	可逐步自动合并
L3	业务运行时 patch	人工 Review 或成熟后自动合并
L4	minor	人工 Review
L5	major	排期升级，必须回归
L6	安全漏洞	优先处理，必要时单独热修
L7	Spring Boot / Cloud 主框架	单独升级分支，完整回归

17.2 建议建立依赖 Owner

不要所有 Renovate PR 都扔给同一个人。可以按技术域分配：

领域	Owner
Spring Boot / Spring Cloud	后端架构负责人
数据库驱动 / ORM	后端负责人
Docker 镜像	DevOps / 后端负责人
CI/CD Action	DevOps
前端依赖	前端负责人
安全更新	安全负责人 + 模块 Owner

17.3 建议保留升级记录

依赖升级不是“合了就完”。建议关注：

哪些依赖频繁失败；
哪些 major 长期不敢升；
哪些内部库版本治理混乱；
哪些项目 CI 覆盖不足导致不敢自动合并；
哪些安全更新响应慢。

这些信息能反过来指导工程治理。

chapter 18：推荐落地清单

18.1 单仓库接入清单

[ ] 仓库有稳定 CI
[ ] 添加 renovate.json
[ ] 开启 dependencyDashboard
[ ] 限制 schedule
[ ] 设置 prConcurrentLimit
[ ] 设置 major 不自动合并
[ ] 按技术域分组依赖
[ ] 验证 Maven/Gradle/Docker/GitHub Actions 是否识别正常
[ ] 检查私服依赖是否能查询
[ ] 观察 1-2 周后再考虑 automerge

18.2 企业自托管清单

[ ] 创建 Renovate Bot 账号
[ ] 配置 GitLab/GitHub token
[ ] 建立 renovate-runner 仓库
[ ] 使用 Docker 或 CI Schedule 定时运行
[ ] 配置 config.js
[ ] 配置 Nexus / Artifactory / Harbor 凭证
[ ] 配置 GitHub token 用于 changelog 查询
[ ] 按仓库白名单逐步接入
[ ] 建设企业级 Renovate preset
[ ] 接入安全扫描工具
[ ] 定期复盘失败 PR 和长期未升级依赖

chapter 19：一份更贴近后端团队的推荐策略

如果是 Spring Boot 后端团队，我建议这样开始：

第一周：

1 2	`只开启 Renovate，不自动合并。观察它会提哪些 PR、哪些依赖查不到、CI 是否稳定。`

第二周：

1
2
3

增加分组规则。
限制每周一早上创建 PR。
设置 prConcurrentLimit = 5。

第三周：

1
2
3

测试依赖 patch 自动合并。
Docker digest 自动合并。
GitHub Actions patch 自动合并。

第四周：

1
2
3

接入 Nexus / Harbor 私服。
建设团队级 preset。
统一所有后端仓库配置。

后续：

1
2
3

Spring Boot / Spring Cloud 大版本单独排期。
把 Renovate PR 成功率纳入工程质量观察指标。
把长期不升级的依赖列入技术债。

chapter 20：最终总结

Renovate 的核心价值不是“自动改版本号”，而是：

让依赖升级持续发生；
让升级行为可配置、可审计、可回滚；
让低风险更新自动化；
让高风险更新显式进入 Review 流程；
让私服、Docker、CI、Monorepo 这些复杂场景也能被统一治理。

对于 Java 后端团队来说，Renovate 最适合用在这些地方：

Spring Boot / Spring Cloud 依赖升级；
Maven / Gradle 多模块项目；
Lombok / MapStruct / MyBatis / 数据库驱动版本治理；
Docker 基础镜像升级；
GitHub Actions / GitLab CI 模板升级；
Nexus / Artifactory 私服依赖管理；
多仓库统一依赖治理。

最终落地原则可以浓缩成一句话：

低风险自动化，高风险显式化，核心依赖谨慎化，团队规则配置化。

Renovate 不会让依赖升级完全没有成本，但它可以把成本变得更早、更小、更可控。工程治理很多时候就是这样：不是消灭麻烦，而是别让麻烦长成怪兽。

参考资料

Renovate 官方文档：https://docs.renovatebot.com/
Renovate GitHub 仓库：https://github.com/renovatebot/renovate
Renovate Managers 文档：https://docs.renovatebot.com/modules/manager/
Maven Manager 文档：https://docs.renovatebot.com/modules/manager/maven/
Gradle Manager 文档：https://docs.renovatebot.com/modules/manager/gradle/
Gradle Wrapper Manager 文档：https://docs.renovatebot.com/modules/manager/gradle-wrapper/
Docker Compose Manager 文档：https://docs.renovatebot.com/modules/manager/docker-compose/
Docker digest pinning 文档：https://docs.renovatebot.com/docker/
GitHub Actions Manager 文档：https://docs.renovatebot.com/modules/manager/github-actions/
Renovate 配置项文档：https://docs.renovatebot.com/configuration-options/
Renovate 自托管配置文档：https://docs.renovatebot.com/self-hosted-configuration/
Renovate 私有包支持文档：https://docs.renovatebot.com/getting-started/private-packages/
Renovate Automerge 文档：https://docs.renovatebot.com/key-concepts/automerge/
Renovate 升级最佳实践：https://docs.renovatebot.com/upgrade-best-practices/

启示录

依赖升级不是杂活，而是工程系统保持生命力的日常保养。

真正稳定的系统，不是永远不变，而是能安全、持续、低成本地变化。

检查	Java 后端建议
编译	`mvn clean compile` 或 `./gradlew compileJava`
单元测试	`mvn test` / `./gradlew test`
集成测试	Testcontainers / Docker Compose
静态检查	Checkstyle、Spotless、Sonar
依赖安全扫描	OWASP Dependency Check、Snyk、Trivy、Grype
Docker 构建	验证 Dockerfile 是否仍可构建
启动冒烟	Spring Boot 应用能否启动