1年前入職時，公司前端部門的靜態**部署都是用ftp工具拖拽部署，沒有記錄，沒有關聯，經常造成許多困擾的問題，
比如：今天有沒有其他人在我要部署的路徑上工作？我的**為啥被蓋掉了？被誰蓋掉的？啥時候蓋掉的？
本地build，ftp拖拽部署這種方式，導致git版本與手動的構建、部署沒啥關聯，更有在本地寫完**部署上去後，壓根沒傳git這種失誤可能發生。
靠人去遵守規範來控制工作流，總會有失誤、疏忽的發生。
要靠機器和**去規範工作流，提高效率、準確性，實現真正的前端工程化。
不討論通用模板(專案開發層面)，只關心構建以後的事情，精確的說，就是從npm run build:*** 這個指令碼開始對接，npm run build:***之前的事情不在本文討論範圍內。 實現構建-部署-測試(多個環境)-沙箱-上線(可回滾)的全部半自動化流程把控。
為什麼選擇jenkins：優先選擇強大的開源工具，避免重複造輪子，主要原因是外掛程式特別豐富，基本可以滿足所有實際需求
先把成果貼上來，整體示意圖
核心思想是分離構建、部署，所以每個專案，jenkins會建兩個job。
jenkins服務部署在公司內網堡壘機上，使用tomcat管理jenkins的war包，占用系統服務、全量部署定時任務都跑在同一臺堡壘機上(linux)。
因為內容很多，所以我直接採用一張圖 + 注釋 來零碎的講解每個功能的實現，因為每個公司的前端業務環境都不一樣，所以我也不打算花太大的筆墨去描述所有的實現。寫這篇文章的目的就是可能某個思想、某一段對jenkins外掛程式的使用等等會幫助到有類似需求的人。注釋會是截圖，或者是關鍵**，對應圖中的數字。
先放幾張實際使用的圖
jenkins專案介面部分截圖
構建job部分截圖
部署job部分截圖（使用jenkins-pipeline實現流程圖）
多套測試環境占用系統部分截圖（占用環境後別人無法部署，全量指令碼也不會覆蓋）
全量部署指令碼日誌展示部分截圖
整體示意圖的注釋（每一條都對應示意圖中的紅色阿拉伯數字）：構建和部署分離開來，便於後續的各種操作，比如全量部署、分環境部署、回滾**等都是不需要構建操作的，耦合在一起會做很多無用功。
同上一次構建三個包，保證了測試環境和沙箱、線上的構建環境/***引數的一致性（用shell指令碼實現，具體如何實現不細說，就是迴圈變數執行npm指令碼，shell指令碼由git倉庫管理，jenkins配置時統一拉取**，這樣所有的專案配置可以同步。示例如下）
4. 下圖展示了部署job可操作的選項
上圖中有說明
貼一段jenkinsfile**，語法為pipeline script
原理同6
占用系統是另外開發的，配套使用，上面有占用系統的示意圖，是用node做後台，vue+element做前台快速開發的，這裡不展開說；
這個利用jenkins的url auth plugin，再開發一下對接公司統一登入系統的api，就可以直接用了，本質上是圍繞cookie來進行的，每個公司都有自己的統一登入(也可能沒有，那就使用jenkins自帶的使用者系統)，這裡不展開說。
全量部署指令碼用corntab，用node指令碼實現，核心思想在於讀取說明6中的"now_online.json"來得知是哪乙個包是線上的，取到這個包，同步到所有測試環境。同時檢測是否有改動，沒改動則跳過；同時檢測說明8中的標記，查明環境是否有人占用，占用也跳過。上面我有貼日誌的截圖。
這裡的意思就是，構建任務還沒執行完的時候，開啟了部署任務進行部署，此時要檢查一下構建任務是否插入了構建完成的標記，不然不能部署。
這裡是我自認為最大的亮點，「如何保證當前分支上的**絕對不落後於master」？我們都知道master上的**即是線上最新**，當多人協作開發的時候，有人先上線，此時master**更新，而後上線的人還在用老的**測試、上線，這樣就會造成問題，除了人為保證主動去pull**，有沒有更可靠的方式？這裡就是工程化的一大亮點，我們設想，如果後上線的人的分支上有落後於master的**，那麼我們就不讓jenkins的構建/部署成功！如何通過**實現並整合進jenkins？我研究了一下git的命令，如果執行 git log [你的當前分支]..origin/master 列印了空值，那麼說明當前分支沒有落後，如果列印了內容，那麼就說明分支落後與master！具體用shell實現示例：
check_results=`git log $branchname..origin/master`
if [[ ! $check_results = "" ]]
then
echo "【error】：當前**比master落後，需要合併master或更新**重新打包之後才能進行構建！"
exit 1
else
echo "【info】:當前**正常，可以部署！"
fi複製**
通過說明6中的pipeline script 中的 input 語法實現
回滾的關鍵**也在說明6中有。
整篇文章比較零散，主要講了一下我對前端工程化探索的思想和實踐，因為手頭的需求也很多(18年一起工作的好幾個小夥伴被裁了，你猜他們剩下的工作誰來做)，斷斷續續搞了兩三個月，目前這套系統已經穩定執行幾個月了，不斷的完善使它現在很好用，線上再也不會出現因為忘了某些分支操作導致的bug；這套系統的優點就是，基於開源jenkins+核心思想，就可以很快的通過node/shell/pipelinescript搭建起一套完整的系統，成本極低！超級實用的功能卻實現很多！
如果你覺得讀完沒啥收穫或我寫的實在不知所云，那就好好看看說明12，我覺得把這乙個小技巧分享出去，並且讓你有所收穫，那也值了，畢竟寫作能力有限~
前端工程化
為什麼出現了前端工程化？09年之前，我們學習的css，div，js只是對頁面設計進行乙個打輔助的功能，當時只能勉強的成為頁面設計師，為什麼會出現前端工程師 1.突然間前端的需求逐漸增多，使用者對介面的要求越來越高，前端範疇越來越大。2.前後端總是保持一致才能進行開發，不能分開開發，提出前端工程化，也...
前端工程化
一 什麼是前端工程化 根據業務特點，將前端開發流程規範化 標準化 包括開發流程 技術選型，規範，構建發布等用於提公升前端工程師開發效率和 質量，提高產品的質量。實現前端工程化的目的 就是通過流程規範 自動化工具來提公升前端的開發效率 效能 質量 多人協作能力以及開發體驗。前端工程化體系分為 元件化 ...
前端工程化
老大考慮到團隊成員學習的曲線，最終選擇thunk 為了更方便團隊人員使用，封裝直接的thunk，和cobinereducer 1 專案分為四大塊，服務治理，資源治理，診斷除錯，分析管理 幾十個元件，不可能將所有的狀態解除安裝乙個reducer裡面來管理 不利於維護 然後因為封裝了元件thunk所以要...