vue build 在伺服器build還是在本地build之後放在伺服器？

01-06

如題，用的是vue-cli構建項目的，剛剛玩vue，所以有很多不懂，代碼要上線了，遇到個選擇，
1.代碼在本地build之後再吧build好的代碼發布到伺服器
2.在伺服器上安裝node 去build代碼

這個其實和vue 無關，是一個通用問題：即代碼在哪裡構建。如果題主的伺服器指的是運行伺服器，那其實兩種都不是好選擇。

很多新人包括我工作前都以為部署代碼是這樣的

但實際上在較大的互聯網公司會麻煩一些。以下介紹都是常見做法，並簡化了一些流程，僅僅只是為了方便新人理解。

代碼提交到git或svn伺服器

注意這裡是源文件，不是build後的文件

2. 構建伺服器會從git伺服器中拉去要發布的代碼版本

在這裡完成安裝依賴，如題主的vue。並構建用於部署的文件，這些文件一般也會被壓縮成一個壓縮包用於管理

3. 構建後的發布包會被上傳到中轉站：文件管理伺服器集群

4. 實際運行的伺服器一般不會是單台，而是集群，這n台伺服器會從文件伺服器中拉去對應版本的相同壓縮包，並解壓最終運行

實際上，這裡有明顯的前後順序的流程在裡面，如果都是手動操作的話會非常麻煩，所以一般大公司里都會有一個自動部署平台來全局統籌完成這些工作，作為開發者其實只需要點下『一鍵部署』就完成以上內容了

如在配合gitlab、github這類提供的webhook自動通知自動部署平台，穩定版本的代碼已經完成推送了（Push Event）。那我們就連點一下按鈕都不需要了。

這是個典型的構建部署分離的Case，帶來的好處非常多，比如

確保構建的是一份代碼，避免多環境構建導致不一致的可能性
構建一般是個高開銷的行為，可能會引起運行伺服器的不穩定
可以快速回滾或回復，相同版本的代碼無需重構構建
。。。

考慮到生產環境可能是多個伺服器運行一套代碼，如果每個伺服器自己編譯，如果結果不一致怎麼辦，如果有的伺服器編譯失敗了怎麼辦？

建議在 build 的時候用一台環境一致的編譯機來做這個事情，然後把產物同步到生產環境裡面去。

淘寶的工程實踐是專門的16核構建伺服器，每次都通過 docker 創建完全乾凈的構建環境，然後構建。

這個其實不需要疑惑啊，你把它理解為編譯型語言是如何發布的不就行了？

例如 Java 項目是怎麼發布出去的？當然是通過 CI 伺服器拉取倉庫源碼運行一系列的測試和構建過程，然後 CD 伺服器推送同一塊編譯結果到其它節點部署運行。

而前端項目如果分離得比較徹底的話，可以說不需要部署這個步驟。因為僅僅是傳送靜態文件到 CDN 伺服器而已。

————

另外說下本地構建應該怎麼做：

在 CDN 上開放介面，一個是上傳靜態資源的介面，另一個是更新靜態資源 hash 值的介面（這個可以讓應用後台開放，這個介面將最新的資源 hash 儲存到資料庫）
在後台引用 JS 的地方讀取資料庫最新的資源 hash 值，頁面模板內容是死的。

然後在本地執行一個構建過程，將 build 出來的結果上傳到 CDN 然後更新資源 hash。

刷新一下網頁就變了，你的後台不會有任何的更新過程。我一年半以前的博客項目就是這麼做的。

這是全站的唯一頁面源碼：

這是 npm/yarn 執行的命令（其中 build 指令會有上傳和調用更新 hash 介面的過程）：

這是 build 指令其中的一個步驟（上傳到 CDN，這裡是七牛雲）：

也就是說，我更新完前端執行一下 npm build 就行了，什麼都不用做，就像你單純在做本地開發一樣。

而且這還是我一年半以前就放棄的項目，那時候沒有 vue-cli，是單純的用 webpack 本地做的。其實這個過程就相當於將 webpack 作為 CI/CD 程序了。

如果不是因為項目太小，我肯定會給它配置 CI 環境讓伺服器來做，因為那才是最高效的。提交代碼發送 webhook 觸發構建過程，一切步驟都是自主完成，連你點一個按鈕或者執行一條命令都省了。

任何簡單的事情放大了之後都會很複雜。 —— 魯迅

瀉藥。

對於個人而言當然是怎麼舒服怎麼來啦，都差不多的。

自己用的話可以寫個Webhook，每次提交代碼自動在伺服器打包。

當然業界已經有很多輪子了。

在公司里通常使用持續繼承工具：Jenkins。

但是在工作中，我們遇到的情況往往是在一個隔離的環境下，同時部署幾十台伺服器。

這時候你可能會向寫一些小工具來專門解決代碼部署中的同步問題。

比如這樣。

我直接參与的部署並不是很多，以後有機會總結再來補充～

以上。

我是在本地build完後使用rsync推送編譯後的dist文件夾的東西去伺服器的。

我的伺服器性能超級差，單核內存也就1G，經不起build文件的折騰。

如果你的伺服器性能好或者有錢買個專門的伺服器那倒可以試試伺服器上build，不過這也比較折騰

我們是本地build然後上傳，前面幾個自動化部署確實應該這樣，但我們運維還沒到那種程度

我司也是和高票一樣有專門的自動編譯模塊。但是，我也要補充一點經驗。編譯工具有時候因為一些配置沒配好，或是本身編譯器就有些小bug，會編譯錯誤，導致代碼運行不起來。所以不要本地用未編譯的源碼開發，然後構建伺服器編譯完直接發布外網，而是在測試環境就使用編譯後的文件來測試。

錢多就搞 build 伺服器，沒錢就用自己的機器開 docker 構建

不請自答。。。

這個部署的問題最好還是自己寫個腳本來搞定，因為上伺服器上打包麻麻煩煩的（1 G內存的伺服器、有時候跑不動 webpack 內存不夠被殺掉），在本地打包好之後又要傳上去也是很麻煩。

兩者都是機械性的、可被自動化的。。。所以建議寫個腳本到 `./build` 下搞定這事情

下面來說說寫自動部署的思路

通常我寫的頁面，需要將index.html放在伺服器上，而其他的靜態資源都是托放在七牛的。

所以，要部署的文件分兩類，一類是放在伺服器上的，一類是放在七牛上的。

所以：

利用 `globby` 取得 `./dist` 下所有子文件，然後分成如上所說的兩類
html 利用 sftp 上傳上去（利用 ssh2-sftp-client）
根據七牛的文檔編寫批量上傳（七牛 node.js sdk）

如果只是想要上傳到伺服器，其實只需用 ssh2-sftp-client 來上傳全部也是ok的。

推薦一個工具，自動構建和多環境部署，fjpublish.js，

也可以看看我的稀土掘金有詳細步驟，前端自動化、多環境配置到發布

本人也是學習，如有不足，請多指教

本地build，然後通過腳本發布

當然是本地build啊。

1，現在很多雲伺服器的內存和cpu並不多，一般都是根據業務量劃分。並沒有那麼多閑置資源給你用。

2，打包後可能還有問題的情況。

3，寫腳本push到生產環境很方便。

我選擇build再發布

好像都是本地啊，伺服器build感覺就不是很舒服

簡單的項目（如題主這樣的），直接本地編譯好。

伺服器要盡量乾淨，不需要安裝 node 的就不要安裝（依賴越多，問題越多）；
本地編譯比伺服器編譯快速方便（分分鐘修復 bug）。

額外 tip：

寫相應的 package.json 文件，用統一的命令 npm run deploy 部署可以更易記、省心；
規模大後有規模大的做法，獨立的伺服器編譯，自動化編譯等。

取決於你的伺服器能不能勝任build工作，如果能就部署一個github鉤子，參考一下gitflow模型，提交到master的代碼讓伺服器自己去Pull -&> Install -&> Build 豈不美滋滋？

然而我就厲害了

像我這種窮學生，1g的某里學生機是跑不動vue的build的 233

你們後端怎麼做的，前端也這麼干不就行了

我自己的項目是本地build再上傳的。。。

這個呀，我們公司用的是Jenkins，小團隊的話，你可以參考 Gitlab CI，做一個持續集成，除了build之外加上單元測試等等，最好是在伺服器上打包，然後發布產線。

絕大部分情況都是本地build,除非你是有錢人有build伺服器.

向我們這種買了幾百塊的單核伺服器,伺服器build豈不是自討苦吃?一萬個坑等你跳.