关于CI/CD流水线的Maven与SonarQube技术问询

问题1：构建Java代码时，是先生成Jar文件再执行SonarQube分析，还是两者同时进行？我认为应先执行SonarQube分析，仅当代码质量达标后再执行Maven构建。 #

你的思路方向是对的，但实际落地要调整细节：不要直接跳过编译步骤，但可以推迟打包成Jar的操作。

SonarQube分析Java代码需要依赖编译后的class文件，所以必须先执行mvn compile完成编译，但不用急着跑mvn package生成Jar。正确流程是：

1. 执行代码编译（mvn compile）
2. 运行SonarQube分析
3. 若质量检查通过，再执行mvn package生成Jar制品

这么做的好处是：

• 避免在代码质量不合格时浪费资源打包Jar
• 提前拦截问题代码，不用等到打包完成才发现质量问题

问题2：Sonar Scanner与Maven是单独使用还是集成使用？我知晓两种方式均可行，但在仅当代码质量达标才生成制品的需求下，哪种方式更优？ #

优先选择Maven集成SonarQube插件的方式，更适配你的需求：

1. 配置更简洁：复用Maven项目的源码路径、编译产物路径、依赖配置，不用单独给Sonar Scanner指定各种路径参数
2. 流程衔接更顺畅：可以把Sonar分析绑定到Maven的构建阶段（比如verify阶段），配合质量门控制，一旦质量不达标，直接终止后续的package阶段
3. CI中易维护：只需要执行mvn sonar:sonar命令，不用额外维护Sonar Scanner的独立配置

单独使用Sonar Scanner的场景通常是非Maven/Gradle的项目，或者需要高度定制分析规则的场景，但对Java Maven项目来说，集成方式更高效。

问题3：SonarQube如何告知CI系统（如Azure DevOps等），在质量检查失败时中断流程，达标则推进至下一步？ #

核心是通过SonarQube质量门（Quality Gate） + CI任务的结果判断来实现：

步骤1：在SonarQube中配置质量门 #

先在SonarQube后台定义好质量规则（比如代码覆盖率阈值、bug数、漏洞数上限等），创建一个自定义质量门，绑定到你的项目。

步骤2：在CI流程中配置等待质量门结果 #

以不同CI工具为例：

• Azure DevOps：使用SonarQube官方扩展任务，勾选“等待质量门”选项。当质量门失败时，该任务会返回失败状态，Azure DevOps流水线会自动中断，不会执行后续的打包/发布步骤；若质量门通过，则继续推进。
• 命令行/通用CI：执行Sonar分析时，添加参数让命令等待质量门结果，比如Maven方式用mvn sonar:sonar -Dsonar.qualitygate.wait=true。如果质量门失败，该命令会返回非零退出码，CI系统会识别为任务失败，终止流程。
• Jenkins：使用SonarQube插件的“Quality Gate Check”步骤，设置为失败时终止流水线。

这样就能实现“质量不达标就中断，达标就继续”的自动化控制。

内容的提问来源于stack exchange，提问作者nischeruku