一.背景

    最近了解到可以通過gitlab+jekens做程式碼的自動化部署，但是專案中並不需要自動部署。同時最近一直讓師弟在做程式碼review的事情，在想能不能通過gitlab來做程式碼的檢測。雖然通過idea阿里的外掛以及eclipse的外掛都是可以做到程式碼規範檢測，但是人都是有惰性的，最會忘記去做檢測就上傳程式碼。所以想在程式碼上傳的時候做一個限制。

二.實現過程

    瞭解了下最新的一些程式碼檢測方法，找了一種相對來說比較簡單的做法，在maven中整合checkstyle的外掛，在程式碼上傳的時候通過gitlab的CI來跑maven的build來實現檢測。

    1）maven中整合checkstyle

    在pom中插入checkstyle，更新下載相應的jar包即可。可通過mvn checkstyle:check來進行程式碼規範的檢測，當我們什麼都不配置的時候是使用的checkstyle預設的檢測規則來檢測程式碼，相對來說比阿里的規範還要嚴格。所以我們可以通過自定義規則來做相應的限制，這個道理就類似於前端的eslint和tslint來做程式碼規範一樣。

    要新增自定義規則的話我們先在專案的根目錄新建個xml，我們命名為check-style.xml。因為具體的規則太多，本文中不一一介紹，大家感興趣的可以自行百度。這邊貼上xml的內容供大家參考。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC
        "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
        "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">

<!-- This is a checkstyle configuration file. For descriptions of
what the following rules do, please see the checkstyle configuration
page at http://checkstyle.sourceforge.net/config.html -->

<module name="Checker">
    <!-- 重複程式碼的檢查，超過20行就認為重複，UTF-8格式-->
    <module name="TreeWalker">
        <!-- javadoc的檢查 -->
        <!-- 檢查所有的interface和class -->
        <module name="JavadocType">
            <property name="allowUnknownTags" value="true"/>
        </module>
        <!--<module name="JavadocMethod">-->
            <!--<property name="scope" value="private" />-->
            <!--<property name="allowMissingPropertyJavadoc" value="true" />-->
            <!--<property name="allowMissingParamTags" value="true" />-->
            <!--<property name="logLoadErrors" value="true" />-->
            <!--<property name="suppressLoadErrors" value="true" />-->
        <!--</module>-->

        <!-- 命名方面的檢查，它們都使用了Sun官方定的規則。 -->
        <!-- 區域性的final變數，包括catch中的引數的檢查 -->
        <module name="LocalFinalVariableName" />
        <!-- 區域性的非final型的變數，包括catch中的引數的檢查 -->
        <module name="LocalVariableName" />
        <!-- 包名的檢查（只允許小寫字母） -->
        <module name="PackageName">
            <property name="format" value="^[a-z]+(\.[a-z][a-z0-9]*)*$" />
        </module>
        <!-- 僅僅是static型的變數（不包括static final型）的檢查 -->
        <module name="StaticVariableName" />
        <!-- 型別(Class或Interface)名的檢查 -->
        <module name="TypeName" />
        <!-- 非static型變數的檢查 -->
        <module name="MemberName" />
        <!-- 方法名的檢查 -->
        <module name="MethodName" />
        <!-- 方法的引數名 -->
        <module name="ParameterName " />
        <!-- 常量名的檢查 -->
        <module name="ConstantName" />
        <!-- 對區域的檢查 -->
        <!-- 不能出現空白區域 -->
        <module name="EmptyBlock" />
        <!-- 所有區域都要使用大括號。 -->
        <module name="NeedBraces" />
        <!-- 多餘的括號 -->
        <module name="AvoidNestedBlocks">
            <property name="allowInSwitchCase" value="true" />
        </module>
        <!-- String的比較不能用!= 和 == -->
        <module name="StringLiteralEquality" />
        <!-- 同一行不能有多個宣告 -->
        <module name="MultipleVariableDeclarations" />
        <!-- 不必要的圓括號 -->
        <module name="UnnecessaryParentheses" />
        <module name="UncommentedMain" />
        <!-- 檢查並確保所有的常量中的L都是大寫的。因為小寫的字母l跟數字1太象了 -->
        <module name="UpperEll" />
        <!-- 檢查陣列型別的定義是String[] args，而不是String args[] -->
        <module name="ArrayTypeStyle" />
        <module name="MagicNumber">
            <property name="tokens" value="NUM_DOUBLE, NUM_FLOAT"/>
            <property name="ignoreNumbers" value="0,1"/>
            <property name="ignoreAnnotation" value="true"/>
        </module>
    </module>
</module>
 

其中註釋掉了JavadocMethod的規範，因為這個規範是要求所有實現的方法都要有doc註釋，但是自己的專案中這一條涉及到的內容過多，所以先行註釋掉。

    寫好這個檔案後我們去修改之前的pom.xml中外掛的設定，我們在properties中新增剛才規則的檔案路徑

<checkstyle.config.location>check-style.xml</checkstyle.config.location>

    外掛的設定改成如圖所示。這樣我們就實現了checkstyle的配置，我們可以通過,mvn checkstyle:check來檢視自己的程式碼有多少不規範的地方，如果有不符合規範的地方則會顯示build faile。成功的話build success，如下圖

    這樣我們就整合好了程式碼規範檢測部分，剩下的就是在gitlab中如何配置我們想要的ci了。

    2）伺服器搭建gitlab-runner

    這邊先介紹一下gitlab CI ：這個東西有兩個東西來支撐:

1. gitlab-ci server
2. gitlab-ci-runner

gitlab-ci server負責排程、觸發Runner,以及獲取返回結果. 而gitlib-ci-runner則是主要負責來跑自動化CI的一個宿主機子.具體過程可參考下圖。

    瞭解完基本的概念後我們可以來做相應的安裝，這邊不介紹gitlab的安裝，在gitlab 9.0之後已經整合好了gitlab-ci server，所以我們在伺服器上安裝好gitlab之後即可。剩下的就是在另一臺伺服器上安裝runner了，當然也可以安裝在同一臺伺服器上，但是，gitlab本身就很吃記憶體了，要跑runner的話如果同時有很多pipeline在執行的話不能保證伺服器效能，所以gitlab的伺服器還是單純用來做程式碼儲存即可。

    ok，開始安裝，具體的安裝步驟可以根據你伺服器的作業系統去gitlab的幫助文件中尋找。這邊介紹下ubuntu的安裝過程。

    1.新增repository

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

    2.安裝gitlab-ci-multi-runner

sudo apt-get install gitlab-ci-multi-runner

    3.register runner

gitlab-ci-multi-runner register

執行之後會出來一系列的配置，下面一一介紹：

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
輸入自己gitlab的地址，不需要具體到專案地址
Please enter the gitlab-ci token for this runner
輸入token，可在gitlab/setting/ci中檢視，複製過來即可
Please enter the gitlab-ci description for this runner
runner 描述
Please enter the gitlab-ci tags for this runner (comma separated):
輸入標籤，這個會在後續ci的配置中進行對應
Enter the Runner executor:
輸入要執行的環境，一般ssh即可

進行上面的配置之後我們就在伺服器上註冊好了一個runner，之後我們去gitlab的setting中可以檢視到有對應的runner。

    這裡分享一個自己在安裝時候踩過的坑，在register的時候會報404或401錯誤，原因是我們上述安裝過程會安裝最新版本的gitlab-runner但是不一定能匹配到我們gitlab的版本，所以我們在安裝前可以去官網檢視我們gitlab對應的runner可執行版本再進行安裝一般就可以解決這個錯誤了，這裡也貼上官網：https://gitlab.com/gitlab-org/gitlab-runner

    3）在專案中配置ci的pipeline

    做完上面的工作我們就把準備工作都做好了，剩下的就是在我們的專案中配置相應的指令碼。

    首先我們現在我們專案的根目錄下新建一個.gitlab-ci.yml 這個檔案是ci來識別具體操作的對應檔案，具體檔案的配置也可以百度下，因為我也沒有深究過，這裡也貼一下自己的程式碼

image: ruby:2.1

stages:
  - test

test:Project:
  stage: test
  script:
    - mvn checkstyle:check
  tags:
    - mytag

    這裡的tags對應我們剛才註冊的runner中輸入的tag。script中實現的是我們要在ci中跑的指令碼，因為我這裡要做的是程式碼檢測，所以輸入我們剛才的命令 mvn checkstyle:check即可。

三.測試

    經過上面的步驟後我們就實現了一整套流程，剩下的就是來測試下整個流程是否有問題。我們這邊程式碼上傳參考gitflow的流程，在本地新建自己的分支後進行程式碼更改後上傳到自己的分支，再發起一個merge request，在通過程式碼檢測後再把程式碼merge到我們想要的分支即可。

具體涉及到的git命令可能有:

// 新建分支並切到相應的分支
git checkout -b test
// commit程式碼
git commit -am 'test'
// push程式碼
git push origin test
// 以下的可能為有衝突時需要的命令
// 將develop分支merge到自己的分支中
git merge develop
// 刪除本地分支
git branch -D test
// 檢視本地源
git branch

上傳成功後可以在gitlab的CI/CD的pipeline中檢視自己上傳程式碼的執行情況

下面為成功和失敗的截圖

當跑成功後我們就可以發起一個merge request

這個過程不多介紹，但是發起的請求中要勾選remove when merged 選項，以保持分支的乾淨。發起後再找個人幫你把請求merge掉就好了，同時那個人也可以幫你稽核程式碼的質量，這樣就少了很多後期程式碼review的工作了。

四.總結

    整個的流程就是上述，難度雖然不大，但是可以對於第一次搭建還是挺有挑戰的，同時網上的教程也不是很多很全，所以需要自己多查，多總結。在這個基礎上後續可以做一些自動化部署的任務。之後如果有嘗試的話再做分享！