SonarQube的质量配置文件，它本质上就是决定了，某一种语言在跑代码分析的时候，到底会启用哪些规则，一个项目扫描出来的那些问题，也会受到它当前绑定的那个配置文件的影响，按照SonarQube的文档说明，质量配置文件，就是用来定义在分析代码的时候，要应用的那一套规则集合的，而且每一种语言，都可以有它自己专属的配置文件。

　　一、质量配置文件要怎么创建

　　在动手去创建一个质量配置文件之前，得先确认一下，你登的这个账号，是不是有管理质量配置文件的权限，要是没有这个权限，那通常就只能看一看，是没办法去新建、复制，或者是修改规则的，在SonarQube里，创建配置文件，比较常见的办法有三种：一个是从一个已经有的配置文件那里继承过来；一个是把一个已经有的配置文件，复制一份出来；还有一个，就是从一张白纸，一个空白的配置文件开始。

　　1、先进到质量配置文件的那个页面里面去

　　在登录了SonarQube的后台以后，去点一下顶部菜单里的质量配置文件，进到这个列表页来，在这个页面里，它会把每一种语言的配置文件，都分开来列好，比如Java的、JavaScript的、C#的、Python的等等这些，这个时候，要先想清楚，你这一次要调整的，到底是哪一种语言，可千万别在一种错误的语言下面，去新建了一套规则集出来。

　　2、去选一下，你打算用什么样的方式来创建

　　去点一下页面右上角的那个创建按钮，要是你的想法是，继续沿用Sonar官方给的那个规则，或者是公司自己定的那套基础规则，然后再往上面去追加项目自己特殊要用的规则，那就去选那个继承已有配置文件的选项；要是你想的是，把一套配置文件完完全全地复制一份出来，然后自己再独立地去维护它，那就去选那个复制已有配置文件的选项；再要是，项目有特别特殊的要求，那也可以选去创建一个空白的配置文件。

　　3、把语言和名字给填上

　　在创建的那个小窗口里面，先去选好这个配置文件，是要给哪一种语言用的，然后再去给它起一个名字，在起名字的时候，最好是能让人一眼就看明白它是干嘛用的，比如说，给公司Java项目打底用的、给专门跟安全相关的Java项目用的、或者是专门给那种老旧的C#项目来用的，可千万不要只给它起个叫测试、新配置文件，这种模模糊糊的名字，不然到了后面，好几个人一起维护的时候，是很容易给选错了的。

　　4、等创建好了以后，去把规则给启用了

　　进到这个新建好的配置文件的详情页面里面去，去点一下那个显示规则数量的地方，或者是直接进到规则的那个页面里去，然后，你就可以靠着语言、严重的级别、标签、还有类型这些条件，去把想找的规则给筛出来了，那些你需要打开的规则，就去点一下激活的按钮，而那些用不着的规则，就让它们继续关着就好了，要是碰到的规则，是带着参数的，那还得去检查一下，那个参数的阈值，是不是符合你们项目的要求。

　　二、规则之间的继承关系要怎么整理

　　关于规则之间的那种继承关系，最好是要提前就规划好，继承这种模式，是比较适合，公司已经有一套统一的基线规则了，然后，又允许不同的项目，在这个基础上，再去增加少量的、属于自己规则的场景；而复制这种模式，就比较适合，项目的规则跟公司的基线，差别已经很大了，而且你也不希望，父级那边一有什么变动，就影响到自己这边的场景，SonarQube的文档里也说明了，继承，是会在父子的配置文件之间，建立起一种关系的，父配置文件的那些变化，是会动态地反映到子配置文件里面去的。

　　1、要优先去把公司的基础配置文件给建立起来

　　你可以先把Sonar官方给的那个规则集给留下来，当成一个基础，然后再去创建一个公司级别的配置文件，在这里面，去统一地把你们团队内部大家都认可的那些规则，给启用起来，SonarQube自己也是这么建议的，它说，是通过去扩展那个官方的规则集，来定制你自己的配置文件的，这么做有一个好处，就是可以跟着内置规则的变化一起走，能拿到新的规则，还有规则参数上的调整。

　　2、让项目的配置文件，从公司的基础配置那里继承过来

　　当不同的项目，需要有不一样的规则要求的时候，不建议给每一个项目，都去单独复制一份官方的规则集来用，一种更清楚的做法，是把公司的基础配置，当成是父级，把各个项目的配置文件，当成是子级，在子级里面，就只去维护这个项目额外需要启用，或者是调整了参数的那些规则，而那些大家都要用的公共规则，就还是继续放在父级里面去统一管着。

　　3、不要把这个继承的层级，给搞得太深了

　　如果继承的层级搞得太多、太深了，到了后面，你就很难去判断，某一条规则，它到底是从官方规则集那里来的、还是从公司的基线那里来的、又或者是从项目自己定义的地方来的，一般情况下，留个两到三层，就已经很够用了，比如说，一层是官方的，一层是公司基线的，再一层是项目配置的，要是再多加一层，维护起来的成本，通常就会很明显的往上涨了。

　　4、要定期地去检查一下，那些不一样的规则

　　进到配置文件的详情里面去，去查看一下，当前启用了哪些规则、哪些是继承来的、哪些又是自己自定义的，重点要去看一看，在项目这一层，有没有额外地去打开了一些什么规则、有没有把哪些规则给禁掉了，还有，哪些规则的参数，是被修改过的，在你要去升级插件，或者是去调整规则之前，最好是先把它导出来，或者是把当前的配置给记录下来，这么做的目的，是为了避免在你改完了以后，结果却说不清楚，这个变化，到底是从哪里来的。

　　三、质量配置文件要怎么绑定到项目上去

　　等到配置文件都建好了以后，还得要把它给绑定到具体的项目上面去才行，要不然的话，扫描的时候，它还是有可能，会继续用那个系统默认的配置。

　　1、去把默认的配置文件给设好

　　在质量配置文件的那个列表页面里面，先选中某一种语言底下，你打算拿它当默认的那个配置文件，然后去用那个设为默认的按钮，把它给设置成默认的，这么一来，那些没有单独去指定配置文件的项目，就会自动地去用，这种语言默认的那套规则集了。

　　2、去给项目，单独地分配一个配置文件

　　进到具体的那个项目里面去，去找到项目设置里面，跟质量配置文件有关的那一块，然后把对应的那种语言，给它切换到你指定的那个配置文件上面去，对于那些用了不止一种语言的项目，是要分开去检查的，每一种语言，都要去确认一下，它绑定的到底是不是你心里想的那个。

　　3、重新跑一次分析，去看看结果是不是对

　　等到配置文件的绑定都弄完了以后，就要去重新再跑一次项目的分析了，等分析跑完了，就去项目的主页面里，找一找那个显示着质量配置文件信息的地方，去确认一下，现在实际在用的，到底是不是你刚刚才绑好的那个新配置文件，然后，再去比对比对，问题的数量，还有规则的类型，看看规则的调整，是不是已经真的生效了。

　　总结

　　关于SonarQube的质量配置文件要怎么去创建，还有规则之间的那种继承关系又要怎么去整理，操作上的重点，就是先去把要给哪一种语言用、还有自己有没有权限，这两个先决条件给弄明白，然后再去决定，是要用继承的、复制的，还是建一个空白的，在规则关系的处理上，比较建议的做法是，拿官方的规则集来当基础，把公司的基线给集中地维护好，到了项目配置这一层，就只是去处理那些跟基线不一样的规则，最后，可千万别忘了，要把建好的配置文件，给实实在在地绑定到项目上面去，然后再重新跑一次分析，要不然的话，你规则这边是改了，可那边扫描出来的结果，却还是老样子，是不会跟着变的。