前端持續集成之—— Gitlab CI

Gitlab CI/CD

開發者推送、提交代碼到Gitlab，Gitlab通過項目的 .gitlab-ci.yml 文件配置，找到指定的項目gitlab runner，runner運行相關的命令，進行編譯、 集成、測試、交付、部署，一切順利地話會分發到各個服務器（測試服務器、預發佈服務器、正式服務器等），此時一個迭代開發上線流程走完。

GitLab Runner

GitLab Runner是一個開源項目，用於運行項目持續集成、持續部署作業並將結果發送回GitLab，與GitLab CI/CD一起使用。GitLab Runner是用Go編寫的，可以作爲單個二進制文件運行，不需要語言特定的要求，運行在Linux，macOS和Windows操作系統上。只要您可以在其上編譯Go二進制文件，其他操作系統可能會起作用，也可以運行在Docker上。

流程摸索

經過一段時間的摸索，總結了一套常用的 CI 流程：

1. 首先需要在項目的根目錄下創建 .gitlab-ci.yml 文件，該文件描述了整個 CI 流程將要做什麼事情。是 CI 流程的核心配置文件
2. 在測試、預發、生產三個環境的打包服務器上安裝 Gitlab Runner，並分別註冊一個 runner。這些 runner 是用來執行具體任務的，比如安裝依賴、打包、執行單元測試等等
3. 當你 push 代碼到開發分支 xxx.feature.dev 時，GItlab 服務器會判斷項目中有沒有 .gitlab-ci.yml 文件，如果有便會觸發 CI 流程。然後根據該文件的配置，去通知測試環境的打包服務器上的 runner，執行
   1. npm install 安裝依賴
   2. npm run test 編譯打包，爲了更好的排查問題，測試環境可以不用壓縮 js
   3. npm run unit 執行單元測試
   4. npm run copy 將編譯後的靜態目錄 /dist 拷貝到目標服務器
   5. 目標服務器重啓服務
4. 當測試環境的目標服務器重啓後，測試同學開始測試，然後將測出的 bug 提給開發。開發修復完 bug 之後又回到第 3 步，如此反覆循環幾次，bug 已被修復完成，進入下一步
5. 這時測試同學會將你的開發分支 xxx.feature.dev 合併到預發分支 release 。這時 Gitlab 服務器發現 .gitlab-ci.yml 中配置了 release 分支被 push 時所要執行的 job。於是通知預發環境的打包服務器執行
   1. npm install 安裝依賴
   2. npm run build 編譯打包，爲了更接近生產環境，需要將 js、css 等進行壓縮
   3. npm run copy 將編譯後的靜態目錄 /dist 拷貝到目標服務器
   4. 目標服務器重啓服務
6. 當預發環境的目標服務器重啓後，測試同學如果發現還有問題，就會重新進入第 3 步。否則通知產品、視覺進行驗收，如果發現與需求、視覺稿有出入，會通知開發修改，重新進入第 3 步。否則進入下一步
7. 一切驗證、準備就緒之後，開發人員將預發 release 分支合併到 master，這時 Gitlab 服務器發現 .gitlab-ci.yml 中配置了 master 分支被 push 時所要執行的 job。於是通知生產環境的打包服務器執行
   1. npm install 安裝依賴
   2. npm run build 編譯打包
   3. npm run copy 將編譯後的靜態目錄 /dist 拷貝到目標服務器
   4. 目標服務器重啓服務
8. 一個迭代開發上線流程完成

最佳實踐

該教程均在 centos7、node10.15.3 環境下執行

編寫 .gitlab-ci.yml 文件

首先在項目的根目錄下創建 .gitlab-ci.yml 文件，內容如下。該文件只是展示了生產環境的配置，其他兩個環境類似，只要多加幾個 job 就行了。但是要注意 job 是安從上到下的順序執行的，所以你應該按照 測試、預發、生產 的順序來寫 job。

#stages 表示整個 CI 流程分爲幾個階段，每個階段中可以運行多個 job 
stages:
  - install
  - build
  - deploy

cache:    #緩存
  #因爲緩存爲不同管道和任務間共享，可能會覆蓋，所以有時需要設置key
  key: "$CI_COMMIT_REF_NAME"  # 啓用每分支緩存。
  #key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME" # 啓用每個任務和每個分支緩存。需要注意的是，如果是在windows中運行這個腳本，需要把$換成%
  #untracked: true    #緩存所有Git未跟蹤的文件
  paths:    #以下2個文件夾會被緩存起來，下次構建會解壓出來
    - node_modules/
    - .nuxt/

.template: &templateDef  # 創建一個錨，'template'
  only:
      - master

#安裝依賴任務
job_install:
  stage: install
  <<: *templateDef           # 利用錨'templateDef'來合併
  cache:
    key: "$CI_COMMIT_REF_NAME"
    paths:
        - node_modules
  script:                    #script 秒速的是該任務需要做那些事情
    - echo "開始安裝依賴..."
    - npm i --register=https://registry.npm.taobao.org/
    - echo "完成所有依賴包的安裝" 
  only:
    - master                # 只有在 master 被 push 或者 merge 時才觸發任務"job_install"
  tags:
    - install-runner        # Gitlab 服務器會根據這個 tag 找到對應的 runner 來執行當前任務

#打包編譯任務
job_build:
  stage: build
  <<: *templateDef
  script:
    - echo "開始編譯打包"
    - npm run build
    - echo "打包成功"
  only:
    - master
  tags:
    - build-runner

#部署任務
job_deploy:
  stage: deploy
  <<: *templateDef
  script:
    - cp -Rf ./dist/* /usr/local/nginx/html    #將 /dist 下的靜態文件拷貝到 nginx/html 下
   # - /usr/local/nginx/sbin/nginx -s reload    #前端靜態文件其實不需要重啓 nginx 
  only:
    - master
  tags:
    - deploy-runner

安裝 Gitlab Runner

1. 登陸到服務器，添加官方源：curl –L https://package.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
2. 安裝：sudo yum install gitlab-ci-multi-runner-1.11.2-1
3. Runner 用戶權限：Runner 默認會在服務器上創建 gitlab-runner 用戶， 所有的 Runner Service 則默認通過該用戶執行集成腳本，因此該用戶需要較高的權限。

註冊 Runner

1、首先進入項目 setting -> CI /CD

2、展開 expend 

3、這時可以看到我們註冊 runner 時要用到的 URL 和 token

4、登陸到打包服務器上，註冊 runner，輸入 gitlab-runner register

5、註冊完成後可以，進入 setting -> CI /CD -> Runners -> Collapse 展開就可以看到多一個 runner

6、可以看到該 runner 的描述和匹配的 3 個 tag。這個 tag 是用來匹配 .gitlab-ci.yml 中配置的 job 下的 tags 字段的。拿上面的配置文件舉例，比如你註冊了多個 runner，當你往 master 上 push 代碼時

1. Gitlab 服務器首先拿到 job_install 這個任務，發現 only 字段是 master，而當前你 push 的正好是 master，那麼 Gitlab 服務器判斷 job_install 這個任務是需要執行的
2. 接着 Gitlab 服務器會檢查 job_install  下的 tags 字段是 install-runner，那麼就會去找已經註冊過的 runner 中有沒有帶 install-runner 標籤的，最後找到 runner-name 這個 runner
3. Gitlab 服務器會通知 runner-name 去拉去最新代碼，然後執行 job_install 這個任務

7、執行的日誌會實時反饋到 Gitlab 上，可以在 Pipeline 中查看。如果前一個任務執行成功，會接着自動執行下一個任務。否則流程終端，後面的任務不再執行

點擊 Pipeline 的編號，可以進入詳情

點擊每個 job 可以查看打包服務器上的日誌

8、job_install 任務執行完了之後，會接着按順序執行 job_build 、job_deploy，過程類似