程式碼質量檢測平臺架構設計

美團點評點餐發表於2017-08-22
架構

「前言」

你是否清楚的瞭解自己的專案有多少個資料夾、多少個檔案、多少行程式碼、多少個函式、多少個字元數？
你是否在專案中引入過程式碼質量檢測相關的工具？
你是否在不同專案的切換中飽受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架構圖

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年加入「美團點評」，目前就職於 點評點餐終端團隊，我們期待您與我們一起打造未來的“智慧餐廳”。

相關文章