![](https://img.laitimes.com/img/_0nNw4CM6IyYiwiM6ICdiwiI0gTMx81dsQWZ4lmZf1GLlpXazVmcvwFciV2dsQXYtJ3bm9CX9s2RkBnVHFmb1clWvB3MaVnRtp1XlBXe0xCMy81dvRWYoNHLwEzX5xCMx8FesU2cfdGLwMzX0xiRGZkRGZ0Xy9GbvNGLpZTY1EmMZVDUSFTU4VFRR9Fd4VGdsYTMfVmepNHLrJXYtJXZ0F2dvwVZnFWbp1zczV2YvJHctM3cv1Ce-cmbw5iNzUjMyYmZ3AjN1QmYhlDNzYzXxATNzIDM1EzLcBTMyIDMy8CXn9Gbi9CXzV2Zh1WavwVbvNmLvR3YxUjLyM3Lc9CX6MHc0RHaiojIsJye.png)
零門檻!一文揭開前端自動化部署的神秘面紗。如果你有用過釋出平台,但是隻停留在使用階段,那就對了!本文從宏觀層面講解前端項目釋出的必經階段。筆者跟大家一起走進前端的基建工作,入門 Devops 領域,看看前端釋出平台應該怎麼做!
就前端而言,筆者認為 Devops領域 還是離我們比較遠的。一方面因為其中存在很多運維的工作,另一方面是參與前端的基建工作的機會少,不是所有前端都有機會參與。筆者也隻是有幸找到機會,參與過前端釋出平台的開發建設工作,算是入門了CI/CD的領域吧~也就是這樣的機會,筆者有機會實戰中使用 、資料庫
node server(koa)
、
mongoDb
這些比較陌生又好玩的技術、工具。
jenkins
先說明一下,因為筆者在公司内接觸到的自動化部署工具是
jenkins
,是以文中主要以其進行展開。業界上有很多自動化部署的實作方案,不一定非得用
jenkins
,像
gitlab-ci
(筆者了解得不多...哭腔)等也是可以實作的,是以大家可以更聚焦在整體流程、實作方案上,不要過度關注技術棧、工具這種,因為百變不離其中。
接下來,筆者打算把實戰經驗通過文章的方式進行記錄和總結。通過寫一個系列,分享從前端的角度全棧開發一個前端釋出平台,跟大家一起打開CI/CD的黑盒,走進前端基建的領域。當然,筆者在運維端的實力也是紙糊的,是以涉及運維方面的點主要針對實作階段,原理層面還望大🔥指點指點!
系列大綱:
- 總覽前端自動化部署流程,如何實作前端釋出平台?
- 前端釋出平台
實戰!node server
- 前端釋出平台
實戰!如何實作前端自動化部署?jenkins
- 前端釋出平台全棧實戰(前後端開發完整篇)!開發一個前端釋出平台
本文是第一篇,将圍繞 前端自動化部署流程 進行展開,核心講解整個前端釋出的所有階段,從宏觀掌握前端釋出核心流程,為後續釋出平台實戰奠定基礎(要做一個産品,首先要知道整個産品要解決什麼問題,滿足什麼需求)。話不多說,趕緊進入主題!
一、為什麼需要自動化部署?
回想起之前的經曆(慘痛的釋出場景),筆者甚至經曆過最原始的前端發版的方式...
- 最開始。毫不誇張的說,就是本地打包、再壓個zip包、通過工具手動上傳、找到leader幫忙解壓到對應的伺服器上...每一個環節都是人工操作,發個版非常的繁瑣,直到leader被更版沖走大量時間開始優化流程...
- 直到後來。發版流程有所縮減,但還是純純人工操作。開發者在下遊分支
完 master 後找到leader,leader進行rebase
、建構項目、同步檔案伺服器、重新整理CDN緩存...依然是純手工活~merge master
以上均是真實場景,每次發版都特别麻煩,特别是發上線還有問題要立馬修複再發那種。還好筆者臉皮厚,可以瘋狂找大佬發版(也就是平時買多幾杯奶茶)~要是是個稍微有點社恐的開發同學,這場景還真是難熬。
這裡筆者畫了個圖大家感受下,可以看到圈黑色虛線部分是純人工介入,整個前端部署流程非常耗費人力資源,而這一塊,恰恰就是本文要講的重點,将其從人工變成自動化。
可能有些同學到現在依然會面臨着純人工發版的場景。畢竟基礎建設這玩意不如業務值錢,很多團隊其實在業務優先的情況,也就隻能這樣了。是以,我們可以嘗試性的去搞基建,一方面自己可以進階,另一方面也可以為團隊提效作出貢獻。接下來,跟着筆者一起看看搞一個前端釋出平台實作自動化部署要從何搞起?
二、如何着手釋出平台?
既然要實作一個前端釋出平台,首先要知道整個前端項目的釋出鍊路,也就是我們先得有個大概的産品形态。隻有有了模型,才能把實物制作出來,不是嗎~在此,筆者先提出一個問題:如果是你需要實作一個釋出平台,你會如何下手?
這裡,筆者決定反其道而行,不從正面抛出整個前端釋出的鍊路,而是從使用者端(終端)進行反推,這樣可能更能幫助大家了解。
一個問題:倒推使用者是如何通路到我們撸的web應用的?
啊,首先在位址欄輸入URL,然後浏覽器根據URL做域名解析,DNS解析會從浏覽器緩存、本機host、到DNS節點、到根DNS伺服器找到域名對應的ip位址,然後發起TCP連結,進行三次握手......啊呸,果然還是八股背多了,對不起,我們重新來一遍~
- CDN。使用者通過位址通路到某CDN,擷取
檔案,下載下傳并解析html
檔案内容,并加載相應的其他資源。(CDN中的資源怎麼來?)html
- 檔案伺服器(代指資源所在的源伺服器,下文統稱“檔案伺服器”)。CDN根據使用者通路,回源到我們的檔案伺服器中擷取資源。(我們的檔案伺服器中的資源怎麼來?)
- 檔案傳輸。打包後的dist産物通過一定手段傳輸到檔案伺服器中,如
。(dist産物怎麼來?)rsync
- 項目打包。以SPA項目為例,通過一定的前端打包工具對代碼進行打包,獲得産物。(代碼怎麼來?)
- 代碼倉庫。開發者本地進行業務開發後,将代碼送出到代碼倉庫。如
、git
等gitlab
上面這5點反推的内容,大概就是我們要實作前端自動化部署所要做的工作了。我們所需要實作的前端釋出平台就是要完成以上這些步驟的自動化過程,我們将需要實作的功能點進行梳理:
- 提供前端界面供使用者配置項目、觸發建構等
- 資料庫儲存使用者的項目配置資訊、建構記錄等
- 建構自動化。包括拉代碼,執行打包指令等
- 檔案同步到檔案伺服器(檔案上傳)
- 重新整理 CDN 緩存(一般是
),讓使用者能通路到最新的web應用index.html
筆者自己撸了個圖,大家可以參考一下,加深了解
如上圖所示,這基本就是我們要做成一個前端釋出平台的最基本的功能點了。緊接着,我們對每個環節進行展開講解。
三、實戰前端釋出平台技術準備
1. 前端
-
前端項目準備
前端項目就沒什麼好說的,相信大家撸前端都比筆者要6了~這一部分就簡單帶過了。
筆者就直接用
建立一個 Vue3 項目吧~vite
pnpm create vite cicd-fe
複制代碼
跑一下項目,搞定~
- 前端要實作哪些功能:
- 提供項目部署的配置操作。如:
- 代碼倉庫位址
- 需要建構的分支
- 項目打包指令
- 上傳到對應的檔案伺服器路徑
- 生産環境的通路域名映射關系
- 提供建構控制操作。如:
- 開始建構
- 停止建構
- 復原操作
- 顯示建構資訊。如:
- 建構日志輸出(jenkins的控制台輸出)
- 建構進度提示
ok,前端的 項目準備 和 前端需要實作的功能 大概介紹到這裡了。具體的前端實戰詳情可以等筆者該系列的最後一篇文章:"前端釋出平台全棧實戰!開發一個前端釋出平台",筆者将在那篇文章裡面針對這些功能點進行展開講解~
2. 後端
-
後端項目準備
首先定好整個後端的目錄結構。雖然不是專業的後端,但也得照貓畫虎套個架構模式
一下!MVC
| -- cicd-node # 項目名稱
| -- package.json
| -- pnpm-lock.yaml # lock檔案
| -- src # 項目代碼目錄
| -- config # 項目配置
| -- controller # 接口實作層
| -- model # 資料模型層,定義資料的 schema
| -- routes # 路由層
| -- services # 接口、資料嫁接層
複制代碼
這是實戰最基本的後端目錄結構定義了,當然後續還會新增一些目錄(比如 jenkins 、gitlab 、 中間件 的),這些筆者會在用到的時候再詳細說,本文隻需要搞個雛形,能跑通項目就行!詳細的後端實戰可以關注筆者的專欄系列第二篇!
那麼,整個後端的每個分層的關系如下圖所示:
簡單來說就是: 使用者發起請求 -> route層 -> controller層 -> service層 -> db
-
跑通後端項目
這裡我們隻需要跑通流程即可,詳細的後端實戰會放在專欄的第二篇文章中進行展開(包括資料庫那那部分也是)。如何算是跑通?在
搞一個請求,能正常處理、傳回就算準備完成!postman
- 先搞個
koa
,把程式運作起來。
cv大神出手,去官方文檔拷一份代碼。
const Koa = require('koa');
const app = new Koa();
app.use(async ctx => {
ctx.body = 'Hello World';
});
app.listen(3000);
複制代碼
再配置一下
package.json
,啟動友善一點。
"scripts": {
"dev": "node ./src/index.js" // 執行入口檔案
}
複制代碼
直接
pnpm dev
,打開 localhost:3000 看看效果。
-
實作路由層。
這裡使用
,先koa-router
install
一哈。詳細了解這個庫可以直接看看它的github 。
接着上面的 Koa 例子,根據 router 的文檔說明進行一定的改造,搞個
、get
的上去測試一下post
const Koa = require('koa')
const Router = require('@koa/router')
const router = new Router()
const app = new Koa();
// get 請求
router.get('/test', (ctx, next) => {
ctx.body = {
code: 0,
data: { name: '井柏然-get' }
}
})
// post 請求
router.post('/test', (ctx, next) => {
ctx.body = {
code: 0,
data: { name: '井柏然-post' }
}
})
app
.use(router.routes())
.use(router.allowedMethods())
app.listen(3000);
複制代碼
啟動服務後,通過 postman 看看效果,首先是
get
請求:
然後是
post
請求:
可以看到都請求成功了,那後端項目準備這塊就差不多完了。當然,實戰中并不會把所有路由都如案例中一樣堆在入口檔案中,實戰會通過一個入口
initRoute
方法包裝,在
index
入口中執行這個
initRoute
方法。并且還要搞個 中間件 去統一包裝傳回資料的外殼,如錯誤處理時傳回什麼樣的 code ,未登陸時傳回怎麼樣的 code 。詳細的大家關注筆者第二篇文章吧!我們接着往下看看後端需要實作什麼功能
- 後端要實作哪些功能:
- 實作跟前端互動。
- 處理前端發起的配置儲存、建構、復原等動作
- 傳回前端需要的資料
- 實作跟
互動。gitlab
- 擷取 gitlab 倉庫資訊、分支資訊等
- 擷取 gitlab 的 commit 記錄等
- 實作跟
互動。jenkins
- 發起建構
- 停止建構
- 擷取建構時狀态、建構日志等
- 實作跟資料庫互動。反正就是各種 crud 操作~
3. jenkins
jenkins 這塊可能是 前端er們 最陌生的東西了,畢竟誰有空沒事回去搞這玩意呢?是以在開始講 jenkins 相關的東西時,有必要去介紹一下 jenkins 是個啥。為此!筆者也是詢問了一些運維大佬,看看怎麼講 jenkins 比較好讓大家了解。總結了幾點:
- 是一個流水線工廠,內建了大量主流打包編譯插件。
- 原生提供UI界面互動,通過界面完成項目建構的配置,讓使用者在一個地方實作
流程。CI/CD
- 從拉取代碼、代碼分析、編譯、歸檔到部署全自動化實作。
- 支援多種腳本式建構(如腳本式
),提供了極高的自由度。pipeline
好吧,說了這麼多可能也很難講明白,畢竟沒接觸過很難有那種概念。沒關系,往簡單了說,我們隻要知道用 jenkins 來幫助我們實作
git pull
、
npm ci
、
npm run build
這一串操作的自動化就行了。對 jenkins 的淺層了解并不影響我們實作一個前端自動化部署的釋出平台。
具體的 jenkins 初始化、0-1搭建筆者就不再展開了,已經有很多大佬的手把手教學的搭建案例了,随便一搜都能找到好多精品文章分享。直接進入 job 的了解吧
- 了解
freestyle job
其實就是一把配置就完事的~我們可以把上述的:拉代碼、裝包、建構 等一系列步驟配置到
freestyle job
中,然後我們再去運作這個 job ,那 jenkins 就會按照配置,幫助我們自動地執行這些我們配置好的前端部署操作,以此來完成前端的自動化部署。
這裡,我們大緻了解下
freestyle job
的配置都有哪些:
- 基礎配置:
- 項目名稱、建構時使用的jenkins節點(打包機)...
- 源碼管理:
- 也就是拉代碼時對應的代碼倉庫、分支
- 建構觸發器(鈎子):
- 配置建構的處罰鈎子,比如:可以監聽到gitlab代碼送出時進行建構
- 建構環境:
- 建構:
- 我們可以在這裡添加我們需要執行的 shell 腳本,如
、npm ci
這些。如果需要在這個階段處理一些業務邏輯,我們還可以通過npm run build
通知到我們的curl
形成一個node server
跟jenkins
的互動。node server
- 建構後操作:
- 我們可以在這個節點,通過郵件、飛書、企微啥的通知一些資訊。
整個配置下來,直接儲存就大功告成了!到部署的時候,直接建構這個 job 就行了,整個 job 的執行都是按順序執行的,并且一個 job 被多次調用的時候會排隊執行。當執行完 job 時,我們的項目就打包完成了,産物會放在 jenkins 的 工作空間(
Workspace
)中。如圖所示:
講到這裡,整個前端自動化部署的工作也就接近尾聲了,最後就是要把這個 dist 包,傳到我們的檔案伺服器中,并且重新整理對應的 CDN 緩存。當然,最後的這一個步驟大機率是不需要我們直接介入的,因為這一塊一般都是由公司的運維同僚去負責。不過,重新整理 CDN 緩存這個動作也是可以在開發側去觸發的。但是有一個問題,檔案同步一般是同步好幾個機器,重新整理 CDN 緩存的時間節點一定是在同步完全部的檔案伺服器觸發才是最穩妥的,那這個鈎子一般還是得由運維那側提供,是以由他們去做重新整理的動作也是比較合理的。也就是說,從開發側來講,完成一個完整的前端釋出平台大概就如筆者上述介紹的了。
那秉承着“可以不會,不能不學”的初心,筆者也還是要提一嘴!檔案同步這個前文中也有提到過,可以通過
rsync
去幫助我們完成。那最後,我們再了解一下
rsync
~
4. 了解 rsync
當然,用來做檔案上傳、同步的工具不隻有
rsync
,隻是筆者見識短淺了解得不多,隻能把自己知道的拿出來說。不過還是那句,實作方式千千萬萬,但是整個流程卻是八九不離十,是以更聚焦在整個流程中會更好。
首先看看 wiki 對 rsync 的描述:
rsync is a utility for efficiently transferring and synchronizing files between a computer and a storage drive and across networked computers by comparing the modification times and sizes of files
劃重點:
- 比對檔案修改時間和大小;
- 機器之間傳輸、同步檔案;
關于
rsync
詳細的用法筆者也不在這裡詳細展開了,畢竟我也是看其他大牛的部落格來學習的,說不定螢幕前的你比筆者還要了解~筆者在這裡放 2 個老師的連結,感興趣的夥伴可以點進去詳細了解
- rsync 用法教程
- rsync 指令
筆者大概總結一下怎麼在前端自動化部署中使用
rsync
,一句話:敲指令就完事了。使用階段,不需要特别深入了解一想工具、技術便可以用它來解決我們的需求點。
結合到 jenkins 中使用,我們可以大概這樣,在建構中添加一個建構步驟執行
shell
指令(注意是要在項目建構完成後添加同步指令):
也就是說,當我們執行完前面那一串 jenkins 自動化流程後到
npm run build
結束(這個階段我們已經可以在工作空間中得到最新的dist包),我們就可以通過
rsync
來幫助我們完成前端産物的同步工作了。隻要把最新的建構産物同步到我們的檔案伺服器後,整個前端項目的部署流程就算是走完了,剩下最後一點就是重新整理 CDN 的緩存了。
四、總結
到最後啦,相信看到這裡,應該能對整個 前端自動化部署流程 有大概的認識了。如果已經平常使用過釋出平台、自動化部署的童鞋肯能對文中提到的一些階段有更深的了解。
筆者撸了個詳細的圖,全面看整個前端自動化部署的過程:
- 通過使用者配置資訊生成
(可配置是否監聽 git commit 觸發建構全自動化)job
- jenkins 建構,執行
(項目打包)job
- rsync 産物檔案傳輸至 檔案伺服器
- 重新整理 CDN 緩存(調open api實作),核心資源(
)回源index.html
-
實戰釋出平台後端開發;Koa + mongoDb
-
實戰詳解,jenkins
、freestyle job
相關;pipeline job
- 前端 + 後端 + jenkins全棧開發前端釋出平台的實戰總結篇