1. 首頁 > 生活百科 > >

使用GitHub Actions實現自動化部署

生活百科

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

  • 開發完成后本地進行build
  • 將build后的文件交給運維（前端人員有權限的可省略）
  • 將打包文件上傳到服務器的指定目錄
前端項目每次上線都得走一遍這個流程，對于程序員來講這怎么能忍 ， 寧愿將時間浪費在B乎上也不可能浪費在這些毫無技術的工作流程上，并且人工操作，難免會出錯 。
所以今天給大家分享一下如何實現自動化部署自己的前端項目 。
如果這篇文章有幫助到你 ， ?關注+點贊?鼓勵一下作者，文章公眾號首發，關注 前端南玖 第一時間獲取最新文章～
自動化部署腳本【使用GitHub Actions實現自動化部署】先來分享一種簡單的自動化部署方案 - 自動化部署腳本
我們每次部署項目時，會有幾個步驟是固定的，既然它是固定的，那么我們就可以通過寫腳本來幫助我們完成 ， 這樣不僅能夠提高我們的開發效率，還能避免人為操作時可能出現的紕漏 。
新建倉庫我們可以在GitHub上新建一個項目并嘗試把它部署到GitHub Pages上 。
使用GitHub Actions實現自動化部署

文章插圖
新建項目這里我們新建一個Vue3 + TS 項目
使用GitHub Actions實現自動化部署

文章插圖
添加腳本我們直接在項目根目錄下新建一個腳本文件deploy.sh
#!/usr/bin/env shset -x# 這里是為了看錯誤日志# 打包項目npm run build# 進入打包后的文件夾cd distgit initgit add -Agit commit -m 'auto deploy'# 將打包后的文件推送到指定分支git push -f https://github.com/bettersong/nanjiu.git main:static-pages執行腳本現在我們可以執行sh deploy.sh ， 然后就會執行我們腳本文件中的內容，先是打包，然后將打包產物推送到遠程指定分支（static-pages） 。我們可以到github倉庫中查看打包產物 。
使用GitHub Actions實現自動化部署

文章插圖
部署完我們怎么訪問這個頁面呢？
在倉庫的Setting -> Pages中可以查看到該頁面的訪問地址
使用GitHub Actions實現自動化部署

文章插圖
最后我們訪問這個地址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 ActionGitHub Actions

推薦閱讀