你知道什麼是 GitHub Action 麼？

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

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

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

首先仍是先放幾個官方的連接：

GitHub Action ： github.com/features/ac…

GitHub Action 官方市場： github.com/marketplace…

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。

連接：github.com/marketplace…

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

有了 GitHub Action 之後， GitHub 除了上面這些功能之外，能作的事情就更多了，好比我在 master 分支上提交了一段代碼， GitHub Action 能夠自動的幫我部署到我本身的服務器上去，或者它還能夠幫我把代碼打成鏡像，將鏡像自動提交到鏡像倉庫裏。

雖然這些事情本身手動也能作，可是，能讓機器本身作的事情就讓本身本身作嘛，畢竟懶惰是程序員的第一輩子產力。

GitHub Action 基本概念

GitHub Actions 有一些本身的術語。

1. workflow （工做流程）：持續集成一次運行的過程，就是一個 workflow。

2. job （任務）：一個 workflow 由一個或多個 jobs 構成，含義是一次持續集成的運行，能夠完成多個任務。

3. step（步驟）：每一個 job 由多個 step 構成，一步步完成。

4. action （動做）：每一個 step 能夠依次執行一個或多個命令（action）。

React 項目發佈至 GitHub Page

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

源碼倉庫：github.com/meteor1993/…

GitHub Page：meteor1993.github.io/github-acti…

第一件事情是咱們須要先建立一個 GitHub 密鑰，由於咱們須要將示例部署至 Github Page ，須要寫權限，建立完成後將這個祕鑰保存在當前倉庫的 Settings/Secrets 裏面。

建立祕鑰能夠參考官方文檔：help.github.com/en/github/a… 。

點擊本身頭像，選擇 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 市場的地址爲：github.com/marketplace… 。

大體講下上面這個配置文件作了什麼：

1. workflow 命名
2. 說明了整個流程在 master 分支發生 push 的時候觸發
3. 而後獲取源碼，使用的 action 是 actions/checkout
4. 而後是構建和部署，使用的 action 是 JamesIves/github-pages-deploy-action
5. 而後是配置環境變量，這裏的 ACCESS_TOKEN 就是咱們剛纔申請的 Token ，由於個人命名是 ACCESS_TOKEN ，因此這裏這麼寫，若是有其餘命名請自行更換， BRANCH 是配置部署的分支，我這裏是部署到了 gh-pages 分支。

workflow 文件的配置字段很是多，詳情能夠參考官方文檔：help.github.com/en/actions/… ，悄悄說一句，有中文版的哦~

接下來最後一步就是將這個項目提交到 Github 的 master 分支，而後咱們在 Github 上點擊 Action ，就能夠看到當前的構建了：

而後點擊進入 Action 之後，能夠看到當前的實時日誌：

日誌默認保存 30 天。

等到項目部署成功後，訪問咱們以前的連接：meteor1993.github.io/github-acti… ，就能夠看到效果了：

而後每次推送到 mater 分支，Github Action 都會自動運行，將構建產物發佈至 Github Page ，感受這個東西很適合作靜態博客網站有木有，好比 Hexo 啥的。

參考

www.ruanyifeng.com/blog/2019/0…

blog.csdn.net/qq_35368183…

您的掃碼關注，是對小編堅持原創的最大鼓勵：）