我们是如何在 Monorepo 中减少 Dependabot 噪音

Source: Dev.to

为什么我们需要 Dependabot

• 依赖管理变得越来越手动且容易出错。
• InnerSource Terraform 模块经常更新，但使用这些模块的项目必须手动跟踪并应用这些更改。随着时间推移，项目落后，升级变得更困难，且不兼容的风险增加。
• Spring Boot 依赖在初始设置后很少更新，导致代码库中存在已知漏洞，并触发 Nexus SCA 的重复警报。
• CI 流水线因漏洞策略违规而开始失败——通常是因为已有可用的修复却未被采用。

我们需要一种自动化方式来保持基础设施和应用程序依赖的最新状态，以避免安全警报、CI 失败以及手动更新日益增长的成本。这促使我们采用了 GitHub 的 Dependabot。

在单体仓库中管理 Dependabot

按生态系统分组的 Pull Request

• 所有基于 Maven 的更新生成一个 Pull Request。
• 所有基于 Docker 的更新生成另一个单独的 Pull Request。
• 其他生态系统同样遵循相同的模式。

每个生态系统的更新频率

• Terraform 依赖每天检查一次，因为我们的 InnerSource 模块更新频繁。
• 其他所有生态系统（Maven、Docker 等）每周检查一次，以在新鲜度和审查工作量之间取得平衡。

Dependabot 配置示例

updates:
  - package-ecosystem: "maven"
    directories:
      - "/packages/app_a"
      - "/packages/app_b"
    schedule:
      interval: "weekly"
      day: "tuesday"
      time: "19:00"

将 Dependabot PR 视为普通功能分支

• 每个 Dependabot PR 都会触发与开发者创建的分支相同的 CI 流水线。
• 自动化测试套件会为每个 Pull Request 运行，验证基础设施和应用程序的更改。
• 只有在通过所有必需检查和审查后，更新才会被合并。

所有权与监控

• 每个 Dependabot PR 都关联一个小的 Jira 任务，并明确指派给一名开发者。
• 被指派的开发者审查 PR 结果并调查任何 CI 或测试失败。
• 如果 PR 失败，他们会找出原因（破坏性更改、测试问题、需要的配置更新），并采取纠正措施。

这个轻量级流程确保 Dependabot PR 不会变成背景噪音。

非工作时间的 CI 执行

• Dependabot 触发的流水线安排在开发高峰期之外运行。
• 这减少了共享 CI 资源的竞争，同时开发者仍在积极工作。
• 团队仍能在下一个工作日获得最新结果，而不会拖慢功能开发。

实际收益

• 依赖相关的 CI 失败显著减少。
• 由于及时更新，Nexus SCA 的漏洞警报减少。
• Pull Request 更少且更有意义，使审查更快更容易。
• Terraform 模块和 Spring Boot 应用的稳定性提升。
• 更好地利用 CI 资源而不影响活跃开发。

总体而言，这种方法将依赖管理从被动问题转变为可预测、低噪音且可靠的过程。