前端初探 Gitlab CI/CD

前言

縱觀人類歷史的發展以及三次工業革命，你會發現利用機器來替代部分人力勞動，將重複的工做自動化從而解放生產力都是發展的必然趨勢，在軟件工程領域也不例外，其中 CI/CD 就是其中一項，那麼什麼是 CI/CD 呢，網上的解釋不要太多，這裏我就直接放一幅 Gitlab 官網的工做流程圖好了：

準備條件

1. Gitlab runner
2. .gitlab-ci.yml

Gitlab runner

Gitlab runner 是整個 CI/CD 的執行器，它是執行你寫的 .gitlab-ci.yml 文件的虛擬機。
Gitlab runner 分爲兩種：

1. 特定的 runner：只能當前項目使用
2. 共享的 runner：全部項目均可以使用

找到你的項目在 設置>Runners 裏
你能夠看到以下界面：

左側就是特定的 runners 右側就是共享的 runners，只要確保有其一就行。
關於 runner 的安裝我不想過多贅述，官網寫的很清楚，只要按照步驟一步一步搭建就行了。

.gitlab-ci.yml

當你有了 runner 就能夠開始着手寫 .gitlab-ci.yml 文件了，.gitlab-ci.yml 文件是對於整個 CI/CD 流程的描述文件，它告訴 runner 應該怎樣執行具體的操做。
在具體介紹配置以前，我想先明確整個 .gitlab-ci.yml 裏面的幾個重要名詞：

1. job: job 是整個 CI/CD 的核心單元，它定義了在什麼條件下應該執行什麼任務，每一個 job 都是相互隔離的。
2. script: job 下的屬性，用於描述 job 要執行的任務。
3. stages: 定義 job 的分組，不一樣 job 能夠所屬於不一樣的階段，一共有三個階段可供選擇：test build deploy，stage 的執行是按順序的，可是 stage 下面的 job 是並行執行的，只有前一個 stage 執行成功纔會執行下一個 stage，一旦上一個 stage 中任何一個 job 執行失敗都會致使整個流水線失敗。
4. pipeline: 上面的整個流程就是一個流水線。

下面是個人一個前端項目的 .gitlab-ci.yml 文件，以它來做爲示例：

image: node:10.13
      
stages:
  - test
  - build
  - deploy
  
cache:
  paths:
    - node_modules/
    
before_script:
  ## set proxy
  - export http_proxy=http://10.2.3.63:3128/
  - export https_proxy=http://10.2.3.63:3128/

test:
  stage: test
  tags:
    - sams
  script:
    - npm install --no-optional --registry=https://registry.npm.taobao.org
    - npm run lint
  only:
    - master
    - dev

build:
  stage: build
  tags: 
    - sams
  script:
    - npm run build
  artifacts:
    paths:
      - $SOURCE_DIR
    expire_in: 2 mins
  only:
    - master

deploy:
  stage: deploy
  tags: 
    - sams
  before_script:
    ## set debian mirros
    - echo 'deb http://mirrors.aliyun.com/debian/ stretch main non-free contrib' > /etc/apt/sources.list
    - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch main non-free contrib' >> /etc/apt/sources.list
    - echo 'deb http://mirrors.aliyun.com/debian-security stretch/updates main' >> /etc/apt/sources.list
    - echo 'deb-src http://mirrors.aliyun.com/debian-security stretch/updates main' >> /etc/apt/sources.list
    - echo 'deb http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib' >> /etc/apt/sources.list
    - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib' >> /etc/apt/sources.list
    - echo 'deb http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib' >> /etc/apt/sources.list
    - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib' >> /etc/apt/sources.list
    ## Using SSH keys with GitLab CI/CD
    ## https://docs.gitlab.com/ee/ci/ssh_keys/README.html
    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
  script:
    - scp -r $SOURCE_DIR $DEPLOY_SERVER_USER@$DEPLOY_SERVER_IP:$TARGET_DIR
  only:
    - master
  environment: test

全局配置

• image: 要使用的 docker 鏡像它會根據你寫的鏡像名從 docker hub 上面拉取鏡像，由於咱們的項目是前端項目，因此這裏配置的鏡像是 node，最終你的 script 指定的腳本會跑在 node 的 docker 環境下，這樣就保證你有了必要的環境依賴（node）
• stages: 定義整個流水線的各個階段，這裏我三個階段都定義了，可是你能夠根據你本身項目的實際狀況定義，定義好後流水線將按照你定義的順序依次執行。
• cache: 定義 job 之間要緩存的文件，一般咱們都會把項目的安裝依賴做爲緩存，這樣下一個 job 就不用從新安裝依賴了
• before_script: 定義全部 job script 執行前須要執行的腳本，這裏我設置了代理。

job 的配置

• stage: 定義該 job 所屬的 stage
• tags: 指定該 job 使用的 runner
• script: 該 job 須要執行的腳本
• only: 該 job 的約束條件，你能夠指定該 job 在哪些狀況下會觸發，好比只有 master 分支和 develop 分支纔會執行 deploy 的 job，與此相對的還有一個 except 屬性表示什麼條件下不執行該 job
• artifacts: 用於在不一樣 stage 之間傳遞結果，通用的作法是將 build 階段打包出來的文件定義爲 artifacts，這樣在 deploy 階段就能夠直接使用了，這裏你可能會對 artifacts 和 cache 有些搞不清，這裏推薦看官方的說明
• environment: 用於定義 job 部署的環境，這裏須要結合 Gitlab 項目的 UI 界面，好比這裏我設置的名稱叫 test，每次部署成功以後 test 環境下就會多一個部署條目，你能夠從新部署甚至回滾到某個部署，以下圖所示：

另外 environment 下還有一個 url 屬性能夠定義部署到的服務器地址，這樣你能夠在 UI 界面經過點擊按鈕直接跳轉到項目，若是你的 Gitlab 低於 8.11 那隻能經過在 UI 界面（上圖）手動配置了。

ssh keys 實現免密登陸

通常來說你部署項目的時候不可避免會用到 ssh 協議，可是 ssh 協議須要你手動輸入用戶名和密碼，這樣不就沒法實現自動化部署了？ 別急，Gitlab 已經幫咱們想到了這一點，仔細閱讀官網上的 Using SSH keys with GitLab CI/CD 這篇文章你就能找到解決方案，或者參考個人實例代碼：

## Using SSH keys with GitLab CI/CD
## https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
- chmod 644 ~/.ssh/known_hosts

這裏我仍是要簡單說一下其實現原理，Gitlab 首先讓你生成一對 ssh 的公鑰和私鑰，在每次執行 CI/CD 時將私鑰（此時已添加到環境變量裏）經過 ssh-add 添加到 ssh-agent 裏面進行管理，並將設置好的 $SSH_KNOWN_HOSTS (裏面就包含了你要 shh 的主機) 也添加到 known_hosts 文件中，這樣在執行 ssh 命令時遠程機器就能識別你的身份從而實現免密登陸，本質上和你本地實現免密登陸的道理是同樣的。

其它

環境變量

相似於編程中的變量，環境變量能夠存儲一些要要變化的或是比較私密的信息，環境變量配置好後能夠經過 $ + 變量名 在 script 裏面進行調用

查看流水線狀態

在 Gitlab 主頁找到流水線頁籤，打開以後就能看到全部流水線的運行狀況

點擊進入具體的 stage 你能夠看到其執行細節，若是失敗也能夠從新執行

參考資料

https://docs.gitlab.com/ee/ci...

總結

此次也是我初次嘗試使用 Gitlab CI/CD ，每次任務大概執行須要 8 分鐘，若是你像以前手動去作這些工做那你每次都至少須要花費 8 分鐘時間，不要小瞧這 8 分鐘，日積月累也是一筆不小的開支，更重要的是機器不多出錯的，可是人的話就無法保證了，並且就像我在開篇所說簡單重複性的工做必然會被機器取代，這是不可避免的歷史規律，無論你用不用它，技術的潮流都會不斷向前推進，因此還不如提早擁抱它。 另外這次只介紹了整個 Gitlab CI/CD 功能的冰山一角，Gitlab 還提供不少優秀的功能，好比在 merge request 的時候進行 CI/CD，因此更多的功能還有待挖掘，若是你感興趣能夠去官方文檔上找尋，若是有什麼不對的地方還請您指正，最後感謝您的閱讀！