jekins 发布前的质量门禁方案有什么比较好的方式吗

[wymisgod]

公司最近在弄开发绩效，效能这一块的东西。其中有一个环节是针对代码质量进行一个门禁设置，目的是把一些问题提前暴露到每一次提交/发布的节点中去。

目前的工具链只有私有化 jekins 和私有化 sonarQube 这两个。
期望是在 jekins 发布某一个环境的时候，会扫描到同样是这个环境以及启动参数的那一次发布。再把最新的代码 commit 以及定位到的发布他俩之间的 commit 产生的变化代码全部统计起来，形成类似于 idea 里针对单个 commit 的 compare branch with local 一样的视图，把这个视图变化，丢给 sonarQube 进行代码质量扫描。如果触发了阈值，则给出一份报告，同时拒绝环境发布，直到代码质量在阈值以下。

目前来说这个只是一个想法，不知道能否实现，以及实现难度如何。

关于为什么需要扫描增量代码：公司里的项目比较多，部分是祖传代码了，如果全量扫描，可能只改了一行，时间代价太大。
为什么用 sonarQube：目前不知道有没有其他的产品做这个的。

领导现在想要的：1.能够有个门禁控制质量。2.先对一些项目试点，先能产生一些数据报表出来。3.不影响业务组的开发

各位有没有什么好的方案教教我

[LeslieLeung]

GitLab + SonarQube 吧，在 push / pr 的时候触发检查。如果你们是 pr 工作流，那可以在 GitLab 禁止它 merge ； push 的话也可以加 hook 解决，这个我不太了解。

整套走通不麻烦，SonarQube 有很完整的 onboarding 流程，关键在这个「代码质量」。每个团队都会有不同的认知，有些是 nit （可改可不改，风格/旧的用法等等），有些可能是屎山（太过复杂的函数之类），很难推动实际业务开发去改，尤其是如果时间/人力不足的情况下。国内公司小团队的话，最后都是不了了之，所谓的「研发效能」还不是看 loc 。

[wymisgod]

@LeslieLeung 目前还没有解决统计两次发布之间的 commit 的增量扫描，我还没找到 sonarQube 里增量代码扫描的办法，如果按照大哥你的说法可以搞，那还是有的玩。

至于代码质量的话，目前肯定是只有用内嵌的规则/开源规则/插件规则（比如阿里 coding guide)等等方式，还没有走到需要自定义规则或者复杂规则那一步。

领导目前是想快速出产出出来，搞一个东西，快速验证可行性

[Charkey]

一样的要所谓研发精细化管理，还没招