ToB企服应用市场:ToB评测及商务社交产业平台

标题: Reviewbot 开源 | 为什么我们要打造自己的代码检察服务？ [打印本页]

作者: 笑看天下无敌手 时间: 2024-11-7 13:36
标题: 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 集群来执行任务。

使用也很简单，在配置文件中的目标堆栈指定即可。类似:

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

复制代码

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

复制代码

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

org/repo:
linters:
golangci-lint:
enable: true
dockerAsRunner:
image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.22.3-gocilint.1.59.1"
command:
- "/bin/sh"
- "-c"
- "--"
args:
- |
source env.sh
export GO111MODULE=auto
go mod tidy
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企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)