專欄寫到這，代碼部分已經完成了，其實是個小小的項目，代碼量也不大，但實現了我們想要的目標，那麼我們還需要將這個大屏的項目部署到服務器上，我們要做就把完整的流程都做一遍。
一、打包方式的技術選型
項目是前後端分離開發的，我們在開發階段是前後端項目分別啓動的，現在要上線，有這麼幾種方案可供選擇：
- 服務器上也前後端分別部署
- 將前端打包後的靜態資源拷貝到服務器的nginx上，後端項目單獨部署
- 使用jenkins這樣的流水線工具部署
- 將前後端代碼打包在一起進行部署
這幾種方案在不同的項目中都有他們的應用場景，而過於我們這麼一個小小的項目來說，前兩種方案都特別不方便，尤其是邊開發邊使用的情況下，改一點前端代碼，就需要打包一次上傳部署一次，這無形中增加了我們很多的工作量。這裏我想讓大家明白的是這麼一個道理，前後端分離開發固然是一個趨勢，但對於小團隊，如果處理不好部署的問題，那會給團隊無形中帶來很多的工作量，會造成團隊工作效率低下。
而我們爲了儘可能地少幹活，那就必須要減少一些不必要的操作，此處就是，前後端的分立部署，絕對不是一件輕鬆的事情。
那此時同學們可能會說，那採用jenkins進行流水線部署呢？那就很簡單了呀，確實，使用jenkins確實能降低很多工作量，也是一種非常好的部署方式，但要注意，使用jenkins可是需要很多服務器資源的，安裝maven私服，部署jenkins服務都要佔用不小的服務器資源。比如，我的服務器就是個一核兩G的學生機，比如，你做的私活項目，客戶就給了你一臺兩核四G的阿里雲主機，那你還在服務器上裝jenkins？安裝jenkins這一套這都是工作量，而且jenkins的運維也是需要人來操作的，從哪方面來說，jenkins對於小項目小團隊來說，都太重了，我們的項目還沒到需要使用這種重量級組件的程度。
所以，我們選擇dubbo-admin採用的方式，開發時前後端分離，部署時將前後端打包到一個Jar包中運行。