SonarQube新代码周期怎么设置 SonarQube新代码周期影响门禁结果怎么看

SonarQube新代码周期的设置，以及新代码周期对门禁结果的影响，是很多团队在配置质量门禁时容易忽略的问题。新代码周期并不是一个单纯的日期设置，它决定了哪些代码会被SonarQube当作“新增或修改的代码”来评估。如果质量门禁主要看的是新代码指标，那么新代码周期的设置一旦不同，同一份代码的门禁结果，也就可能会跟着不同。在SonarQube里面，新代码的定义可以按照全局、项目，或者是分支的层级来进行配置，而且它会影响到新代码问题，以及相关质量指标的计算。

一、SonarQube新代码周期怎么设置

在新代码周期被设置以前，需要先想明白，团队采用的是哪一种质量治理的方式。如果项目是持续地在迭代，每次都希望去控制最近的那些改动，那就可以按照天数，或者是参考分支来设置；如果项目是按照版本来发布的，那么使用版本号来作为周期的边界，就会显得更加清楚。

1、先去选定新代码的定义方式

比较常见的几种方式，包括上一个版本、指定天数，还有参考分支。上一个版本这种方式，比较适合按照版本去发布的项目；指定天数这种方式，比较适合持续交付的项目；参考分支这种方式，则比较适合用在功能分支和主分支进行对比的场景。不要给所有的项目，都套用同一种方式，否则的话，有的项目，新代码的范围会被拉得过宽，而有的项目，却又看不到那些真正是新冒出来的问题。

2、在项目的设置里面，去调整新代码的周期

进到【Project Settings】以后，找到跟新代码有关的设置，然后根据项目自身的具体情况，去选择上一个版本、天数，或者是参考分支。

要是选择了指定天数，那么SonarQube就会把这段时间范围以内，发生了变更的代码，当成是新代码；在相关的文档里面，也曾经给出过三十天这样的一个示例，并且说明了天数这种方式，通常是会被用在持续交付的场景里面的。到了这一步，需要留意的是，周期越是短，门禁就越是会盯住近期的那些改动；周期越是长，被纳入到新代码范围里面的问题，也就会跟着变多。

3、要去确认分支层级的设置，是不是覆盖了项目层级的设置

有些项目，它的主分支和功能分支，各自的节奏是不一样的，这个时候，就可以在分支的层面，单独去调整新代码的定义。比如说，主分支按照版本来计算，功能分支则按照参考分支来计算。在设置完成了以后，需要把结果保存下来，并且重新去分析一次，否则页面上显示出来的，有可能还是上一次分析留下来的结果。

二、SonarQube新代码周期影响门禁结果怎么看

新代码周期会直接影响到质量门禁，尤其是在门禁的条件，是被设置在新代码上面的情况。比如说新代码的覆盖率、新代码的重复率、新增的漏洞、新增的Bug、新增的代码异味，这几样东西，都是和周期的边界，有关系的。

1、先去看一看门禁没有通过的那些条目

在【Quality Gate】这个页面里面，去查看一下那些没有通过的条件，到底是落在了新代码的指标上面，还是落在了整体代码的指标上面。

要是没有通过的，是新代码的覆盖率，那就说明在当前这个周期以内，新增加的，或者是被修改过的代码，它的测试覆盖，是不足的；要是没有通过的，是整体的覆盖率，那么这个问题，就是来自于全项目的历史状态。这两种情况，处理的思路是不一样的，不能把它们给混在一起看。

2、把新代码的状态，和整体代码的状态，拿来做一下对比

有些项目，整体的历史问题是比较多的，可是新代码的质量，却还是很不错的，在这种情况下面，门禁也是有可能通过的；反过来，也有些项目，历史的代码，看上去还可以，但是最近一段时间，提交的代码引入了高风险的毛病，那么门禁，就同样会过不去。SonarQube所提倡的Clean as You Code这个思路，它本来就是要去优先守住新代码，避免质量再继续往下滑。

3、去检查一下周期的边界，是不是合理的

如果门禁突然之间就失败了，这倒也不一定，就代表代码是突然变差了，它也有可能是因为新代码的周期，被人为地调整过了。比如说，从三十天被改成了九十天以后，就会有更多的历史改动，被算进了新代码里面；从参考分支被改成了上一个版本以后，周期的边界，也会跟着发生变化。在做排查的时候，是需要把新代码的定义、最后一次分析的时间、项目的版本号，还有分支之间的关系，这几样东西，都放在一起来看的。

三、SonarQube新代码周期怎么避免配置混乱

新代码周期，一旦在配置上面出现了混乱，团队内部就很容易产生争论，“为什么昨天还能通过，今天就过不去了”。所以最好的办法，是先把周期的策略给固定下来，并且把它和分支的策略、发布的策略，还有门禁的规则，放在一起去管理。

1、要把主分支和功能分支，分开来去考虑

主分支，通常情况下，会更加适合按照版本，或者是固定的周期去管理；功能分支，则更加适合去和目标分支，进行对比。这样一来，开发的人员，就能比较清楚地知道，本次提交的这些代码，它到底带进来了哪些新的问题，而不是被一大堆历史的问题，给干扰了判断。

2、在版本发布的时候，要同步地去更新项目的版本号

如果是采用了上一个版本这种方式，那就要在扫描的参数里面，去维护好项目的版本。版本号要是没有及时被更新，那么新代码的周期，就有可能会一直停留在旧的边界上面，这样一来，就会把新旧的问题，都搅和到了一起。在版本发布的流程里面，最好是能把扫描的参数、发布的标签，还有SonarQube的分析，这几样东西，都保持一致。

3、门禁的条件，不要搞得过于复杂

质量门禁这边，最好是能重点去关注新代码里面的那些严重问题、覆盖率、重复率，还有安全方面的问题。门禁的条件要是太多了，开发的人员，就不清楚应该先从哪里下手去修；条件要是太松了，那它拦截的作用，也就没有了。一个比较实际的做法，是先去把新代码的质量给守住了，然后再一步一步地，去消化掉那些历史遗留下来的问题。

总结

SonarQube新代码周期应当怎样去设置，以及新代码周期对门禁结果的影响又要怎样去查看，这两件事的关键，是要先去确定项目到底是按照版本、按照天数，还是按照参考分支，来定义新代码。新代码周期，会影响到哪些问题被拿进到门禁的判断里面，尤其是会影响到新代码的覆盖率、重复率，还有新增问题的数量。在做门禁结果的排查时，不能只是去看它是通过了，还是没有通过，而是要同时去看一下没有通过的条件、新代码的定义、分支之间的关系，还有项目的版本。等到周期的边界，都弄得比较清楚了以后，SonarQube门禁的结果，解释起来也就会更加容易了。