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

「前言」

你是否清楚的了解本身的项目有多少个文件夹、多少个文件、多少行代码、多少个函数、多少个字符数？
你是否在项目中引入过代码质量检测相关的工具？
你是否在不一样项目的切换中饱受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端架构实现

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

Web端页面展现

咱们经过该web框架展现目标项目执行结果。

总结

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

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

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

做者简介： J文，15年加入「美团点评」，目前就任于 点评点餐终端团队，咱们期待您与咱们一块儿打造将来的“智能餐厅”。