前端工程化—部署

前端工程化—部署

使用腳手架創建初始項目，在本地搭建開發伺服器進行項目開發。編碼完成後，經過構建生成目標環境可用的代碼，到此階段的所有工作都屬於開發環節。下一步的工作需要將代碼部署到指定的環境中，方便進一步的聯調測試工作。

在部署一些個人項目或者小團隊的項目時，可能就是使用一些工具（如FTP上傳工具）將文件上傳到指定的伺服器，然後交給運維人員發佈上線即可。 這種發佈方式簡單快速，適合於個人項目或者小規模團隊。但是對於用戶量龐大的產品和擁有多種開發體系的技術團隊，項目部署必須考慮協作、速度、安全等多方面因素，需要一套完整的流程實現項目部署。

先來看三個場景，從實際場景出發考慮前端部署需要註意哪些因素。

1、開發人員使用FTP工具上傳代碼到伺服器。在測試階段，測試人員提了一個Bug給開發同學，開發人員修複完成後需要打開FTP工具，定位到指定目錄然後上傳代碼。每次的Bug修複都需要重覆這個過程。

2、多人協作的項目中，如果A同學在修複一個Bug後沒有將代碼提交到代碼倉庫，其他開發在舊代碼基礎上進行改動，部署後發現A修複的Bug又出現了。

3、開發同學失誤將代碼部署到其他應用的目錄中，導致其他應用功能故障。

以上三個場景分別對應了部署流程中需要考慮的3個因素：速度、協作和安全。不同結構、不同規模的團隊有著不同的側重點，小團隊註重速度，大團隊註重於協作和安全。

部署工具

針對場景1中的速度問題，我們需要一個自動化的部署工具，工具必須可配置且操作簡單。

• 可配置化：部署的目標伺服器、路徑信息與項目一一對應，可供運維人員部署。
• 操作簡化：部署操作應該實現自動化，開發人員通過命令行或者可視化頁面部署項目。 平臺應該實現高度的自動化，開發人員只需要申請測試環境，然後點擊部署項目即可進行測試。背後的伺服器資源分配、項目構建、項目資源部署都無需開發人員關註。

部署流程

針對場景2中的寫作問題，我們需要一個完善的部署流程。 場景2中存在兩個問題：溝通不及時導致代碼不同步；控制不嚴格導致部署內容錯誤覆蓋。

首先我們需要完善分支管理機制，多人開發的項目使用版本控制系統Git，本地的項目不能直接部署到伺服器上，伺服器部署是從Git倉庫中拉取分支代碼，要想在伺服器上部署必須將代碼推送到Git倉庫中。

開發者可以申請多個日常環境部署自己的項目分支，但是要保證每個項目的預發環境中只能有一個或者兩個分支。發佈必須以隊列的形式進行發佈，而且發佈隊列中只能有一個項目分支，從而保證項目內容不會被錯誤覆蓋，都是最新的代碼。 以Git為例，多人協作的項目中，都是從master分支創建feature進行開發，在日常環境中可以部署自己的feature分支，但是在預發部署時，必須merge master的代碼，否則預發編譯報錯，發佈必須從預發隊列發佈。 

簡單來說，部署隊列就是將所有的部署請求按順序排成一個隊列，必須依次完成發佈，且每次發佈之前對流程進行卡點。必須保證預發功能驗證通過，代碼安全性掃描通過，code review通過，否則不允許項目發佈。

許可權體系

對於場景3中的安全問題，我們需要建立許可權體系。 開發人員只保留請求部署的許可權，項目部署到哪台伺服器、具體路徑以及部署的環境等信息對於開發人員來說是透明的，所以開發人員只需要關註業務即可。項目的部署到目標伺服器和目標地址的過程應該使用代碼或者腳本自動化完成，減少人為因素造成的誤操作。

前端靜態資源部署

在設計部署流程的時候，需要考慮到的是前端領域和其他領域最大的區別是前端資源都是靜態資源，其中最特殊的就是HTML文件。

HTML文件是Web網站的唯一入口，所有其他資源必須由html文件直接或者簡介引用才能被夾在。HTML的特殊性決定了它只能使用協商緩存，其他資源（Js、CSS等）應使用強緩存。這種緩存策略保證用戶每次訪問網站能夠獲取到最新的HTML資源，其他靜態資源的更新能夠直接體現在HTML中，只要HTML及時更新，就保證了全站資源的更新。可以在伺服器中針對不同的靜態資源設置不同的緩存策略。

HTML和其他靜態資源應部署在不同的功能變數名稱下，有兩個好處：

• 如果部署在統一功能變數名稱下，請求靜態資源（Js、CSS）時也會攜帶cookie，浪費資源，將這些靜態資源部署在另一個功能變數名稱下，就解決了這個問題。
• Js、CSS等文件可以部署在CDN中，優化網站性能。

總結

以上所述都是前端工程化部署中需要考慮的一些基本問題，實施過程中還有很多細節需要考慮，例如代碼回滾機制、部署隊列優先順序處理、許可權體系中的黑白名單策略等，但是在設計部署方案時，一定要考慮速度、協作和安全三個因素，然後設計最適合自己團隊的具體方案。

參考資料

• 大公司里怎樣開發和部署前端代碼？

文章首發於我的Github：前端知識體系