SonarQube里质量门禁要怎么去设，还有当这个门禁过不去的时候，应该先查哪些指标，很多团队把静态代码检查接进CI以后，都会撞上这个问题。质量门禁这个东西，它不单单是去看一下代码扫描成没成功，而是用事先定好的一组条件，去判断这回交上来的代码，到底够不够格合进去，或者能不能往外面发。它主要是拿来卡新代码的，也可以去卡整体代码，现在搞项目的人一般都会说，先把力气用在管好新代码上头，这么一来，就不会弄成老问题还没清掉，新问题又跟着跑进来的局面。

　　一、SonarQube质量门禁怎么设置

　　在设置的时候，不要一开头就把条件弄得太紧，特别是那种已经跑了好些年的老项目，你要是上来就让整体代码全都去够一个很高的标准，这个门禁恐怕要长时间地亮红灯过不去，搞到最后，做开发的人心里一烦，干脆绕着它走，比较把稳的做法，是先拿着默认的那个门禁用起来，然后照着项目自己的情况，再一点一点地往严里去收。

　　1、先把门禁要管的对象定下来

　　项目这头，要先拿个主意，看看这个门禁主要是去卡【新代码】，还是连新带旧，把整体代码也一块儿查了，新项目是可以要求整体质量一上来就往高里够的，老项目的话，一般先从新代码下手，会更实在一些。

　　SonarQube的质量门禁，是能分开给新代码和整体代码设条件的，真的往项目里落的时候，要留神别把过去攒下的那一屁股债，一口气全压到每个分支上面去。

　　2、用默认的那个门禁先跑起来

　　SonarQube自己带的推荐的那种门禁，一般就是盯着新代码带进来的问题、安全上的热点、测试覆盖率，还有代码被来回抄的重复率，这么几样。常见的做法，是让新加进来的代码不要再往里头带新的毛病，新代码那边的测试覆盖率也别掉到百分之八十下头去，重复率不要超过百分之三，这些就算是很常见的门禁条件了。

　　3、照着项目自己的风险去调条件

　　要是做的东西是很核心的业务、车上跑的软件，或者是金融那一块的系统，那在安全、可靠和覆盖率上头，就可以定得更严一点，反过来，要是那种包袱压得很重的内部系统，那就可以先保住新代码别再接着烂下去，然后再分阶段去拾掇那些旧问题，拿来卡门禁的条件，可不是你往上码得越满就越好，码太多了，失败的原因就会变得东一块西一块的，底下写代码的人反倒要犯迷糊，不知道先从哪里下手去改。

　　二、sonarQube质量门禁不过该先查哪些指标

　　门禁亮红灯过不去的时候，头一件事，别光拿眼睛盯着那个红通通的状态发愣，比这要紧的，是去把那些失败的条件一个一个点开，认准了到底是哪个指标在底下捅亮了这盏红灯，很多时候，根本不是整片代码一下子都坏掉了，它就偏偏是那么一个小条件没够上，比如说新代码覆盖率差了一丁点，再或者，有一个安全热点还撂在那里没人去碰它。

　　1、先拿眼睛看失败的条件都是些啥

　　进到项目的【Quality Gate】结果页里头，先把具体是哪儿没通过给找出来，到底是coverage这一块没够上数，还是duplications那边抄得冒了头，是reliability rating那个评级没够到线，还是security rating那边翻了大船，照着这么个先来后到的次序往下排，这个章法是很要紧的，可别一看见门禁失败，就朝着整个项目满地儿瞎改。

　　2、去查一遍新代码那边都带了些什么问题过来

　　要是门禁主要是冲着新代码去的，那就先把眼神搁到New Code里头的那些个Bugs、Vulnerabilities、Code Smells和Security Hotspots上面，有些问题瞧着好像不过就是些代码的味道，可要是它们扎着堆出现在新加进去的那些核心逻辑里头，那也不该随手就把它给忽略过去。

　　3、去检查一下覆盖率，还有那些被反复抄的比例

　　覆盖率这一项要是没过，头一件事是先去看那个用来报告测试覆盖率的文件，有没有被好端端地导进来，有些项目挺冤的，测试在本地明明跑了，可进了CI里头，那个coverage report没传对给SonarQube，结果显出来的覆盖率就低得没法看，重复率那边要是也没过，那也要先瞧一眼，是不是成段成段地复制了业务逻辑，或者是那种自动生出来的代码没被加到排除名单里头，像那种自动生成的、第三方过来的代码，顶好事先就把要排除的范围给它圈好。

　　三、sonarQube门禁过不去，别光硬改代码

　　质量门禁失败，这根子倒不一定全都要靠着动手改代码才能摆平，有些时候，它就是配置上出了毛病，有些时候是统计范围给圈得不对了，也还有的时候，是团队一开头就把门禁的法子定得跟眼下项目的阶段合不到一个拍子上去，处理的时候，得先把底下那个真正的原因摸透了，然后才好拿主意，看是该去改代码、补测试、调配置，还是照着规矩去走那种被允许的例外流程。

　　1、先把要分析的那个范围给认清楚

　　先去查一遍sonar-project那边的配置、源码目录、测试目录、要排除出去的规则、分支名，还有新代码周期，新代码周期要是设得不对头，它就很可能会把一批明明是历史里头留下来的老代码，硬给算成是新加进来的代码，真要摊上这么个情况，那这个门禁想过可就难了。

　　2、完了以后，去料理那些真正冒尖的高风险问题

　　安全上的漏洞、要命的Bug、空指针的风险、资源没被好好放掉的问题，还有跟认证和权限挂着钩的那些，这些是要提到最前头先给收拾干净的，跟这些个东西一比，那些关于名字起得好不好、格式对不对，还有一些不痛不痒的轻微重复，就可以排到后头去弄了，门禁它生出来的价值，可不是在屏幕上给你挂满红灯，而是要把眼下最该修、最要命的问题，抢在前头给拦下来。

　　3、让门禁跟CI那边好好地打起配合来

　　门禁这个东西，顶好是接进合并请求或者是流水线里头，在它挂掉的时候，好让做开发的人第一眼就能瞅见是栽在了什么上头，可不要只在临发布前才去扫那么一下，到那个时候问题都堆成山了，再回头去修，实在是太被动了，平时做开发的那个阶段，就把新冒出来的问题给死死地摁住，后面再谈质量要怎么治理，那担子才会轻上很多。

　　总结

　　所以说，SonarQube质量门禁怎么设，不过的时候该先查哪些指标，这里头的关键，倒不是把拿来卡人的条件像堆小山一样码得越多越好，而是要叫那个门禁，真真正正地去给代码的合入和质量的治理出一份力，设的时候可以先围着新代码把标准立起来，再一步一步铺开，不过的时候，先看失败的条件是个啥，再去查新代码带进来的问题、覆盖率、重复率、安全热点，还有当初划下来的那个分析范围，把这些个指标、配置，还有代码里头的毛病拆开来看，处理起来心里会觉得稳当不少，也不怎么容易就把那个本是好心设在那里的质量门禁，给生生弄成了压在团队背上的一副担子。