SonarQube质量配置怎么复制 SonarQube质量配置复制后规则数量不一致怎么办

SonarQube里的“质量配置”通常指Quality Profile，它决定某种编程语言启用哪些检查规则。团队想给新项目沿用现有标准时，复制一份很方便。

麻烦也常出在这里。明明从同一个配置复制，过一段时间再看，规则数量却对不上。遇到这种情况，别急着一条条手工补，先确认用的是复制、继承，还是跨服务器导入。

一、SonarQube质量配置怎么复制

质量配置按编程语言分别管理。Java配置不能直接当成JavaScript配置使用，复制前要先进入对应语言的配置列表。

修改质量配置通常需要【Administer Quality Profiles】权限。没有权限时可以查看规则，但看不到复制、恢复或批量修改入口。

1、在同一台SonarQube中复制

①进入顶部菜单【Quality Profiles】。

②找到对应语言和源质量配置。

③打开配置页面，点击右上角三点菜单。

④选择【Copy】。

⑤输入新名称，再点击【Copy】完成创建。

复制完成时，SonarQube会克隆源配置中当前已激活的规则。新配置随后独立存在，源配置以后增加或删除规则，不会自动同步到副本。

这一点很容易忽略。刚复制时两边数量一样，过几个月再看却差了十几条，并不一定是复制失败，可能只是源配置后来改过。

2、复制和继承怎么选

创建配置时，除了【Copy】，还可以选择继承现有配置，也就是建立父子关系。

【Copy】适合做一份固定副本。团队可以随意启用、停用规则，后面怎么改都不会牵动原配置。

【Extend】更适合多个项目共用一套基础规范。父配置发生变化后，新增、停用或调整的规则会反映到子配置中，子配置还可以增加自己的规则。

项目只是临时做一点差异化，使用继承会省心不少。要是每个项目都复制一份，时间一长，十几个配置各长各的，维护起来确实头大。

3、复制到另一台SonarQube服务器

跨服务器不能直接点【Copy】，需要导出XML文件后再恢复。

①在源服务器进入【Quality Profiles】。

②找到自定义质量配置，打开右侧操作菜单。

③选择【Back up】，下载XML文件。

④登录目标服务器，进入【Quality Profiles】。

⑤点击【Restore】，选择XML文件并恢复。

官方文档说明，如果目标服务器已经存在同名配置，恢复操作会把备份中缺少的激活规则补进去，但不会更新目标配置中已经激活的规则。这个行为更像合并，和新建一份完整副本不太一样。

二、SonarQube质量配置复制后规则数量不一致怎么办

同一实例内刚完成【Copy】，正常情况下，源配置和副本的激活规则数量应该一致。数量对不上时，先查差异来源，别只盯着页面上的总数。

1、直接比较两个质量配置

①打开其中一个质量配置。

②点击右上角三点菜单。

③选择【Compare】。

④在【Compare with】中选择另一个配置。

⑤查看两侧多出的规则和缺少的规则。

SonarQube只能比较同一种语言的质量配置。比较结果会列出一边多出的规则、另一边缺少的规则，还会显示严重性或参数配置不同的规则。

规则总数一样，也别马上认定两份配置完全一致。某条规则的严重级别、阈值参数不同，数量不会变化，实际扫描结果却可能差很多。

2、确认创建方式有没有选错

有时口头上说“复制了一份”，实际操作用的是【Extend】。子配置页面会把继承规则、自身规则和覆盖规则分开统计，看起来就容易和父配置对不上。

①打开目标质量配置。

②查看【Inheritance】区域。

③检查是否存在父配置。

④查看【Active】、【Inactive】和【Overridden】数量。

⑤点击对应数字查看具体规则。

官方界面会在继承区域展示父子关系，以及激活、未激活和覆盖规则数量。覆盖规则通常是子配置修改了严重级别、参数或其他可配置属性。

看到数量不一致先别慌。子配置多出几条项目专用规则，或者停用了父配置中的部分规则，都属于正常情况。

3、核对SonarQube版本和分析器版本

跨服务器恢复配置时，两台服务器的版本、版本类型和语言分析器不一致，规则库也可能不同。

SonarQube及第三方分析器升级后，可能增加新规则、调整已有规则，或者将旧规则标记为弃用。某些弃用规则后续还会被移除，所以同一份配置放在不同环境里，规则总数未必能完全对齐。

商业版本还可能包含Community Build没有的规则。源服务器能识别某条规则，目标服务器没有对应分析能力，光靠导入配置文件也补不出来。

4、检查弃用规则和新增规则

①进入【Quality Profiles】。

②查看是否出现粉色的弃用规则提示。

③点击数量进入规则列表。

④使用【Status】筛选【Deprecated】。

⑤再按【Available Since】检查新增规则。

内置配置会随SonarQube或分析器升级持续更新。独立复制出来的自定义配置不会自动接收这些变化，需要管理员定期检查新增和弃用规则。

这也是很多规则数量差异的来源。源配置是持续更新的【Sonar way】，副本却停在半年前，两边越差越多很正常。

三、怎样让复制后的质量配置保持一致

把规则数量调成一样，只能说明表面数量对上了。真正用于项目分析时，还要核对规则标识、严重级别和参数，否则扫描结果仍然会有差距。

1、按比较结果补齐规则

①使用【Compare】找出缺少的规则。

②打开具体规则详情。

③确认规则适用于当前项目。

④在目标配置中激活或停用。

⑤核对严重级别和规则参数。

别为了追求数字一致，把所有缺少规则一股脑打开。某些规则可能针对特定框架、语言版本或团队规范，硬加进去只会制造一堆没人处理的问题。

2、查看质量配置变更记录

①打开对应质量配置。

②点击右上角操作菜单。

③选择【Changelog】。

④查看规则激活、停用和参数调整记录。

⑤对照升级或导入时间判断变化来源。

SonarQube会记录质量配置的变更历史。项目使用的配置发生变化后，项目事件中也可能出现相应记录，方便判断某次分析为什么突然多出或减少问题。

3、确定团队采用哪种维护方式

希望各项目始终跟随统一基线，可以让自定义配置继承内置配置或团队基础配置。

希望某个项目长期保持固定规则集，就用独立副本，但要安排定期比较和维护。官方也建议持续检查未继承内置配置的自定义质量配置，避免长期漏掉新增规则。

配置数量别铺得太开。一个项目建一份、一个分支再建一份，短期看很灵活，半年以后基本没人能说清它们差在哪里。

总结

“SonarQube质量配置怎么复制SonarQube质量配置复制后规则数量不一致怎么办”反映的是规则基线如何长期维护。复制适合独立控制，继承更利于统一更新，跨服务器恢复还会受到版本、分析器和已有配置的影响。团队提前确定维护方式，比后期单纯追着规则数量调整更可靠。