你知道什麼是 GitHub Action 麼？

極客挖掘機發表於2020-04-25

Github

本文是 GitHub Action 的入門教程，如您已有相關使用經驗可以直接關掉。

GitHub Action 是 GitHub 於 2018 年 10 月推出的一個 CI\CD 服務。

之前一直都是 Beta 版本，正式版於 2019 年 11 月正式推出。

首先還是先放幾個官方的連結：

GitHub Action ： https://github.com/features/actions

GitHub Action 官方市場： https://github.com/marketplace?type=actions

CI\CD

CI\CD 其實說的是三件事情：「持續整合（Continuous Integration）」、「持續交付（Continuous Delivery）」、「持續部署（Continuous Deployment）」。

因為「持續交付」和「持續部署」的英文縮寫是一樣的，所以這三件事情縮寫成了 CI\CD 。

持續整合

那麼什麼是「持續整合」？借用一幅圖：

從這幅圖上可以很清楚的看到「持續整合」的流程：

開發人員提交程式碼到 Source Repository （原始碼倉庫），並通過 git hook 等
觸發 CI Server（持續整合伺服器）的相關功能。執行編譯 -> 測試 -> 輸出結果的流程
向開發人員反饋結果的 report

我們在日常開發中經常使用到的整合方式是「階段整合」（完成一個階段的開發後執行程式碼的整合），相比較而言，「持續整合」能給我們帶來的好處有哪些？

易於定位錯誤：每一次的程式碼整合都需要執行相關的測試工作，持續整合頻繁的整合次數天然的*將複雜的程式碼邏輯切割為了小塊，也就使得每一次測試中遇到的錯誤能夠更加容易的被定位；
易於控制開發流程：更為細緻的工作提交也就意味著更容易判斷當前的工作進度，這對於管理者規劃開發流程而言提供了一個有效的參考，同時也為開發人員省下了彙報工作的時間；
易於 CodeReview：對於大塊工作的切分自然也有助於做 CodeReview；
易於減少不必要的工作：build 以及 test 過程的自動化可以為你節約一大票的時間，從而投入到有價值的工作中去。

持續交付

什麼是持續交付呢？

「持續交付」指的是：一種能夠使得軟體在較短的迴圈中可靠的釋出的軟體工程方法。

與「持續整合」相比，持續交付的側重點在於交付，其核心物件不在於程式碼，而在於可交付的產物。

「持續整合」僅僅針對於新舊程式碼的整合過程執行了一定的測試，其變動到持續交付後還需要一些額外的流程。

從上面這張圖可以看到，與「持續整合」相比較，持續交付新增了 Test -> Staging -> Production 的流程，也就是為新增的程式碼新增了一個保證：確保新增的程式碼在生產環境中是可用的。

在這一增加的流程中，Test 環節不僅僅包含基本的單元測試，還需要延伸到更為複雜的功能測試以及整合測試等。

在這裡，Staging 指的是 類生產環境 ，其儘可能的對真實的網路拓撲、資料庫資料以及硬體裝置等資源進行模擬，從而為測試人員反饋程式碼在生成環境中的可能表現。

流程中每一個環節的執行結果都會對開發人員進行反饋，每一個出現的錯誤都會導致版本的回滾。

當測試完畢確認無誤之後，將由相關人員對其進行手動部署到生產環境。

持續部署

「持續部署」意味著：通過自動化部署的手段將軟體功能頻繁的進行交付。

與「持續交付」以及「持續整合」相比，「持續部署」強調了通過 automated deployment 的手段，對新的軟體功能進行整合。

通過和「持續交付」的圖對比，區別主要體現在對 Production 的自動化。

從開發人員提交程式碼到編譯、測試、部署的全流程不需要人工的干預，完全通過自動化的方式執行。

這一策略加快了程式碼提交到功能上線的速度，保證新的功能能夠第一時間部署到生產環境並被使用。

從前面這些介紹可以看到，CI/CD 是由很多操作組成，比如抓取程式碼、執行測試、登入遠端伺服器，釋出到第三方服務等等。GitHub 把這些操作就稱為 actions。

很多操作在不同專案裡面是類似的，完全可以共享。GitHub 注意到了這一點，想出了一個很妙的點子，允許開發者把每個操作寫成獨立的指令碼檔案，存放到程式碼倉庫，使得其他開發者可以引用。

如果你需要某個 action，不必自己寫複雜的指令碼，直接引用他人寫好的 action 即可，整個持續整合過程，就變成了一個 actions 的組合。這就是 GitHub Actions 最特別的地方。

GitHub 做了一個官方市場，可以搜尋到他人提交的 actions。

連結：https://github.com/marketplace?type=actions

在很長一段時間裡， GitHub 我都是當做程式碼倉庫或者版本管理工具來用，有時候還用作檔案管理工具（速度屬實有點慢，檔案管理工具更多的是使用國內的 Gitee）。

有了 GitHub Action 以後， GitHub 除了上面這些功能以外，能做的事情就更多了，比如我在 master 分支上提交了一段程式碼， GitHub Action 可以自動的幫我部署到我自己的伺服器上去，或者它還可以幫我把程式碼打成映象，將映象自動提交到映象倉庫裡。

雖然這些事情自己手動也能做，但是，能讓機器自己做的事情就讓自己自己做嘛，畢竟懶惰是程式設計師的第一生產力。

GitHub Action 基本概念

GitHub Actions 有一些自己的術語。

workflow （工作流程）：持續整合一次執行的過程，就是一個 workflow。
job （任務）：一個 workflow 由一個或多個 jobs 構成，含義是一次持續整合的執行，可以完成多個任務。
step（步驟）：每個 job 由多個 step 構成，一步步完成。
action （動作）：每個 step 可以依次執行一個或多個命令（action）。

React 專案釋出至 GitHub Page

React 是由 FaceBook 開源的一個前端框架，有相關經驗的同學應該都清楚， React 專案是需要打包編譯的，我這次就用 React 嘗試下使用 GitHub Action 編譯、打包以及部署。

原始碼倉庫：https://github.com/meteor1993/github-actions-demo/settings

GitHub Page：https://meteor1993.github.io/github-actions-demo/

第一件事情是我們需要先建立一個 GitHub 金鑰，因為我們需要將示例部署至 Github Page ，需要寫許可權，建立完成後將這個祕鑰儲存在當前倉庫的 Settings/Secrets 裡面。

建立祕鑰可以參考官方文件：https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line 。

點選自己頭像，選擇 Settings ：

在左邊欄選擇 Developer settings ：

然後在左邊欄選擇 Personal access tokens 點選頭上的 Generate new token 建立一個新的 Token ：

注意： 建立完成後需要儲存好這個 Token ，它只會出現這一次。

接下來，建立一個專案，我這裡建立的名字叫做 github-actions-demo ，然後點選專案中的 Settings ，在 Secrets 的欄目中將剛才建立的 Token 填寫進去：

這裡的名稱隨便填寫，但是要記住，後面我們會用到。

接下來是建立一個標準的 React 應用：

npx create-react-app github-actions-demo

等待進度條走完，然後開啟專案中的 package.json 檔案，新增一個 homepage 欄位，如下：

"homepage": "https://[username].github.io/github-actions-demo",

將 [username] 替換成你自己的 GitHub 使用者名稱，

我這邊完整的 package.json 檔案內容如下，供參考：

{
  "name": "github-actions-demo",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.5.0",
    "@testing-library/user-event": "^7.2.1",
    "react": "^16.13.1",
    "react-dom": "^16.13.1",
    "react-scripts": "3.4.1"
  },
  "homepage": "https://meteor1993.github.io/github-actions-demo",
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

接下來是在這個專案中，在 .github/workflows 的目錄中生成一個 workflow 檔案，名字可以隨便取，這個我這裡的名稱是 ci.yml 。

下面是 ci.yml 中的內容：

name: GitHub Actions Build and Deploy Demo
on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@master # If you're using actions/checkout@v2 you must set persist-credentials to false in most cases for the deployment to work correctly.
      with:
        persist-credentials: false
    - name: Install and Build
      run: |
        npm install
        npm run-script build
    - name: Deploy
      uses: JamesIves/github-pages-deploy-action@releases/v3
      with: 
        ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
        BRANCH: gh-pages
        FOLDER: build
        BUILD_SCRIPT: npm install && npm run build

這裡使用了一個別人已經寫好的 Action ： JamesIves/github-pages-deploy-action ， Github Action 市場的地址為：https://github.com/marketplace/actions/deploy-to-github-pages 。

大致講下上面這個配置檔案做了什麼：

workflow 命名
說明了整個流程在 master 分支發生 push 的時候觸發
然後獲取原始碼，使用的 action 是 actions/checkout
然後是構建和部署，使用的 action 是 JamesIves/github-pages-deploy-action
然後是配置環境變數，這裡的 ACCESS_TOKEN 就是我們剛才申請的 Token ，因為我的命名是 ACCESS_TOKEN ，所以這裡這麼寫，如果有其他命名請自行更換， BRANCH 是配置部署的分支，我這裡是部署到了 gh-pages 分支。

workflow 檔案的配置欄位非常多，詳情可以參考官方文件：https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions ，悄悄說一句，有中文版的哦~

接下來最後一步就是將這個專案提交到 Github 的 master 分支，然後我們在 Github 上點選 Action ，就可以看到當前的構建了：