前端工程化—部署

前端工程化—部署

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

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

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

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

二、多人協做的項目中，若是A同窗在修復一個Bug後沒有將代碼提交到代碼倉庫，其餘開發在舊代碼基礎上進行改動，部署後發現A修復的Bug又出現了。

三、開發同窗失誤將代碼部署到其餘應用的目錄中，致使其餘應用功能故障。

以上三個場景分別對應了部署流程中須要考慮的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：前端知識體系