前言

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

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

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

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

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

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

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

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

新建倉(cāng)庫(kù)

我們可以在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倉(cāng)庫(kù)中查看打包產(chǎn)物。

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

在倉(cāng)庫(kù)的Setting -> Pages中可以查看到該頁(yè)面的訪問(wèn)地址

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

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

CICD

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

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

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

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

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

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

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

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

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

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

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

• 源代碼：缺點(diǎn)，代碼依賴的環(huán)境不容易控制
• 打包的二進(jìn)制文件或者系統(tǒng)包：存在兼容性問(wèn)題和環(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)目部署過(guò)程中的各個(gè)階段。下面再來(lái)介紹下如何使用GitHub的CICD來(lái)部署前端項(xiàng)目。

GitHub Action

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

Workflows(工作流)

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

Events(事件)

事件是指?jìng)}庫(kù)觸發(fā)運(yùn)行工作流的具體的行為，比如創(chuàng)建一個(gè) pull request、新建一個(gè) issue、或者推送一個(gè) commit。你也可以使用時(shí)間表觸發(fā)一個(gè)工作流，或者通過(guò)請(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ù)沒(méi)有依賴，并行執(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 倉(cāng)庫(kù)，為你的構(gòu)建環(huán)境創(chuàng)建合適的工具鏈等。你可以寫(xiě)自己的動(dòng)作 ，或者在 GitHub 市場(chǎng)找已經(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的概念，我們開(kāi)始搭建一條自己的工作流用于項(xiàng)目的部署。

搭建工作流

.github/workflows

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

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

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

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

yml

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

name: Build and Deploy
on: # 監(jiān)聽(tīng) 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è)工作流的日志，方便排查問(wèn)題

部署完訪問(wèn)地址還是一樣https://bettersong.github.io/nanjiu

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