使用GitHub Actions實現自動化部署

前言

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

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

  • 開發完成後本地進行build
  • 將build後的文件交給運維（前端人員有許可權的可省略）
  • 將打包文件上傳到伺服器的指定目錄

前端項目每次上線都得走一遍這個流程，對於程式設計師來講這怎麼能忍，寧願將時間浪費在B乎上也不可能浪費在這些毫無技術的工作流程上，並且人工操作，難免會出錯。

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

如果這篇文章有幫助到你，❤️關注+點贊❤️鼓勵一下作者，文章公眾號首發，關注 前端南玖 第一時間獲取最新文章～

自動化部署腳本

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

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

新建倉庫

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

github-1.png

新建項目

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

github-2.png

添加腳本

我們直接在項目根目錄下新建一個腳本文件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 //github.com/bettersong/nanjiu.git main:static-pages

執行腳本

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

github-3.png

部署完我們怎麼訪問這個頁面呢？

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

github-4.png

最後我們訪問這個地址//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 或者部署合併後的程式碼到生產環境。

github-5.png

Workflows(工作流)

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

github-工作流.png

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-6.png

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

github-7.png

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

我們還是選擇新建自己的工作流，然後會在我們項目的根目錄下新建一個目錄.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/[email protected]  
        with:
          persist-credentials: false

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

      - name: Deploy 🚀 # 部署
        uses: JamesIves/[email protected]
        with:
          branch: static-pages # 部署後提交到的分支
          folder: dist # 這裡填打包好的目錄名稱

我們把這個文件提交上去，它就會在提交程式碼後自己完成打包及部署的工作。

自動化部署

github-8.png

github-9.png

在程式碼提交上去後，它會按照我們工作流的步驟進行打包及部署

github-10.png

並且上面可以查看整個工作流的日誌，方便排查問題

github-11.png

部署完訪問地址還是一樣//bettersong.github.io/nanjiu

到這裡我們基於GitHub Actions實現的自動化部署流程就完成了，現在我們在本地修改完程式碼後就只需要將程式碼推送到遠程，就能夠實現自動打包部署了。

最後

喜歡的同學歡迎點個贊呀～

原文首發地址點這裡，歡迎大家關注公眾號 「前端南玖」，如果你想進前端交流群一起學習，請點這裡

我是南玖，我們下期見！！！

Tags:

VirMach 便宜 VPS

QNews

QNews