【編者按】本文作者為 Parker Selbert，主要介紹高效部署靜態(tài)托管應(yīng)用的7大技巧，助你實(shí)現(xiàn)持續(xù)、安全且高效的交付流程。本文系國(guó)內(nèi) ITOM 管理平臺(tái) OneAPM 編譯呈現(xiàn)。
單頁(yè)應(yīng)用不僅能提供非常豐富的用戶體驗(yàn)，而且為持續(xù)開發(fā)開辟了一個(gè)完全不同于以前的新途徑。將前端應(yīng)用從服務(wù)器分離，從而簡(jiǎn)化團(tuán)隊(duì)職責(zé)的劃分，是非常合理的策略。維護(hù)一個(gè)單獨(dú)的前端代碼庫(kù)，允許團(tuán)隊(duì)通過 API ，快速迭代應(yīng)用特性、改善交互功能。
然而，交付靜態(tài)資源的過程并不都是如此順利的。在開始持續(xù)部署靜態(tài)資源之前，你的團(tuán)隊(duì)必須注意托管和交付中的陷阱。 以下是一些有關(guān)高效部署靜態(tài)托管應(yīng)用的技巧，幫助你實(shí)現(xiàn)持續(xù)、安全，以及最重要的，高效的交付流程。
1. 使用最先進(jìn)的打包和部署工具
如果你的團(tuán)隊(duì)已經(jīng)決定單獨(dú)部署客戶端和服務(wù)器代碼，很有可能的是，服務(wù)器并不是使用Node.js語(yǔ)言編寫的，但這并不能阻止你使用 Node.js 和 NPM 來構(gòu)建和管理應(yīng)用程序！你可以自由使用最先進(jìn)的打包和開發(fā)工具，而不用管服務(wù)器端采用了什么框架。
一旦你的構(gòu)建和測(cè)試過程不受服務(wù)器框架限制，也就釋放了交付過程。一旦前端應(yīng)用通過了集成測(cè)試，CI 服務(wù)器就可以構(gòu)建一個(gè)正式版(參見技巧2)，直接交付并進(jìn)行發(fā)布(參見技巧5)。
2. 縮小，壓縮和源映射(Source Maps)是必不可少的
部署一個(gè)單頁(yè)應(yīng)用遠(yuǎn)不止上傳級(jí)聯(lián)碼到服務(wù)器這么簡(jiǎn)單。你在為生產(chǎn)環(huán)境的 Web 框架部署資源時(shí)，一定會(huì)精打細(xì)算地節(jié)省字節(jié)數(shù)，部署單頁(yè)應(yīng)用也是如此，需要同等的注意力與投入。這意味著單頁(yè)應(yīng)用必須盡可能縮小，壓縮，并包含 源映射(source maps)。
任何主流的 JavaScript 構(gòu)建工具，再加上少量的腳本，都能幫助你交付出最優(yōu)化的應(yīng)用。
3. 優(yōu)化代碼和樣式交付
鑒于最近的趨勢(shì)是將視圖組件與樣式定義放在一起，這一點(diǎn)可能稍有爭(zhēng)議。但是，你需要權(quán)衡樣式和代碼捆綁后的利弊。
通常，瀏覽器可以并行下載 CSS 和 JS 文件，降低第一次加載后的繪制時(shí)間。如果所有的資源都捆綁在一起，是不可能提升性能的。當(dāng)所有的樣式和代碼都捆綁在一個(gè)大文件內(nèi)，客戶只能盯著空白的屏幕，等待資源下載。
雖然多個(gè)文件會(huì)使交付過程稍顯復(fù)雜，但文件縮小后帶來的性能優(yōu)勢(shì)是值得我們這樣做的。
4. 單獨(dú)交付資源包
除非你是個(gè)極端的純粹主義者，每個(gè)打包應(yīng)用都應(yīng)該是由庫(kù)模塊和應(yīng)用代碼組成的。通常，你的應(yīng)用代碼比庫(kù)模塊更改得更為頻繁。當(dāng)你提供巨大的級(jí)聯(lián)包時(shí)，客戶端被迫下載每一次更新，哪怕改動(dòng)很小。應(yīng)用程序包通常推送3MB 的數(shù)據(jù)量，這又需要下載大量的代碼，而僅僅是因?yàn)閹仔袘?yīng)用代碼的更改。
為了避免這個(gè)問題，你應(yīng)該將應(yīng)用程序分成至少兩個(gè)資源包：一個(gè)包含級(jí)聯(lián)庫(kù)代碼，另一個(gè)包含應(yīng)用代碼。未來如果實(shí)現(xiàn) 支持連接并行的HTTP / 2 協(xié)議，單個(gè)文件可以并行發(fā)送，這樣的部署就不再必要了。但是現(xiàn)在，資源包的分割將加快用戶獲得每個(gè)新發(fā)布版本的速度。
5. 善加利用內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）
使用內(nèi)容分發(fā)網(wǎng)絡(luò)發(fā)布靜態(tài)應(yīng)用。只要保留語(yǔ)義緩存，CDN 就允許客戶端繼續(xù)指向相同的 URL。此外，在發(fā)布新代碼時(shí)，即使缺乏資源指紋，也支持執(zhí)行主動(dòng)失效。主動(dòng)失效會(huì)更新每個(gè)邊緣服務(wù)器（也就是向客戶端發(fā)布應(yīng)用的服務(wù)器）上緩存的應(yīng)用版本。
要注意的是，主動(dòng)失效可能延時(shí)，在 Amazon CloudFront 上需要 10分鐘或更多時(shí)間。這一不可預(yù)知的異步行為，是發(fā)布版本時(shí)需要額外留意的。
6. 連續(xù)性面前沒有版本
不要期望用戶會(huì)重新加載瀏覽器。假設(shè)一些用戶會(huì)運(yùn)行舊版本的應(yīng)用，并做好準(zhǔn)備，處理一些已棄用功能的請(qǐng)求。將版本發(fā)布看作是一個(gè)連續(xù)的變化，并決定你的發(fā)布周期。
總會(huì)某一階段，繼續(xù)支持所有舊版本及它們可能包含的各種錯(cuò)誤，是不切實(shí)際的。除非你部署的是一臺(tái)自助服務(wù)機(jī)，更新周期非常不頻繁，你可以放心地假設(shè)用戶會(huì)每周重新加載一次。
7. 逐步推出功能
使用功能標(biāo)記逐步推出新功能。Ember 技術(shù)就是一個(gè)很好的例子，可以將功能和代碼相綁定，但它是默認(rèn)禁用的。代碼在運(yùn)行時(shí)動(dòng)態(tài)產(chǎn)生，但是大多數(shù)人并不使用它。一旦通過測(cè)試人員或一小部分用戶的測(cè)試，你就可以發(fā)布包含這一功能的新版本。
在發(fā)布服務(wù)器端代碼時(shí)，通常也會(huì)使用同樣的方法，但是靜態(tài)托管單頁(yè)應(yīng)用的風(fēng)險(xiǎn)更高。循序漸進(jìn)的方法是至關(guān)重要的，因?yàn)榛貪L代碼的速度取決于 CDN 的失效期。這意味著你若是發(fā)布了一個(gè)錯(cuò)誤版本，它至少在生產(chǎn)環(huán)境中運(yùn)行10分鐘以上，而無法立即撤銷。
應(yīng)用資源和服務(wù)器代碼若是綁定，部署單頁(yè)應(yīng)用就變得既簡(jiǎn)單又穩(wěn)定。此外，你可以利用原生JavaScript 工具的優(yōu)勢(shì)，而不管應(yīng)用框架是什么。核心是，服務(wù)器/瀏覽器的關(guān)系是一個(gè)簡(jiǎn)單的分布式系統(tǒng)。通過在服務(wù)器端單獨(dú)部署單頁(yè)面應(yīng)用，你的團(tuán)隊(duì)可以獲得微系統(tǒng)架構(gòu)帶來的靈活性，專注度以及優(yōu)先度。
OneAPM Browser Insight 是一個(gè)基于真實(shí)用戶的 Web 前端性能監(jiān)控平臺(tái)，能幫助大家定位網(wǎng)站性能瓶頸，實(shí)現(xiàn)網(wǎng)站加速效果可視化；支持瀏覽器、微信、App 瀏覽 HTML 和 HTML5 頁(yè)面。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問 OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客
原文地址：http://blog.codeship.com/continuously-deploying-single-page-apps/
