代码质量检测平台架构设计

发表于:2022-8-25 09:51

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:曾经沧海    来源:知乎

分享:
  前言
  你是否清楚的了解自己的项目有多少个文件夹、多少个文件、多少行代码、多少个函数、多少个字符数?
  你是否在项目中引入过代码质量检测相关的工具?
  你是否在不同项目的切换中饱受indent=2还是indent=4的困扰?
  你是否怀疑过自己的代码存在性能问题和内存泄露?
  赶快和我一起来学习如何搭建一套持续集成的代码质量检测平台,为日常项目开发“保驾护航”吧~
  背景
  我们团队有多条业务线,每条业务线都有很多子业务项目,每个业务项目使用的技术栈都各不相同,每天有很多业务迭代需求,每次提交的merge request都需要相关同事完成code review之后才可以 merge 代码,这更是增加大量的人力成本。
  不同业务框架使用不同的技术栈,不同技术栈引入不同的coding style,这更是导致开发者在开发过程中无法适从,无统一的标准,导致编程风格混乱。
  有些开发者由于迭代需求多或者临时bug修复等原因直接跳过代码质量检查,上线后由于粗心大意产生一些低级bug导致线上故障。
  简单的code review只能解决代码风格问题,而很难发现重复度、复杂度,case通过率等方面的问题。
  预期
  对于在日常开发中遇到的这些问题,我们期望能有这样一套系统,它能够帮助我们解决以下问题:
  可视: 我们希望这个系统能够方便、直观的查看到代码存在的问题;
  统一规范:不同的项目运用统一的代码检测规则,方便团队进行多项目管理,降低开发者上手成本;
  规范且定量:建立一套对检测结果通用的评分标准,方便我们定量的了解项目代码健康度;
  多维度全方位:提供多维度代码检测工具;
  优化建议:代码质量检查后提供相关优化建议;
  项目功能点实现
  持续集成:通过code Merge Request持续触发检测;
  配置中心化:统一的配置管理,包括检测任务,检测需要用到的规则;
  多维度:开始我们加入 code lint 和代码重复率检查;
  可视化:web页面查看项目的检测评分与各子项详细检测结果;
  评价体系:建立符合实际需求的评价标准体系;
  整体架构
整体架构图
  项目主要通过提交 Merge Request 触发 git hook,该请求发送merge相关数据至中间层 Node Server,Node 层将请求透传到 Jenkins Server, Jenkins Server 启动Job并执行相关检测脚本,任务完成callback通知 Node Server 和 git 仓库完成相关‘解锁’步骤。
  使用的技术栈
  而在该项目中,我们使用的技术栈包括:
  ·Nuxt + koa + WebSocket
  · Apollo + GraphQL
  · Jenkins + Plugin
  · Shell + Python
  这篇文章定位是项目整体介绍,故而不涉及具体实现细节,后续我们会有系列文章和大家一起分享功能实现中遇到的问题。
  Jenkins Server架构
Jenkins Server架构图
  Jenkins Server根据收到的请求调起对应Job, 在对应Job执行完成后触发回调,通知开发者、Node Server中间层任务已经结束。
  Jenkins是一个比较成熟,普遍用于持续集成框架,它通过安装插件便可支持各种任务模式。
  在该这个项目中,我们自己开发 plugin 完成参数统一化和回调触发。
  脚本框架
原始结果产出
  我们将jenkins需要执行的脚本放在一个代码仓库中管理,而jenkins job只负责拉取脚本代码,并执行入口文件。
  import os
  import sys
  gitRemote = 'ssh://git@***********.com/litmus.git'
  # 拉取代码仓库, 切换cwd为脚本目录
  if os.path.isdir('litmus'):
    os.chdir('litmus')
    os.system('git fetch origin && git reset --hard origin/master')
  else:
    os.system('git clone %s --depth=1' % gitRemote)
    os.chdir('litmus')
  # 安装依赖,执行入口文件
  os.system('npm install')
  sys.path.append('entry')
  import web
  result = web.main(None, None)
  我们的脚本执行结果都是以文件的形式产出,而这套文件产出结果将会成为我们提供web页面展示的原始数据输入。
  Node Web端架构
Node Web端架构实现
Web端页面展示
  我们通过该web框架展示目标项目执行结果。
  总结
  本文主要讲解“代码质量检测平台”项目从需求收集、提取、架构设计以及最终的实现。
  这套架构体系对我们的开发者提出了较高的要求,在业务项目接入中,我们遇到了很多困难:
  ·如何制定统一规则
  · 如何本地化脚本任务
  · 如何将graphql集成到nuxt中
  · 如何控制单个项目对jenkins任务的重复触发
  · 如何解决脚本+web导致的linux文件打开数上线问题
  · 如何在多端同步jenkins任务状态
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号