代碼質量檢測平臺架構設計

時間 2019-12-05

原文原文鏈接

「前言」

你是否清楚的瞭解本身的項目有多少個文件夾、多少個文件、多少行代碼、多少個函數、多少個字符數？
你是否在項目中引入過代碼質量檢測相關的工具？
你是否在不一樣項目的切換中飽受indent=2仍是indent=4的困擾？
你是否懷疑過本身的代碼存在性能問題和內存泄露？
趕快和我一塊兒來學習如何搭建一套持續集成的代碼質量檢測平臺，爲平常項目開發「保駕護航」吧~node

背景

咱們團隊有多條業務線，每條業務線都有不少子業務項目，每一個業務項目使用的技術棧都各不相同，天天有不少業務迭代需求，每次提交的merge request都須要相關同事完成code review以後才能夠 merge 代碼，這更是增長大量的人力成本。
不一樣業務框架使用不一樣的技術棧，不一樣技術棧引入不一樣的coding style，這更是致使開發者在開發過程當中沒法適從,無統一的標準，致使編程風格混亂。
有些開發者因爲迭代需求多或者臨時bug修復等緣由直接跳過代碼質量檢查，上線後因爲粗枝大葉產生一些低級bug致使線上故障。
簡單的code review只能解決代碼風格問題，而很難發現重複度、複雜度，case經過率等方面的問題。

預期

對於在平常開發中遇到的這些問題，咱們指望能有這樣一套系統，它可以幫助咱們解決如下問題：linux

可視：咱們但願這個系統可以方便、直觀的查看到代碼存在的問題；
統一規範：不一樣的項目運用統一的代碼檢測規則，方便團隊進行多項目管理，下降開發者上手成本；
規範且定量：創建一套對檢測結果通用的評分標準，方便咱們定量的瞭解項目代碼健康度；
多維度全方位：提供多維度代碼檢測工具；
優化建議：代碼質量檢查後提供相關優化建議；

項目功能點實現

持續集成：經過code Merge Request持續觸發檢測；
配置中心化：統一的配置管理，包括檢測任務，檢測須要用到的規則；
多維度：開始咱們加入 code lint 和代碼重複率檢查；
可視化：web頁面查看項目的檢測評分與各子項詳細檢測結果；
評價體系：創建符合實際需求的評價標準體系；

總體架構

項目主要經過提交 Merge Request 觸發 git hook，該請求發送merge相關數據至中間層 Node Server，Node 層將請求透傳到 Jenkins Server, Jenkins Server 啓動Job並執行相關檢測腳本，任務完成callback通知 Node Server 和 git 倉庫完成相關‘解鎖’步驟。git

使用的技術棧

而在該項目中，咱們使用的技術棧包括：web

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

這篇文章定位是項目總體介紹，故而不涉及具體實現細節，後續咱們會有系列文章和你們一塊兒分享功能實現中遇到的問題。npm

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)複製代碼