前言

大家在工作中想必都是通過自動(dòng)化部署來進(jìn)行前端項(xiàng)目的部署的，也就是我們?cè)陂_發(fā)完某個(gè)需求時(shí)，我們只需要將代碼推送到某個(gè)分支，然后就能自動(dòng)完成部署，我們一般不用關(guān)心項(xiàng)目是如何build以及如何deploy的，這就極大得提高了我們的開發(fā)效率。

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

• 開發(fā)完成后本地進(jìn)行build
• 將build后的文件交給運(yùn)維(前端人員有權(quán)限的可省略)
• 將打包文件上傳到服務(wù)器的指定目錄

前端項(xiàng)目每次上線都得走一遍這個(gè)流程，對(duì)于程序員來講這怎么能忍，寧愿將時(shí)間浪費(fèi)在B乎上也不可能浪費(fèi)在這些毫無技術(shù)的工作流程上，并且人工操作，難免會(huì)出錯(cuò)。

所以今天給大家分享一下如何實(shí)現(xiàn)自動(dòng)化部署自己的前端項(xiàng)目。

自動(dòng)化部署腳本

先來分享一種簡單的自動(dòng)化部署方案 - 自動(dòng)化部署腳本

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

新建倉庫

我們可以在GitHub上新建一個(gè)項(xiàng)目并嘗試把它部署到GitHub Pages上。

新建項(xiàng)目

這里我們新建一個(gè)Vue3 + TS 項(xiàng)目

添加腳本

我們直接在項(xiàng)目根目錄下新建一個(gè)腳本文件deploy.sh

#!/usr/bin/env sh

set -x  # 這里是為了看錯(cuò)誤日志

# 打包項(xiàng)目
npm run build

# 進(jìn)入打包后的文件夾
cd dist

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

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

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

執(zhí)行腳本

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

部署完我們?cè)趺丛L問這個(gè)頁面呢?

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

最后我們?cè)L問這個(gè)地址https://bettersong.github.io/nanjiu/就能看到我們部署的頁面了。

這種方案最后再與GitHooks結(jié)合，可以在某個(gè)分支提交時(shí)自動(dòng)完成打包部署，這里就不再介紹了。下面我們?cè)賮砜戳硪环N更加優(yōu)雅的方案。

CICD

CICD翻譯過來就是持續(xù)構(gòu)建、持續(xù)交付。

CI 持續(xù)集成(Continuous Integration)

持續(xù)集成：頻繁的將代碼合并到主分支中，強(qiáng)調(diào)通過集成測試反饋給開發(fā)一個(gè)結(jié)果，不管失敗還是成功。

持續(xù)集成分成三個(gè)階段：

1. 持續(xù)集成準(zhǔn)備階段：根據(jù)軟件開發(fā)的需要，準(zhǔn)備CI的一些前置工作

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

2. 持續(xù)集成進(jìn)行階段

• 推送代碼出發(fā)CI系統(tǒng)
• 通過CI系統(tǒng)監(jiān)聽代碼的測試、構(gòu)建，反饋集成結(jié)果
• 通過版本管理系統(tǒng)實(shí)現(xiàn)版本的管理

3. 接續(xù)集成完成階段：反饋集成結(jié)果

CD 持續(xù)交付(Continuous Delivery)

持續(xù)交付：主要面向測試人員和產(chǎn)品，可以保證一鍵部署，常常要交付的內(nèi)容包括

• 源代碼：缺點(diǎn)，代碼依賴的環(huán)境不容易控制
• 打包的二進(jìn)制文件或者系統(tǒng)包：存在兼容性問題和環(huán)境差異出現(xiàn)的部署失敗
• 虛擬機(jī)鏡像交付：系統(tǒng)隔離最好，但占用系統(tǒng)資源嚴(yán)重
• Docker交付：容器交付，成本最低，兼容性最好
• 持續(xù)部署：此時(shí)要提供一個(gè)穩(wěn)定的版本，包括所需的環(huán)境和依賴，主要面向用戶提供服務(wù)，發(fā)生錯(cuò)誤要能快速回滾。

CICD是目前大多數(shù)互聯(lián)網(wǎng)公司選擇的一種部署方案，因?yàn)樗軌蜢`活配置項(xiàng)目部署過程中的各個(gè)階段。下面再來介紹下如何使用GitHub的CICD來部署前端項(xiàng)目。

GitHub Action

GitHub Actions 是一個(gè)持續(xù)集成 (Continuous integration)和持續(xù)交付 (Continuous delivery)的平臺(tái)，它可以做到自動(dòng)化構(gòu)建、測試、部署。你可以創(chuàng)建工作流，構(gòu)建和測試每一個(gè) pull request 或者部署合并后的代碼到生產(chǎn)環(huán)境。

Workflows(工作流)

工作流是一個(gè)可配置的自動(dòng)化的程序。創(chuàng)建一個(gè)工作流，你需要定義一個(gè) YAML 文件，當(dāng)你的倉庫觸發(fā)某個(gè)事件的時(shí)候，工作流就會(huì)運(yùn)行，當(dāng)然也可以手動(dòng)觸發(fā)，或者定義一個(gè)時(shí)間表。一個(gè)倉庫可以創(chuàng)建多個(gè)工作流，每一個(gè)工作流都可以執(zhí)行不同的步驟。

Events(事件)

事件是指倉庫觸發(fā)運(yùn)行工作流的具體的行為，比如創(chuàng)建一個(gè) pull request、新建一個(gè) issue、或者推送一個(gè) commit。你也可以使用時(shí)間表觸發(fā)一個(gè)工作流，或者通過請(qǐng)求一個(gè) REST API，再或者手動(dòng)觸發(fā)。

Jobs(任務(wù))

任務(wù)是在同一個(gè)運(yùn)行器上執(zhí)行的一組步驟。一個(gè)步驟要么是一個(gè)shell 腳本要么是一個(gè)動(dòng)作。步驟會(huì)順序執(zhí)行，并彼此獨(dú)立。因?yàn)槊恳粋€(gè)步驟都在同一個(gè)運(yùn)行器上被執(zhí)行，所以你可以從一個(gè)步驟傳遞數(shù)據(jù)到另一個(gè)步驟 。

你可以配置一個(gè)任務(wù)依賴其他任務(wù)，默認(rèn)情況下，任務(wù)沒有依賴，并行執(zhí)行。當(dāng)一個(gè)任務(wù)需要另外一個(gè)任務(wù)的時(shí)候，它會(huì)等到依賴的任務(wù)完成再執(zhí)行。

Actions(動(dòng)作)

動(dòng)作是 GitHub Actions 平臺(tái)的一個(gè)自定義的應(yīng)用，它會(huì)執(zhí)行一個(gè)復(fù)雜但是需要頻繁重復(fù)的作業(yè)。使用動(dòng)作可以減少重復(fù)代碼。比如一個(gè) action 可以實(shí)現(xiàn)從 GitHub 拉取你的 git 倉庫，為你的構(gòu)建環(huán)境創(chuàng)建合適的工具鏈等。你可以寫自己的動(dòng)作 ，或者在 GitHub 市場找已經(jīng)實(shí)現(xiàn)好的動(dòng)作。

Runners(運(yùn)行器)

一個(gè)運(yùn)行器是一個(gè)可以運(yùn)行工作流的服務(wù)。每一個(gè)運(yùn)行器一次只運(yùn)行一個(gè)單獨(dú)的任務(wù)。GitHub 提供 Ubuntu Linux，Microsoft Windows 和 macOS 運(yùn)行器，每一個(gè)工作流都運(yùn)行在一個(gè)獨(dú)立新建的虛擬機(jī)中。如果你需要一個(gè)不同的操作系統(tǒng)，你可以自定義運(yùn)行器。

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

搭建工作流

.github/workflows

我們?cè)谥敖ê玫膫}庫中點(diǎn)擊New workflow來新建一條工作流。

然后會(huì)到選擇工作流的頁面

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

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

yml

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

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

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

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

我們把這個(gè)文件提交上去，它就會(huì)在提交代碼后自己完成打包及部署的工作。

自動(dòng)化部署

在代碼提交上去后，它會(huì)按照我們工作流的步驟進(jìn)行打包及部署

并且上面可以查看整個(gè)工作流的日志，方便排查問題

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

到這里我們基于GitHub Actions實(shí)現(xiàn)的自動(dòng)化部署流程就完成了，現(xiàn)在我們?cè)诒镜匦薷耐甏a后就只需要將代碼推送到遠(yuǎn)程，就能夠?qū)崿F(xiàn)自動(dòng)打包部署了。