關(guān)注若川視野, 回復(fù)"pdf" 領(lǐng)取資料，回復(fù)"加群"，可加群長期交流學(xué)習(xí)

一、前言

大家好，我叫鰻魚，這次分享的主題是如何從 0 到 1 打造適合自己的構(gòu)建部署方案。

image.png

先例行的自我介紹，大概 14 年開始接觸前端，曾經(jīng)在菜鳥實習(xí)過，現(xiàn)在是在百度我也不知道算啥 title 的前端開發(fā)，帶了個小團(tuán)隊。前兩期在女生職業(yè)發(fā)展道路上已經(jīng)分享過一次，然后當(dāng)時說過自己對工程化這一塊興趣比較大，相信懶是程序員的美德之一，這次又過來做一次分享。

image.png

這次的話題其實說大不大，說小也有很多零零散散的東西可以講，自己公司內(nèi)部也有一定的實戰(zhàn)經(jīng)驗甚至完善的平臺。不過調(diào)研發(fā)現(xiàn)其實大部分中小型公司并沒有專門的人去折騰這些事情，也不知道怎么做或者說沒精力搞那么復(fù)雜的東西。

所以這次分享的話題可能比較輕松，剛好大家午休時間，可以邊吃飯邊看，也不用那么燒腦。主要受眾可能是一些對構(gòu)建部署還停留在聽說過，但是沒有實際用過的偏小白。時間關(guān)系也沒有像其他講師畫那么多高大上的架構(gòu)圖。但是會比較細(xì)粒度的解析構(gòu)建部署的過程，希望能幫助形成一個大體的概念，便于梳理能去選擇合適自己的方案。具體的平臺實現(xiàn)還可以參考其他講師們的 PPT，也都非常不錯。

image.png

這次主體大致包含兩部分：

第一塊就是，為什么我們要花那么多功夫去做構(gòu)建部署的事情。

第二塊是我們可以怎么去做，分為構(gòu)建和部署兩個部分。

image.png

二、為什么要做？

項目開發(fā)流程

從前端進(jìn)入現(xiàn)代社會之后，無論是看社區(qū)論壇還是各種分享，都能看到各種各樣講構(gòu)建部署的東西。那么它到底有什么魔力吸引大家都紛紛駐足呢？我們可以從項目的整體結(jié)構(gòu)來看，前端其實就是軟件開發(fā)交付過程中的一個小小的環(huán)節(jié)而已。通常來說，一個互聯(lián)網(wǎng)軟件開發(fā)的流程如下：

image.png

大多數(shù)都是本地編碼完畢，然后執(zhí)行 npm run build? 去做打包構(gòu)建，通過一定的方式推送到一個測試環(huán)境去看看有沒有問題。遇到 bug 就改 bug，沒有 bug 就喊相關(guān)人員驗收，并進(jìn)行部署上線。這整個流程可能有自動化的部分，也有手動的部分，每個團(tuán)隊?wèi)?yīng)該多少都有點區(qū)別 ，通常來說自動化程度跟團(tuán)隊規(guī)模還有業(yè)務(wù)復(fù)雜度都有關(guān)系。

但是業(yè)務(wù)如果持續(xù)發(fā)展，可能一般都會經(jīng)歷一個過程，就是剛開始我覺得這么玩玩就好了，我覺得好像也沒什么問題，實際上會變得越來越復(fù)雜。

我們理想中，可能會覺得 A 項目做完了，就上到 A 項目的服務(wù)上去，B 做完上到 B 的服務(wù)，C 做完上到 C 的服務(wù) 但是實際情況下，可能會出現(xiàn)不同的項目模塊，有相互依賴的關(guān)系，比如 B 服務(wù)要在 A 上線之后才能上線，D 又依賴 C，最可怕的還是相互依賴，遞歸依賴，傳說中依賴黑洞的現(xiàn)象。那么，這可能會出現(xiàn)什么問題呢？

image.png

軟件危機(jī)

我們看幾個歷史上的實際的例子，都是計算機(jī)早期的時候真實發(fā)生的故事：

美國銀行信托軟件系統(tǒng)開發(fā)案：美國銀行 1982 年進(jìn)入信托商業(yè)領(lǐng)域，并規(guī)劃發(fā)展信托軟件系統(tǒng)。項目原訂預(yù)算 2 千萬美元，開發(fā)時程 9 個月，預(yù)計于 1984 年 12 月 31 日以前完成，后來至 1987 年 3 月都未能完成該系統(tǒng)，期間已投入 6 千萬美元。美國銀行最終因為此系統(tǒng)不穩(wěn)定而不得不放棄，并將 340 億美元的信托賬戶轉(zhuǎn)移出去，并失去了 6 億美元的信托生意商機(jī)。

阿麗亞娜-5 運載火箭爆炸事件：96 年 6 月，阿麗亞娜-5 運載火箭首次測試發(fā)射，在發(fā)射后 37 秒被迫自行引爆，原因由于 64 位的運算錯誤地變?yōu)?16 位的運算，造成程序崩潰，火箭感測角度失常，從而觸發(fā)自毀裝置的啟動。

以上軟件問題均出現(xiàn)在計算機(jī)誕生早期的時候，計算機(jī)剛剛投入實際使用，軟件的規(guī)模比較小，很少使用系統(tǒng)化的開發(fā)方法。但是由于計算機(jī)的飛速發(fā)展，軟件系統(tǒng)的規(guī)模越來越大，復(fù)雜程度越來越高，產(chǎn)生的問題也越來越突出。其實在早 1968 年的時候，北大西洋公約組織在一次國際會議上，就已經(jīng)創(chuàng)造了軟件危機(jī)這一詞，并且連續(xù)召開過幾次會議，提出了軟件工程的概念。

那么軟件危機(jī)是什么呢？那與我們今天要說的工程化或者構(gòu)建部署有什么關(guān)系呢？

其實它需要解決的基本上是一類問題，主要是日益龐大的軟件系統(tǒng)，其復(fù)雜度已經(jīng)遠(yuǎn)超我們?nèi)四X可以直接控制的程度，很難說我們靠人力靠時間就能比較好的去保證所有東西都是沒問題的。

image.png

那么對于前端來說，他面領(lǐng)哪些問題呢？當(dāng)你代碼寫久了可能會有一些感覺，我們?nèi)粘Ｓ龅降募夹g(shù)問題可能少一些或者說好解決一些，但是工程問題反而較多，而且大多缺乏系統(tǒng)性和通用性。

比如說我們要開發(fā)一款完整的 Web 應(yīng)用時，我們不光要書寫 HTML/CSS/JS 之類的，來完成功能的開發(fā)。也將會面臨更多的工程問題，比如：

• 體量比較大的系統(tǒng)，有很多功能，有很多頁面，有各種狀態(tài)，要怎么去把他們組織起來；

• 再比如對于大型系統(tǒng)多人團(tuán)隊，我們作為承上啟下的環(huán)節(jié)，怎么去比較好的進(jìn)行多人甚至多團(tuán)隊合作開發(fā)；

• 再有就是我們經(jīng)常說的性能優(yōu)化問題，比如說 CDN 部署、緩存控制、按需加載、首屏渲染等等。

image.png

所以，這個時候其實我們就需要工程化了，前端工程化的定義就是借助軟件工程的技術(shù)、方法和思想，來優(yōu)化前端側(cè)的流程、效率和規(guī)范等。參考網(wǎng)上將前端工程化分四個能力點：規(guī)范化、模塊化、組件化、自動化，個人是比較認(rèn)同。

但是其中的每個點要細(xì)講，都能牽扯出不少的東西，這次的分享只是講其中的一部分，就是如何自動化，更具體來說是構(gòu)建部署階段的自動化。

image.png

工程化&自動化

說到自動化，有一個可能都聽說過的詞，CI/CD。但是他具體是指帶什么？我們看一下：

CI/CD 是指在應(yīng)用開發(fā)過程中，通過自動化手段來頻繁向客戶交付應(yīng)用的方法。核心概念是持續(xù)集成、持續(xù)交付和持續(xù)部署。

• CI（Continuous Integration）簡稱持續(xù)集成，原意是各個開發(fā)者在開發(fā)過程中，需要將代碼集合到一起，比如我們的 GitLab，GitHub 等。現(xiàn)在大多會包含集成之后，自動觸發(fā)編譯，測試等過程，幫助開發(fā)者及時收集問題。

• CD（Continuous Delivery）指的是持續(xù)交付和持續(xù)部署，經(jīng)過 CI 后，代碼自動部署到服務(wù)器上的一個過程。

image.png

然后看一下市面上對于項目的開發(fā)流程過程中，會涉及到的一些常見的平臺（這里是網(wǎng)上找的一張圖比較糊，沒來得及找高清的，大概看一下后面都會有詳細(xì)說明）：

• 代碼托管：我們有 GitHub/GitLab/還有國內(nèi)的碼云，Coding 之類的平臺；

• 構(gòu)建：對于 Java 有 Maven，對于前端是 npm；

• 集成：有 Jenkins，Travis，測試對于前端是 Mocha/Jest 之類的工具；

• 部署：物理機(jī)/虛擬機(jī)/Docker K8s 等等。

image.png

CI/CD 主要是自動化地在云端平臺去完成這些事情。一方面來說像早上冬冬說的保持環(huán)境的一致性，提高構(gòu)建部署的穩(wěn)定性。另外一方面就是通過自動化去減少重復(fù)機(jī)械的勞動。

所以從收益來講，肯定是項目越多，模塊關(guān)系越復(fù)雜，帶來的收益越明顯。

image.png

三、怎么做？

第二個環(huán)節(jié)，我們大概知道了要做什么，那么具體怎么做呢？

構(gòu)建篇

image.png

首先是構(gòu)建，剛剛說過，構(gòu)建指從本地開發(fā)提交到代碼庫，以及完成遠(yuǎn)程構(gòu)建，自動化測試等一系列的過程。我們按順序來看：

首先，當(dāng)你完成一個功能，本地看著沒問題之后，去做 git commit 的時候，從自動化的角度來說，我們可以做什么事情？

image.png

這里有一個很重要的點，也是會貫穿構(gòu)建流的一個點。就是我們要知道，git 不光只是代碼存儲，還有一系列鉤子，能允許你在特定的時期，做一些想做的事情。例如 precommit，就是代碼提交前，我們可以用它來做一些本地代碼檢查，比如 ESLint，再有比如自動化測試，在檢查通過之后再允許代碼提交。通常對于前端來說，我們會結(jié)合 husky 來使用。

作為一個合格的校驗系統(tǒng)，當(dāng)然不光只是讓用戶自己做本地檢查就夠了，畢竟在某些特殊狀態(tài)下，大家可以有各種手段去繞過自己的檢查。因此對于一些關(guān)鍵平臺或者項目，就需要服務(wù)端檢查的東西了。比如目前我們自己這邊的系統(tǒng)，在代碼提交之后但是還沒入庫之前，會自動的去做一些復(fù)用率檢查，安全掃描等等，這個就是 pre-receive 鉤子可以做到的事。當(dāng)然，對于一些小型系統(tǒng)這個環(huán)節(jié)其實可以直接跳過。

另外，我們可能還會有 Code Review 環(huán)節(jié)，代碼被人審查過之后才允許合入。以及在合入之后，也能有一定事件，比如去通知合作方及時更新代碼，去通知流水線繼續(xù)走后續(xù)構(gòu)建的流程等等。

image.png

當(dāng)我們提交完代碼，作為一個合格的 CI 系統(tǒng)，還需要做什么事情呢？就是打包構(gòu)建了。

這里的打包其實就是 npm run build? 的過程，只是執(zhí)行的環(huán)境不是你本地的機(jī)器，而是換成了在線的統(tǒng)一環(huán)境的機(jī)器，比如項目測試環(huán)境的機(jī)器，公司內(nèi)統(tǒng)一的編譯機(jī)等。但是他做的事還是一樣的。

image.png

通常大多數(shù)情況來說，我們執(zhí)行 npm run build? ，然后去拿 dist 的產(chǎn)物就結(jié)束了。但是實際如果你玩 CI 的過程中，你很有可能遇到一些環(huán)境不一致，版本不一致等莫名其妙報錯的問題，這個時候如果你能對構(gòu)建過程有一定了解，在定位問題層面可能就能有一定幫助了。

比如在現(xiàn)代化前端的演進(jìn)中，我們早就從解釋性語言，變成了半編譯型語言。因此在打包核心功能時就是要把我們自己理解的代碼，變成瀏覽器可認(rèn)識的代碼，這里舉個實際的例子。

image.png

比如對于 TypeScript 的代碼，我們有 Interface，有變量類型定義，轉(zhuǎn)化器也是會先將它解析成 AST 的語法樹，具體解析成啥樣有個在線的網(wǎng)站可以查詢，具體的解析原理其實網(wǎng)上也很多資料，然后根據(jù) AST 去掉給我們看的內(nèi)容，變成可執(zhí)行的 JS 代碼。

image.png

當(dāng)然在編譯過程中，肯定不止是代碼轉(zhuǎn)換這么簡單，很多時候我們有很多很多其他的配置，例如 icon，我們可能需要把零零散散分散在各處的圖標(biāo)，生成 iconfont 或者雪碧圖。還有代碼合并壓縮，靜態(tài)變量替換等等，具體可能會做什么事情，以 Webpack 為例，可以參照其常見的 loader。

image.png

總的來說，當(dāng)我們執(zhí)行 npm run build? 的時候，無論你用什么工具什么方式，我們核心需要把零零散散的資源打包匯總到一起，讓其可執(zhí)行。

image.png

那么常見的打包工具有哪些呢？比如早一點的有 Browserify，Gulp，Grunt，新一點的有 Webpack，Rollup，Parcel 等等。

打包這塊好了，那 CI 的一個核心點，是自動化，就是在代碼提交之后能自動去運行打包的腳本，而不是我在本地打包之后一起提交帶代碼庫里面。

通常來說我們可以去選擇各大平臺提供的現(xiàn)成工具，例如 Travis CI，這是一個跟 GitHub 強(qiáng)集成的 CI 平臺，對于一些開源項目，或者自己想要練練手的時候，就可以用它去玩了。左邊是一份它的 CI 的配置文件，大致功能就是能配置在什么階段，可以去做什么事情。

另外還有 Jekins，這是一個開源的基于 Java 的一種持續(xù)集成平臺，對于一些私有化部署的項目應(yīng)該算是用得非常多的一個平臺了。還有基于 GitLab 內(nèi)置的平臺，國內(nèi)的幾個代碼托管平臺好像也有類似的服務(wù)。當(dāng)然對于一些大型公司，還會有自研的平臺，這里就不細(xì)說。

image.png

具體要怎么選？個人覺得：

• 對于一些中小型團(tuán)隊，建議直接找市面上成熟的工具，然后結(jié)合這次大家的分享，可以做一些簡單的封裝；

• 對于成熟度比較高業(yè)務(wù)復(fù)雜的大型團(tuán)隊，有較強(qiáng)的技術(shù)中臺或者有專門的人力去做這一塊的事情的話，可以考慮自研或者高度定制化。

image.png

具體怎么做？無論哪種方式，其實他的思路都差不多，自研需要的東西也很簡單：

首先，你要有一個運行環(huán)境，就是能讓你執(zhí)行 npm run install? 和 npm run build? 不會報錯的地方。無論是物理機(jī)，還是虛擬機(jī)，還是容器都沒問題。

其次，你需要一個代碼托管平臺，無論是現(xiàn)成的，還是自己私有化搭建的，只要能保證以能執(zhí)行 git 的各種鉤子就行。

然后大致的一個流程，當(dāng)你提交代碼之后，可能會去做一些本地檢查，這個應(yīng)該是配置在項目代碼庫中的，比如用 husky 結(jié)合 ESLint 做代碼規(guī)范性檢查。檢查過了之后，git 會自動推送代碼到遠(yuǎn)程代碼庫，這個時候可以結(jié)合服務(wù)端的 git-hook? 做檢查，當(dāng)然沒有也沒問題。

當(dāng)你收到代碼提交通知的時候，需要有一個 Web hook 連接通知到你配置的可用編譯環(huán)境里面，告訴它我有新的代碼提交了，你可以開始一系列后續(xù)任務(wù)。那么通常來說編譯機(jī)會要做什么呢？首先需要將代碼 clone 下來，并安裝所需要的依賴，對于前端來說就是 npm install?，然后去打包就是 npm run build?。這樣你在服務(wù)器上就已經(jīng)得到了你想要的產(chǎn)出，構(gòu)建過程就已經(jīng)完畢。

看起來是不是覺得很簡單 :)

image.png

但是當(dāng)系統(tǒng)復(fù)雜度升高，業(yè)務(wù)多了之后，實際情況可能會遇到的一些思考點，也是我們目前有的一些東西，這里只是拋出來大家可以想一想。

首先 Git hook 觸發(fā)方式，代碼提交了之后是自動觸發(fā)的，那怎么去做到定時觸發(fā)，怎么去在一個代碼庫編譯完了之后，通知另外一個代碼庫去做編譯。其次還有分支，有時候我們只想 dev 分支去做自動編譯，master 分支需要有特殊控制，怎么去更好的監(jiān)聽分支的變化，除了精確匹配是否還可以有前綴匹配，正則匹配等方式。再有就是實際業(yè)務(wù)是怎樣的，我需要用到哪些鉤子等等...

image.png

然后在編譯構(gòu)建層面，可能還會涉及到，環(huán)境變量有哪些，不同流程之間怎么做到一些通用變量共享。我們實際有哪些環(huán)境，比如說 node8，node10，怎么去特定換定編譯，怎么切換？

編譯所有都串型感覺太慢了，我們怎么去做并行編譯。機(jī)器對編譯產(chǎn)物怎么去存儲，是否有定時清理機(jī)制過期時間等，還有一些異常的處理，超時機(jī)制，各種檢查具體怎么做？

這些都是一些細(xì)節(jié)問題，也沒辦法在此次分享給出一個標(biāo)準(zhǔn)答案。它是一個跟業(yè)務(wù)密切相關(guān)的過程，只要做了多多少少都會碰到這些問題。但相信對于一些積極思考熱愛學(xué)習(xí)的同學(xué)，比如能周末來聽早早聊的，應(yīng)該能自己去探索得出答案。

image.png

部署篇

image.png

然后部署，當(dāng)我們拿到了產(chǎn)出，怎么把產(chǎn)出給弄到不同的環(huán)境，怎么優(yōu)雅的上線，也是一個值得思考的問題。

我們再看看歷史，一直在說前后端分離不分離，那么具體常見的前后端合作模式有哪些呢？

前后端完全不分離，前后端在一個代碼庫里面，前端在本地跑的時候很有可能要配置后端的服務(wù)環(huán)境，提交代碼后端幫忙一起部署；

前后端代碼庫分離了，但是部署到機(jī)器中還是在同個服務(wù)內(nèi)，這個時候可能我們會把代碼產(chǎn)出本地打包丟給后端，或者說通過一系列自動化工具直接推到服務(wù)器對應(yīng)的靜態(tài)資源目錄里面；

前端后端代碼分離了，部署也都分離開了，前端這個時候通常來說可能就是一個簡單的 HTTP，中間可能通過一些后端路由轉(zhuǎn)發(fā)的形式做關(guān)聯(lián)；

對于一些現(xiàn)在的大型團(tuán)隊，可能前端不直接跟后端對接，還會有一個 BFF 中間層去做一些轉(zhuǎn)發(fā)配置，甚至身份校驗之類的事情。

image.png

以上，應(yīng)該是一個前端開發(fā)的歷史進(jìn)程的縮影，我們來來回回的折騰，看著越來越復(fù)雜，但是其實無論哪種，部署都是大同小異的。

image.png

來看看我們的目標(biāo)，最前面也有說，所謂的構(gòu)建部署，就是把各種手動操作的東西，變成自動化規(guī)范化的流程。

因此我們的目標(biāo)，就是需要把曾經(jīng)手動丟服務(wù)器，需要多人協(xié)同操作口口相傳的這種情況。變成能由較少人可以操作，由工具去幫我們自動做分發(fā)，部署之類的事情，從而來提高部署的效率和穩(wěn)定性。

image.png

具體怎么丟，其實很簡單，可以理解成是一個文件上傳的過程。所以無論你使用 FTP，還是有個 HTTP 請求的接口，都沒什么大的問題，這里不做仔細(xì)描述。

image.png

那么我們遇到的問題可能是什么呢，對于前后端分開部署前端有自己獨立服務(wù)的應(yīng)用，可能更大的問題是應(yīng)該要怎么發(fā)布，畢竟服務(wù)重啟這回事，如果掛了分分鐘影響的都是流量。這也是為什么大部分業(yè)務(wù)上線時間可能都是挑晚上上線。

我們看看市面上常見的一些發(fā)布策略，這個對于前端來說可能接觸得并不是很多。

image.png

首先說藍(lán)綠部署，指我們同時運行兩個版本的應(yīng)用，藍(lán)綠部署的時候，并不停止掉老版本，而是直接部署一套新版本，等新版本運行起來后，再將流量切換到新版本上。

這就要求在升級過程中，同時運行兩套程序，對硬件的要求就是日常所需的二倍，比如日常運行時，需要 10 臺服務(wù)器支撐業(yè)務(wù)，那么使用藍(lán)綠部署，你就需要購置 20 臺服務(wù)器，顯然，比較耗費資源。

image.png

滾動升級，就是在升級過程中，并不一下子啟動所有新版本，是先啟動一臺新版本，再停止一臺老版本，然后再啟動一臺新版本，再停止一臺老版本，直到升級完成，這樣的話，如果日常需要 10 臺服務(wù)器，那么升級過程中也就只需要 11 臺就行了。

image.png

再有就是灰度發(fā)布，這個其實就已經(jīng)不算是發(fā)布策略了，而是一個測試的策略。也是日常會用得比較多的一個點，先啟動一個新版本應(yīng)用，但是并不會像是滾動升級一樣，不斷的對所有服務(wù)進(jìn)行切換，而是會將小部分了流量導(dǎo)入到新版本的環(huán)境中，測試人員對新版本進(jìn)行線上測試。如果沒有問題，那么可以將少量的用戶流量導(dǎo)入到新版本上。這種發(fā)布方式也叫做金絲雀發(fā)布，具體為什么叫金絲雀有興趣的同學(xué)可以自己搜一搜。

如果這個時候我們對新版本做運行狀態(tài)觀察，收集各種數(shù)據(jù)，并做新舊數(shù)據(jù)的對比，這就是所謂的 A/B 測試。

image.png

說了那么多部署方式，那么對我們前端來說有什么用呢，一方面來說更好的了解后端的一個部署模式在跟后端或者做溝通的時候可以稍微多一些底氣，另外也可以借鑒借鑒，知道前端要怎么玩。

通常來說，前端部署可能可以劃分為覆蓋式部署和非覆蓋式部署。覆蓋式部署大多就是資源在服務(wù)器上，每次部署把之前的內(nèi)容都刪了重新替換。而非覆蓋式會存儲多套資源，在恰當(dāng)?shù)臅r候去控制做資源的切換，有點類似藍(lán)綠，但是沒有銷毀的過程。

對于個人來說，我們這邊可能目前用的比較多的是非覆蓋式，將資源都部署到對象存儲上面，例如阿里的 OSS，百度的 BOS，去使用它們的 CDN 功能。然后在 Nginx 或者哪一層去控制資源的版本切換，或者說默認(rèn)使用其 lastest 的版本。

image.png

那么對于普通的業(yè)務(wù)開發(fā)，我們應(yīng)該怎么選呢？上面說的各種部署方式，市面上很多云平臺都有一定的支持。因此對一些業(yè)務(wù)簡單的小團(tuán)隊，可以考慮直接找個云平臺，然后擼一擼公共腳本或者服務(wù)，串一串就可以開心的玩耍了。

對于一些業(yè)務(wù)龐大復(fù)雜，有人力精力的情況下，也可以考慮弄一個可視化的流水線平臺，像是早上其他講師分享的。這建議是在有一定規(guī)模之后，且簡單模式 run 了一定時候再去搞。

image.png

具體可能會涉及到哪些東西呢，首先呢還是一樣，需要有一個環(huán)境，可以跟上面說的編譯環(huán)境保持一致。然后拉取打包后的產(chǎn)物，并將產(chǎn)物發(fā)送到指定的機(jī)器/CDN，期間可能會涉及到一些服務(wù)之間的關(guān)聯(lián)，部署模式等。

image.png

這是我們這邊的一個流水線平臺的大概例子，它大概的功能可以遠(yuǎn)遠(yuǎn)不止 Web 的構(gòu)建和打包，還有像是客戶端，Server 類型的不同環(huán)境的編譯，都是以插件的形式集成到其中。

另外還可以做一些常見跟發(fā)布相關(guān)的功能，比如打版本號，提測，環(huán)境切換，發(fā)單，審批等都可以在這里進(jìn)行。

image.png

然后對于部署，同樣有一些思考點，這里也是列舉不做詳細(xì)的解答，比如：怎么制定部署到不同環(huán)境，怎么去做權(quán)限的控制，然后部署成功的通知，失敗的回滾和通知，怎么去打版本號，還有對于前端 Sourcemap 怎么存，怎么做關(guān)聯(lián)，日志怎么去做上報存儲分析，對于物理機(jī)，虛擬機(jī)，Docker 等不同形式我們怎么去做部署。

image.png

另外，如果自己搞平臺，那么我們的關(guān)注點，除了構(gòu)建部署，我們還能做什么別的事情，比如說：代碼跟需求卡片關(guān)聯(lián)，自動提測，各種服務(wù)端的檢查，各種測試，審批等等。

思路層面這里基本就講完了。

image.png

四、總結(jié)

總的來說，以上就是構(gòu)建部署的一個簡單介紹。對于具體業(yè)務(wù)，不同的方向的需求多多少少都有些不同，這也是軟件開發(fā)中一個比較難的部分。

這次分享只是做了細(xì)粒度的思路拆解，具體方案其他講師也都說得很清楚。這里引用人月神話中一句話，“軟件開發(fā)中最困難的部分是規(guī)格說明，設(shè)計和測試這些概念上的結(jié)構(gòu)，而不是對概念進(jìn)行表達(dá)和對表達(dá)完整程度進(jìn)行驗證。所以軟件開發(fā)天生就沒有銀彈”。

這里核心想說明的就是構(gòu)建部署沒有銀彈，大家需要根據(jù)自身情況做各種調(diào)整，希望大家都能早日造就適合自己的方式。

image.png

既然說到這里了，那么分享例行需要推薦的書就是這本《人月神話》。被很多人都推薦以及評分都特別高的書，剛開始看可能看不懂，當(dāng)你有了一定經(jīng)驗，項目達(dá)到一定規(guī)模之后再回頭來看，可能會有不一樣的體會。

推薦閱讀

我在阿里招前端，我該怎么幫你？（現(xiàn)在還可以加模擬面試群）
如何拿下阿里巴巴 P6 的前端 Offer
如何準(zhǔn)備阿里P6/P7前端面試--項目經(jīng)歷準(zhǔn)備篇
大廠面試官常問的亮點，該如何做出？
如何從初級到專家(P4-P7)打破成長瓶頸和有效突破
若川知乎問答：2年前端經(jīng)驗，做的項目沒什么技術(shù)含量，怎么辦？
若川知乎高贊：有哪些必看的 JS庫？

末尾

你好，我是若川，江湖人稱菜如若川，歷時一年只寫了一個學(xué)習(xí)源碼整體架構(gòu)系列~(點擊藍(lán)字了解我)

關(guān)注若川視野，回復(fù)"pdf" 領(lǐng)取優(yōu)質(zhì)前端書籍pdf，回復(fù)"加群"，可加群長期交流學(xué)習(xí)

我的博客地址：https://lxchuan12.gitee.io?歡迎收藏

覺得文章不錯，可以點個在看呀^_^另外歡迎留言交流～

小提醒：若川視野公眾號面試、源碼等文章合集在菜單欄中間【源碼精選】按鈕，歡迎點擊閱讀，也可以星標(biāo)我的公眾號，便于查找

總結(jié)

以上是生活随笔為你收集整理的如何从 0 到 1 打造团队 PC/H5 构建工具的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。