Jenkins + SonarQube 从原理到实战六：Jenkins 和 SonarQube 的项目落地实践
前言
本篇 没有代码 主要聚焦在 思路和落地方案 上，更多是“在实际项目里怎么把它跑起来”。
前面几篇我们已经聊过：
- C/C++ 代码怎么用 SonarQube + sonar-cxx 插件去做扫描；
- SonarQube 上的报告展示；
- Jenkins 和 Gerrit 打通、SonarQube 与 Windows AD 打通；
- Jenkins 与 SonarQube 打通，最终实现了 git push → Jenkins 触发任务 → 下载代码 → 扫描上传 → 获取 SonarQube 扫描结果并打分/评论。
- 等等之类的
按前面的篇章做完，基本也对 CI 技术有个了解了。
需求背景
这里说一下实际项目需求，项目经理提出了：
- 针对 C/C++ 代码做静态扫描，开发同事能看到代码质量是什么问题并及时修正；
- 需要结合现有 Jenkins 实现自动化扫描；
- 报告权限隔离：只有相关项目的人能看到自己项目的结果，避免交叉曝光；
- 目前现有的部分 Jenkins 任务原本就会跑编译或自定义脚本扫描，希望能和 SonarQube 一起集成，实现 Patch 的打分并评论。
换句话说，我们要把 SonarQube 引入到已有的 CI 流程里，让它自然地成为开发日常的一部分。
落地方案
1. SonarQube 与 Windows AD 打通
- 所有 AD 用户都能直接登录 SonarQube。
- 登录后，SonarQube 可以自动识别用户所属组（AD group）。
2. 基于组的权限管理
- 在 SonarQube 上创建与 AD 相同名称的 group。
- 用户登录后会自动加入对应组。
- 项目私有化：授权给该组即可，确保“只看自己项目”。
3. Jenkins 项目自动化对接
- Jenkins Job 名作为变量传入扫描，SonarQube 会自动创建同名项目。
- 这样 Jenkins 的任务名与 SonarQube 项目名天然保持一致，便于管理。
4. 项目管理员机制
- SonarQube 的项目权限管理粒度较细：只有管理员或项目管理员能配置。
- 为避免集中维护，我给每个项目配一个“项目管理员”，由他们自己管理成员和权限。
- 但目前没找到 批量授权 的办法，只能考虑后续用 SonarQube API 来做。
5. Jenkins 与 SonarQube 打分逻辑
-
由于 Gerrit 是统一账号接入，打分需要区分：
- Review 分（代码质量层面）
- Verify 分（编译/构建层面）
-
可以分成两个 Job，也可以在一个 Job 中拆分处理。
6. 任务拆分与并行
- 如果时间太长，可以把“SonarQube 扫描”和“编译”拆成两个 Job，或者同一个 Job 下并行处理。
- 原本已有的编译任务保持不动，额外加一个扫描任务即可。
实际问题与无奈
技术方案上，CI 已经打通得差不多了。
但真正落地，问题并不是工具，而是 推广。
- 原来没有代码质量扫描，大家写完代码 push，编译没问题，负责人检查下没问题合并了就好；
- 现在多了一层扫描，出了问题还要修复，还能扫描出复杂度、bug 等问题，相当于额外工作量；
- 并且很多 sonar-cxx 的规则其实不太适合我们，要么太严格，要么不适用，结果项目经理到现在都没定好最终规则；
- 我作为运维/平台方去推动，开发自然会有抵触，“多一件事，凭什么要做”（此应由技术总监或项目经理去推动）；
- 平台部署好了，对自己来说也没啥好处，反而还要多维护一套系统，说到底只能算是自己多熟悉了一套 CI 工具链。
说白了，CI 的难点不是 CI/CD 工具本身，而是“人”。
CD 设想
CI 做到这一步，CD 自然是下一个话题。
但 CD 更加困难：
- CI 还能用“质量门槛”来逼一逼；
- CD 则涉及“发布流程、责任划分、上线事故风险”，更敏感。
我们目前有两套 Gerrit：
- 对内 Gerrit：用于内部开发；
- 对外 Gerrit：SDK 工具发布。
理想状态是：
-
内部 CI 流程完成测试/验证后，如果能拿到这些代码需要发布的部分，分析改动规律；
-
开发改好测好之后，触发一个 Jenkins 脚本，自动把结果同步到外部 Gerrit 上；
-
这样就能减少重复操作，避免开发手动再去 push 到对外平台。
不过这还只是设想，能不能推行要看后续公司 + 项目发展。
目前发布都是由开发他们手工 Push 到 对外 Gerrit 上的，若实现 CD ，对他们来说也省了不少事情。
总结
整个 Jenkins + SonarQube 系列看下来并操作一遍，能带大家熟悉整个 CI 制作流程和技术要点了，遇到相关需求应该也能独自部署了。
本篇不是去展示某个命令或配置，而是把 从需求 → 思路 → 落地 → 困难 → 展望 这条路讲了一遍。
- 技术上，SonarQube + Jenkins + Gerrit 的集成已经比较成熟，代码扫描、打分、评论的 CI 流程能跑通；
- 管理上，权限、项目归属、自动化配置也有了相应方案；
- 困难在于：推广与人。没有强制要求和合理的激励机制，开发同事很难自发去接受这套工具。
CI/CD 并不是单纯的工具链，而是 组织协作方式的改变。
技术问题总能解决，但“人”的问题，往往才是最难的。