本文分享自百度開發者中心To B前端 CI/CD建設實踐css

背景
去年末團隊接手負責 30 多個面向 ToB 的平臺系統，系統多，需求緊，人力缺口一直存在，主要問題體如今：html

先後端部署耦合：先後端資源部署在同一 Web 容器，後端上線會帶着前端，一樣前端也會帶着後端；
研發流程不規範：各平臺缺乏統一的規範，好比分支規範，部署規範，聯調規範等；
研發質量保證：缺乏基本的質量保證手段，好比前端單元測試，先後端接口變動流程等；

經過技術手段提升研發效率一直是咱們追求的目標。今年經過對業界和公司內部愛番番團隊的相關技術調研，決定對現有研發流程進行改進規範，經過 CI/CD 能力建議，提升研發效率和下降運維成本（感謝愛番番團隊的 CI/CD 工做！）前端

今天主要從如下方面來講明 CI/CD 針對 ToB 場景的最佳實踐，除了說明作了 What 外，更重要但願能從價值收益上說明 How 和 Why。（注：ToC 與 ToB 各方面差別較大）數據庫

什麼是CI/CD

簡單理解：Continuous Integration/Continuous Deployment編程

深刻理解：基於新興的 DevOps 文化，以管道的形式，經過自動化構建、測試和部署，縮小開發團隊和操做團隊之間的差距，以到達快速穩定的交付目的。後端

名詞解釋

Devops
DevOps 是 Development 和 Operations 的組合，是一種思想、一組最佳實踐、以及一種文化，用於促進應用開發、應用運維和質量保障（QA）部門之間的溝通、協做與整合。以期打破傳統開發和運營之間的壁壘和鴻溝。瀏覽器
CI
CI 即 Continuous Integration 的縮寫，開發人員將會頻繁地向主幹提交代碼，這些新提交的代碼在最終合併到主幹前，須要通過編譯和自動化測試流進行驗證；安全
CD
CD 可對應多個英文名稱，持續交付 Continuous Delivery 和持續部署 Continuous Deployment；服務器

Continuous Delivery
完成 CI 中構建及單元測試和集成測試的自動化流程後，持續交付可自動將已驗證的代碼發佈到存儲庫。爲了實現高效的持續交付流程，務必要確 CI 已內置於開發管道。
持續交付的目標是擁有一個可隨時部署到生產環境的代碼庫。網絡
Continuous Deployment 對於一個成熟的 CI/CD 管道（Pipeline）來講，最後的階段是持續部署。做爲持續交付 —— 自動將生產就緒型構建版本發佈到代碼存儲庫 —— 的延伸，持續部署能夠自動將應用發佈到生產環境。

涵蓋範圍
涵蓋軟件開發全生命週期，做用於各個階段

基本原則

可靠性
CI 流水線須要很快
獨立環境中構建和運行
預發佈環境和生產環境等價

流程規範

CI/CD 實施的基本前提條件是根據團隊的技術能力現狀，制定符合團隊實際狀況的研發流程規範。

技術全景圖

研發流程規範

分支開發，主幹測試，RB 上線
歷史分支保留，確保隨時上線發佈
未測試代碼不帶到線上
按期檢測同步代碼機制，儘可能避免衝突
各項檢查能力 CI 上落地，保障高質量交付

分支管理規範

代碼版本分支是自動化構建的基礎，開發團隊必須遵照
feature 非必需分支，各團隊根據實際開發協同場景的複雜度，酌情使用
分支命名規範包含上線日期的作法，僅適合 ToB 場景

Pipeline 規範

編譯：使用公司統一的集羣編譯
安全掃描：啄木鳥、貓頭鷹
靜態代碼掃描：包含代碼規範和潛在的 Bug
端測試：自動化，穩定性

雲端部署（BOS/CDN)

部署設計

方案一與方案二的區別是 index.html 放在 BOS 仍是 RD 服務器？
優先推薦方案一：

與後端解耦更完全，html 的更新可由前端來控制
前端版本號管理放在 html 裏，不用更新 version.js，部署更簡單

方案一里有些後端可能沒法配置轉發；

備註：最優方案是由 BFE 配置轉發規則至 BOS，不用經 RD 集羣，但目前 BFE 沒法直接轉發至 BOS。

版本說明
前端靜態資源版本通常分兩種方式管理：
Hash 版本號：基於文件內容的 MD5 值，取部分長度或所有長度，作爲文件的版本號，每一個文件都有不一樣的版本號，適合於增量發佈，節約存儲空間。例如：index.abcd12.js，manifest.123456.js 等

時間戳版本號：以當前構建時間點爲準，生成時間文件夾，構建結構部署在時間文件夾下。適合於全量發佈。

目前選用時間戳版本號，考慮有以下：

Hash 版本，適合容器化部署，好比 Docker、Jarvis，每次包括全部資源文件；Bos 若是使用 Hash，文件夾下同名資源會有不少，顯得較亂。

部署目錄結構實例

performance
|---- 202101281200
|     |---- css
|     |---- js
|           |----index.js
|---- 202101291200
|     |---- css
|     |---- js
|           |----index.js
version.js
index.html

index.html 和 version.js 承擔版本號維護，每次上線時更新版本號。

單元測試

現狀
前端中是大部分是無測試的，國外的一項調查顯示，有 43% 的 developer 沒有作過任何前端相關測試，兩個主要緣由：

前端屬於 GUI 編程，瀏覽器不少，要在這麼多瀏覽器上作幾輪測試，實際上是成本很高，很昂貴；
某些類型的產品當中，不少時候 UI 界面迭代的更快，測試跟不上迭代；

以上兩點致使前端測試不受重視，不少開發可能工做好幾年年仍未寫過測試。

咱們爲何要作單測
ToB 業務與 ToC 相比：

業務會相對穩定：UI 頁面穩定變化少
穩定性要求極高：須要頻繁的進行迴歸測試，服務的是付費用戶
持續升級迭代：迭代週期相對較長

單測帶來的收益：

減小 Bug：現在的項目大多都是多人分模塊協同開發，當各個模塊集成時再去發現問題，定位和溝通成本是很是高的，經過單元測試來保證各個模塊的正確性，能夠儘早的發現問題，而不是等到集成時再發現問題；
放心重構：對於持續升級迭代的項目，代碼不斷的在變化和重構，經過單元測試，開發能夠放心的修改重構代碼，減小改代碼時心理負擔，提升重構的成功率；
改進設計：越是良好設計的代碼，通常越容易編寫單元測試，多個小的方法的單測通常比大方法（成百上千行代碼）的單測代碼要簡單、要穩定，因此在編寫單測的過程當中，若是發現單測代碼很是難寫，通常代表被測試的代碼包含了太多的依賴或功能，須要反思代碼的合理性，進而推動代碼設計的優化，造成正向循環；

前端自動化測試分層

E2E 測試：是一種黑盒測試，測試的是應用的執行是否從頭至尾都按設計完成。
整個應用程序已在實際場景中進行了測試，其中包括測試組件之間的通訊，例如數據庫，網絡，API 等，以及在各類瀏覽器中執行代碼基本上測試一切。設置會花費不少時間，並且成本最高。
集成測試：測試程序之間的交互，例如，UI 和 API 之間的通訊。設置所需的時間較短，也不太昂貴。
單元測試：是最小粒度的測試，由於它包括將代碼的孤立部分做爲單元進行測試。這些單元能夠是方法，屬性，某一個 UI 元素點擊、輸入這樣的動做等形式。例如說我有一個函數，經過入參的不一樣，去覆蓋邏輯的不一樣 if else 這樣的分支，而後去確認函數的返回值是否與咱們預期的一致，代碼是否按預期執行，這就須要寫斷言，對於前兩個測試類型來講，這是最快，最便宜的實現方式。

能夠看到在金字塔中走的越高，創建咱們的測試所花費的時間和成本（越耗時，失敗時的信息越模糊，越難跟）就越多。這就是爲何許多項目傾向於專一於單元測試的緣由，由於它們能夠經過涵蓋大多數場景，省時省力的去測試咱們的代碼。

測試框架選型

Jest 表現強勁，在滿意度和使用度維度都有不錯的表現：

優秀的性能：對測試用例併發測試，只執行發生改變的文件所對應的測試，測試速度快；
集成度高：零配置，默認提供全部的東西，好比 Mock（幹掉 Sinon）、Test Runner（幹掉 Karma）、Matcher（幹掉 Chai）、Test Coverage（內置 istanbul）；
守護模式：注重開發者體驗，可以在編碼的時候幫助咱們快速得到測試結果的反饋；

先後端規約

現狀問題
隨着業務邏輯愈來愈複雜，先後端分工與協做不免會出現爭議，表如今：

存在必定的職責模糊地帶，好比數據格式拼裝、格式轉換等工做，便可以由前端來完成，又可由後端來完成，須要屢次溝通討論，溝通成本高；
先後端分離的模式下，先後端職責進行分工，致使開發溝通成本高，客戶體驗差（渲染速度慢，耗電高）等問題；

故制定此標準，意在明確先後端分工，減小溝通成本，減小開發維護成本，提高客戶體驗。

基本原則

後端按業務領域拆分接口，接口數據結構避免與 UI 展示耦合。前端應關注交互渲染邏輯，根據 UI 展示須要進行數據拼裝和轉換；
瀏覽器處理性能有限 (JS 單線程)，移動端續航能力有限，爲了保證流暢穩定的客戶體驗，在批量計算，排序，分頁等大數據量計算時應放到後端完成，後端返回最終結果，而非中間結果；
前端網絡環境複雜且不穩定 (2G/3G/4G/WIFI，進電梯等），應儘可能減小先後端網絡交互次數，單頁面網絡請求數量不建議大於 3 個；
在遇到對前端渲染速度要求極高，且後端接口數量及數據結構沒法知足要求時，可作 BFF 層（Backend For Frontend）進行接口適配或者採用服務端渲染 (SSR) 技術完成；
接口遵循最簡原則，屏蔽業務實現細節，避免無效字段，避免暴露過多的業務邏輯，避免冗餘的多級嵌套格式出現；

其餘具體的約定參考阿里的《Java 開發手冊》裏的先後端規約章節。

工程能力地圖

價值體現

工程能力地圖的價值：

規範研發和上線流程：需求、開發、准入、測試、部署與運行全流程的最佳實踐指導；
推薦工具鏈方案：全流程中推薦符合公司場景的最優工具；

YAPI平臺

價值體現
不管是前端仍是後端開發，都或多或少地被接口文檔折磨過。前端常常抱怨後端給的接口文檔與實際狀況不一致。後端又以爲編寫及維護接口文檔會耗費很多精力，常常來不及更新，隨着時間推移，版本迭代，接口文檔每每很容易跟不上代碼。
Swagger 提供了一套規範去定義接口及接口相關的信息，RD 只須要按照規範編寫描述文件，就能夠作到自動生成各類格式的接口文檔，生成多種語言的客戶端和服務端的代碼，以及在線接口調試頁面等等。

YAPI 對各角色同窗都有價值：

後端同窗實現「代碼即文檔」，簡化接口文檔維護；
前端同窗實時的，全自動的，更加真實的 Mock 數據，完成自動化部署服務，及自動聯調工具；
QA 同窗實現基於 Swagger 接口數據的契約測試，結合 ITP 平臺，實現自動生成契約測試；
對總體平臺的價值，主要體如今穩定性：後端同窗修改接口後，前端使用 Mock 數據，可及時發現接口變動，解決接口變動的流程溝通問題（溝通永遠是最高的成本）。

>期待你的加入

>百度開發者中心已開啓徵稿模式，歡迎開發者進入了不得的開發者活動進行投稿，優質文章將得到豐厚獎勵和推廣資源。