阅读 982

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

「前言」

你是否清楚的了解自己的项目有多少个文件夹、多少个文件、多少行代码、多少个函数、多少个字符数?
你是否在项目中引入过代码质量检测相关的工具?
你是否在不同项目的切换中饱受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 Servergit 仓库完成相关‘解锁’步骤。

使用的技术栈

而在该项目中,我们使用的技术栈包括:

  • Nuxt + koa + WebSocket
  • Apollo + GraphQL
  • Jenkins + Plugin
  • Shell + Python

这篇文章定位是项目整体介绍,故而不涉及具体实现细节,后续我们会有系列文章和大家一起分享功能实现中遇到的问题。

Jenkins Server架构

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端架构实现
Node Web端架构实现

2016 年 10 月 25 日,zeit.co 背后的团队对外发布了 Next.js,一个 React 的服务端渲染应用框架。几小时后,与 Next.js 异曲同工,一个基于 Vue.js 的服务端渲染应用框架应运而生,我们称之为:Nuxt.js

Web端页面展示
Web端页面展示

我们通过该web框架展示目标项目执行结果。

总结

本文主要讲解“代码质量检测平台”项目从需求收集、提取、架构设计以及最终的实现。
这套架构体系对我们的开发者提出了较高的要求,在业务项目接入中,我们遇到了很多困难:

  • 如何制定统一规则
  • 如何本地化脚本任务
  • 如何将graphql集成到nuxt中
  • 如何控制单个项目对jenkins任务的重复触发
  • 如何解决脚本+web导致的linux文件打开数上线问题
  • 如何在多端同步jenkins任务状态

想要更多的了解我们是如何解决这些难题的, 请点击下方“❤️”,并关注我们吧。
我们会有系列文章来和大家一起分享我们与「代码质量检测平台」的故事。

作者简介: J文,15年加入「美团点评」,目前就职于 点评点餐终端团队,我们期待您与我们一起打造未来的“智能餐厅”。

评论