使用GitHub Actions實現自動化部署

作者：前端南玖 2022-11-15 17:07:40

開發前端

大家在工作中想必都是通過自動化部署來進行前端項目的部署的，也就是我們在開發完某個需求時，我們只需要將代碼推送到某個分支，然后就能自動完成部署，我們一般不用關心項目是如何build以及如何deploy的，這就極大得提高了我們的開發效率。

前言

在沒有自動化部署的情況下，前端項目的部署流程一般是這樣的：(手動部署)

開發完成后本地進行build
將build后的文件交給運維(前端人員有權限的可省略)
將打包文件上傳到服務器的指定目錄

前端項目每次上線都得走一遍這個流程，對于程序員來講這怎么能忍，寧愿將時間浪費在B乎上也不可能浪費在這些毫無技術的工作流程上，并且人工操作，難免會出錯。

所以今天給大家分享一下如何實現自動化部署自己的前端項目。

自動化部署腳本

先來分享一種簡單的自動化部署方案 - 自動化部署腳本

我們每次部署項目時，會有幾個步驟是固定的，既然它是固定的，那么我們就可以通過寫腳本來幫助我們完成，這樣不僅能夠提高我們的開發效率，還能避免人為操作時可能出現的紕漏。

新建倉庫

我們可以在GitHub上新建一個項目并嘗試把它部署到GitHub Pages上。

新建項目

這里我們新建一個Vue3 + TS 項目

添加腳本

我們直接在項目根目錄下新建一個腳本文件deploy.sh

#!/usr/bin/env sh

set -x  # 這里是為了看錯誤日志

# 打包項目
npm run build

# 進入打包后的文件夾
cd dist

git init
git add -A
git commit -m 'auto deploy'

# 將打包后的文件推送到指定分支

git push -f https://github.com/bettersong/nanjiu.git main:static-pages

執行腳本

現在我們可以執行sh deploy.sh，然后就會執行我們腳本文件中的內容，先是打包，然后將打包產物推送到遠程指定分支(static-pages)。我們可以到github倉庫中查看打包產物。

部署完我們怎么訪問這個頁面呢?

在倉庫的Setting -> Pages中可以查看到該頁面的訪問地址

最后我們訪問這個地址https://bettersong.github.io/nanjiu/就能看到我們部署的頁面了。

這種方案最后再與GitHooks結合，可以在某個分支提交時自動完成打包部署，這里就不再介紹了。下面我們再來看另一種更加優雅的方案。

CICD

CICD翻譯過來就是持續構建、持續交付。

CI 持續集成(Continuous Integration)

持續集成：頻繁的將代碼合并到主分支中，強調通過集成測試反饋給開發一個結果，不管失敗還是成功。

持續集成分成三個階段：

持續集成準備階段：根據軟件開發的需要，準備CI的一些前置工作

集成CI工具的代碼倉庫(Gitlab、Github、Jenkins等)
單元測試或者集成測試的腳本
觸發CI的配置文件，實現各種功能的Jobs

持續集成進行階段

推送代碼出發CI系統
通過CI系統監聽代碼的測試、構建，反饋集成結果
通過版本管理系統實現版本的管理

接續集成完成階段：反饋集成結果

CD 持續交付(Continuous Delivery)

持續交付：主要面向測試人員和產品，可以保證一鍵部署，常常要交付的內容包括

源代碼：缺點，代碼依賴的環境不容易控制
打包的二進制文件或者系統包：存在兼容性問題和環境差異出現的部署失敗
虛擬機鏡像交付：系統隔離最好，但占用系統資源嚴重
Docker交付：容器交付，成本最低，兼容性最好
持續部署：此時要提供一個穩定的版本，包括所需的環境和依賴，主要面向用戶提供服務，發生錯誤要能快速回滾。

CICD是目前大多數互聯網公司選擇的一種部署方案，因為它能夠靈活配置項目部署過程中的各個階段。下面再來介紹下如何使用GitHub的CICD來部署前端項目。

GitHub Action

GitHub Actions 是一個持續集成 (Continuous integration)和持續交付 (Continuous delivery)的平臺，它可以做到自動化構建、測試、部署。你可以創建工作流，構建和測試每一個 pull request 或者部署合并后的代碼到生產環境。

Workflows(工作流)

工作流是一個可配置的自動化的程序。創建一個工作流，你需要定義一個 YAML 文件，當你的倉庫觸發某個事件的時候，工作流就會運行，當然也可以手動觸發，或者定義一個時間表。一個倉庫可以創建多個工作流，每一個工作流都可以執行不同的步驟。

Events(事件)

事件是指倉庫觸發運行工作流的具體的行為，比如創建一個 pull request、新建一個 issue、或者推送一個 commit。你也可以使用時間表觸發一個工作流，或者通過請求一個 REST API，再或者手動觸發。

Jobs(任務)

任務是在同一個運行器上執行的一組步驟。一個步驟要么是一個shell 腳本要么是一個動作。步驟會順序執行，并彼此獨立。因為每一個步驟都在同一個運行器上被執行，所以你可以從一個步驟傳遞數據到另一個步驟。

你可以配置一個任務依賴其他任務，默認情況下，任務沒有依賴，并行執行。當一個任務需要另外一個任務的時候，它會等到依賴的任務完成再執行。

Actions(動作)

動作是 GitHub Actions 平臺的一個自定義的應用，它會執行一個復雜但是需要頻繁重復的作業。使用動作可以減少重復代碼。比如一個 action 可以實現從 GitHub 拉取你的 git 倉庫，為你的構建環境創建合適的工具鏈等。你可以寫自己的動作，或者在 GitHub 市場找已經實現好的動作。

Runners(運行器)

一個運行器是一個可以運行工作流的服務。每一個運行器一次只運行一個單獨的任務。GitHub 提供 Ubuntu Linux，Microsoft Windows 和 macOS 運行器，每一個工作流都運行在一個獨立新建的虛擬機中。如果你需要一個不同的操作系統，你可以自定義運行器。

了解完上面這些有關GitHub Actions的概念，我們開始搭建一條自己的工作流用于項目的部署。

搭建工作流

.github/workflows

我們在之前建好的倉庫中點擊New workflow來新建一條工作流。

然后會到選擇工作流的頁面

這里你可以選擇一條別人建好的工作流，也可以選擇新建自己的工作流。

我們還是選擇新建自己的工作流，然后會在我們項目的根目錄下新建一個目錄.github/workflows，這里會新建一個yml文件，我們這里就叫ci.yml好了

yml

在這個文件中，我們要做的事情還是打包以及部署

name: Build and Deploy
on: # 監聽 main 分支上的 push 事件
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest # 構建環境使用 ubuntu
    steps:
      - name: Checkout  # 將代碼拉到虛擬機
        uses: actions/checkout@v2.3.1  
        with:
          persist-credentials: false

      - name: Install and Build # 下載依賴 打包項目
        run: |
          npm install
          npm run build

      - name: Deploy ?? # 部署
        uses: JamesIves/github-pages-deploy-action@v4.3.3
        with:
          branch: static-pages # 部署后提交到的分支
          folder: dist # 這里填打包好的目錄名稱