Reviewbot 开源 | 为什么我们要打造本身的代码审查服务？ ...

---

   Reviewbot 是七牛云开源的一个项目，旨在提供一个自托管的代码审查服务, 方便做 code review/静态检查, 以及自定义工程规范的落地。
  —

静态检查不是个希奇事。
我记得早在几年前，我们就调研并利用过 sonarqube 做静态检查，但当时并没有大范围的推广。重要原因在于，一是发现的标题多数是风格标题，较少能发现缺陷; 二是 sonarqube 社区版的 worker 数有限制，满足不了我们大规模代码扫描的需求。当然，也是因为前一个标题，感觉付费并不是很划算。
而由于七牛重要利用 golang 语言，以是在静态检查方面，我们基本利用 go vet/fmt/lint 等，再就是后来的 golangci-lint，似乎也够用了。
但随着代码仓库的增多，以及对工程规范的不断强化，我们越来越发现当前的落地方式，已经开始无法满足我们的需求。
Linter 工具的引入与更新标题

以 golangci-lint 为例，它是 go 语言 linters 聚合器，内置了 100+ linters，利用也很简单, golangci-lint run 一条命令即可。但你知道吗？假如没有特别配置，你这条命令其实仅仅实行此中的 6 个 linter，绝大部门 linters 都没有实行！
另外，工具本身需要更新，且很多时间我们也会本身定制 linter 工具，这种时间该怎么做呢？假如仅有少量仓库，可能还好，但假如仓库很多，那维护资本就上去了。
还有就是新业务，新仓库，如何包管相关的检查可以或许及时配置，相关的规范可以或许精确落地？
靠自觉一定是不可的。
Linter 标题的发现与修复情况

如何确保发现的标题可以或许被及时修复？如何让标题能更及时、更容易的被修复？
埋藏在大量 raw log 中的标题，一定是不容易被发现的，查找起来很贫苦，体验很差。
历史代码仓库的存量标题，谁来改？改动就需要时间，但实际上很多业务研发可能并没有动力来跟进。同样，变动总是有风险的，有些 lint 标题修复起来也并不简单，假如因修复 lint 标题而引入风险，那就得不偿失了。
假如想了解当前组织内 lint 标题的分布及修复情况，又该怎么办呢？
如何办理，方向在哪里？

不可否认，linter 标题也是标题，假如每行代码都能进行充实的 lint 检查，那一定比不检查要强。
另一方面，组织内订定好的工程规范，落地在日常的开辟流程中，那一定是希望被遵守的，这类就是强需。
以是这个事情值得做，但做的方式是值得思索的，尤其是当我们有更高追求时。
参考 CodeCov 的服务方式，以及 golangci-lint reviewdog 等工具的设计理念，我们认为:

• 假如能对于新增仓库、历史仓库，不需要专人配置 job，就能自动见效，那一定是优雅的
  
• 假如能只针对 PR/MR 中的变动做分析和反馈，类似我们做 Code Review 那样，那对于提 PR 的同学来讲一定是优雅的，可接受的，顺手修复的可能性极大
  
  
  
  • 而进一步，针对 PR/MR 中涉及的文件中的历史代码进行反馈，在公道推动下，支持夹带修改，持续改进的可能性也会大大增强
    
  
  
• Lint 工具多种多样，或者我们本身开辟出新工具时，可以或许较为轻松的让所有仓库都自动见效，那也一定是非常赞的，否则就可能陷入工具越多负担越重的风险
  

基于上面的思索，我认为我们需要的是: 一个中心化的 Code Review/静态检查服务，它能自动接受整个组织内 PR/MR 事件，然后实行各种预定义的检查，并给与准确到变动代码行的有效反馈。它要能作为代码门禁，持续的保障入库代码质量。
而 Reviewbot 就是这样一个项目。
Reviewbot 在设计和实现上有哪些特点？

面向改进的反馈方式
这将是 Reviewbot 反馈标题的核心方式，它会尽可能充实利用各 Git 平台的自身本事，准确到变动的代码行，提供最佳的反馈体验。

• Github Check Run (Annotations)
  
  
  
  
• Github Pull Request Review (Comments)
  
  
  
  

支持多种 Runner
Reviewbot 是自托管的服务，推荐大家在企业内自行摆设，这样对私有代码更友好。
Reviewbot 自身更像个管理服务，不限制摆设方式。而对于任务的实行，它支持多种 Runner，以满足不同的需求。好比:

• 不同的仓库和 linter 工具，可能需要不同的底子环境，这时间你就可以将相关的环境做成 docker 镜像，直接通过 docker 来实行
  
• 而当任务较多时，为了实行服从，也可以选择通过 kubernetes 集群来实行任务。
  

利用也很简单，在配置文件中的目标仓库指定即可。类似:

1. dockerAsRunner:
2.   image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.22.3-gocilint.1.59.1"

复制代码

1. kubernetesAsRunner:
2.   image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.23.2-gocilint.1.61.0"
3.   namespace: "reviewbot"

复制代码

零配置+定制化
本质上，Reviewbot 也是个 webhook 服务，以是我们只需要在 git provider 平台配置好 Reviewbot 的回调地点即可(github 也可以是 Github App)。
绝大部门的 linter 的默认最佳实行姿势都已经固定到代码中，如无特别，不需要额外配置就能对所有仓库见效。
而假如仓库需要特别对待，那就可以通过配置来调整。
类似:

1. org/repo:
2.   linters:
3.     golangci-lint:
4.       enable: true
5.       dockerAsRunner:
6.         image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.22.3-gocilint.1.59.1"
7.       command:
8.         - "/bin/sh"
9.         - "-c"
10.         - "--"
11.       args:
12.         - |
13.           source env.sh
14.           export GO111MODULE=auto
15.           go mod tidy
16.           golangci-lint run --timeout=10m0s --allow-parallel-runners=true --print-issued-lines=false --out-format=line-number >> $ARTIFACT/lint.log 2>&1

复制代码

可观察
Reviewbot 是在对工程规范强管理的背景下产生的，那作为工程规范的推动方，我们天然有需求想了解组织内当前规范的实行情况。好比, 都有哪些标题被检出？哪些仓库的标题最多？哪些仓库需要特别配置？
现在 Reviewbot 支持通过企业微信来吸收关照，好比:

• 检出有效标题
  

• 遇到错误
  

当然，将来可能也会支持更多方式。
   其他更多的功能和姿势，请参考仓库: https://github.com/qiniu/reviewbot
  Reviewbot 的将来规划

作为开源项目，Reviewbot 还需要办理很多可用性和易用性标题，以提拔用户体验，好比最典范的，接入更多的 git provider(gitlab/gitee 等)，支持 CLI 模式运行。
但我个人认为，作为 code review 服务，提供更多的检测本事，才是重中之重。因为这不光是行业需求，也是我们自身需要。
以是背面我们除了会引入七牛内部推荐的规范，也会调研和探索更多的行业工具，同时会考虑引入 AI，探索 AI 在 code review 中的应用等等。
Anyway，Reviewbot 还很年轻，我们在持续的改进中，非常欢迎大家试用并提出宝贵意见。当然，更欢迎大家一起参与到项目建立中来。
感谢大家。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。