持續交付中流水線構建完成後就大功告成了嗎？別忘了質量保障

上期文章我結合自己的實踐經驗，介紹了持續交付中流水線模式的軟體構建，以及在構建過程中的3個關鍵問題。我們可以看出，流水線的軟體構建過程相對精簡、獨立，只做編譯和打包兩個動作。

但需要明確的是，在持續交付過程中，我們還要做很多與質量保障相關的工作，比如我們前面提到的各類功能測試和非功能測試。

所以，今天我們聊一聊在流水線構建過程中或構建完成之後，在質量保障和穩定性保障方面，我們還需要做哪些事情。

首先，我們回顧一下之前總結的這張流程圖：

可以看出，在流水線構建過程中，我們尤其要重視以下3個方面的工作內容。

依賴規則限制

主要是對程式碼依賴的二方包和三方包做一些規則限制。比如，嚴格限定不允許依賴snapshot版本；不允許引入有嚴重漏洞的版本，如struts2的部分版本；檢測jar包衝突，如我們常用的netty、spring相關的包；限定某些軟體包的最低版本釋出，如內部提供的二方包，以確保版本收斂，降低維護成本。

過濾規則上，通過maven構建軟體包過程中生成的dependency:list檔案，將GroupID和ArtifactID作為關鍵字，與我們設定的版本限制規則進行匹配。

兩個示例如下（真實版本資訊做了修改）：

• 檢測jar包衝突：

  [WARNING] 檢測到jar包衝突: io.netty:netty-all, 版本: 4.0.88.Final, 當前使用:
  4.0.22.Final
  

• 限定最低版本：

  [WARNING] 檢測到 mysql:mysql-connector-java, 版本 5.0.22, 版本不符合要求, 需要大於等於
  5.0.88 。舊版存在已知相容性bug，導致連不上資料庫, 請在2018-01-15 00:00:00前升級完成, 否則將被禁止釋出，如有疑問，請聯絡@釋出助手
   
  

jar包依賴以及維護升級，通常是一件令我們比較頭疼的事情，特別是在執行時出現的衝突異常，更是災難性的。為了從技術角度更好地進行管理，我們需要做好隔離，這一點可以利用JVM類載入機制來實現。

如果你有興趣，可以在網上參考阿里的潘多拉（Pandora）容器設計資料，這裡我們就不作詳細介紹了。

功能測試

包括單元測試、介面測試、聯調測試和整合測試。這裡的每個測試環節起到的作用不同，聯調測試和整合測試依賴的主要手段還是手工驗證，所以這裡我們分享下可以通過自動化手段完成的單元測試和介面測試。

這裡主要用到的幾個工具：

• JUnit 和TestNG，分別做單元測試和介面測試；
• Maven外掛，maven-surefre-plugin，用來執行JUnit或TestNG用例；
• JaCoCo，分析單元測試和介面測試後的程式碼覆蓋率；
• Jenkins，自動化測試任務執行，報表生成和輸出，與Maven、JUnit、Gitlab這些工具結合非常好。

關於上述這幾種工具，我在此就不展開詳細介紹了，你可以自行上網查詢和學習。

下面，我們分析一下功能測試中的兩個重要環節：單元測試和介面測試。

• 單元測試，由開發完成測試用例的開發，對於需要連線DB的用例，可以用DBUnit這樣的框架。用例的自動執行，每次程式碼開發完成，開發執行mvn test在本地進行自測通過，然後提交到Gitlab。可以在Gitlab中設定hook鉤子，和回撥地址，提交的時候在commitMsg增加鉤子標識，如unitTest，這樣提交後就觸發回撥自動化單元測試用例執行介面，確保提交後的程式碼是單元測試通過的，最終可以通過JaCoCo工具輸出成功率和程式碼覆蓋率情況。
• 介面測試，用例編寫上使用TestNG，這個測試框架相比JUnit功能更全面，也更靈活一些。但是過程上與單元測試類似，當然也可以不通過hook方式出發，可以通過手工觸發進行測試。

上述自動化測試環節結束，軟體包就可以釋出到我們之前說的專案測試環境或整合測試環境進行功能聯調和測試了，這時就需要部分人工的介入。

非功能測試

在功能驗證的同時，還需要並行進行一些非功能性驗證，包括安全審計、效能測試和容量評估。分別介紹如下：

• 安全審計，由安全團隊提供的原始碼掃描工具，在構建的同時，對原始碼進行安全掃描，支援Java和PHP語言。可以對原始碼中的跨站指令碼、偽造請求、SQL注入、使用者名稱密碼等敏感資訊洩露、木馬以及各類遠端執行等常見漏洞進行識別，對於高危漏洞，一旦發現，是不允許構建出的軟體包釋出的。而且實際情況是，不審不知道，一審嚇一跳，我們前面幾次做程式碼掃描時，各種漏洞觸目驚心，但是隨著工具的支援和逐步改進，基本已經將這些常見漏洞消滅在萌芽狀態。

下面是掃描結果的簡單示例（目前掃描工具已經開源，請見文末連結）：

• 效能和容量壓測，主要針對核心應用，進行釋出前後的效能和容量比對，如果出現效能或容量差異較大，就會終止釋出。關於這一點，我在後面穩定性保障的文章中會詳細介紹到。這個驗證工作，會在預發或Beta環境下進行驗證，因為這兩個環境是最接近線上真實環境的。

下圖是一張釋出前後的效果比對示意圖，正常情況下，效能曲線應該是基本重疊才對，不應該出現較大的偏差。

最後到這裡，我們稍作一個總結。
關於持續交付中的流水線模式，我們在前面兩期文章以及本期的分享中，相對完整地介紹了從需求分解開始，到程式碼提交、軟體構建，再到功能和非功能測試驗證的整個過程。這個過程就是我們常說的持續整合。

之所以我沒有在一開始引入這個概念，是因為，如果我們將注意力集中到這一過程中具體的動作和問題上，會更有利於我們理解，而不是一開始就被概念性的術語和框架束縛住。

流水線模式功能測試和非功能測試的整個過程可以總結如下：

同時，我們在上面持續整合的過程中，要基於前面介紹的各類環境和基礎配置管理，比如功能驗證就需要線上下環境中的開發環境、專案環境以及整合測試環境上進行驗收。

而非功能驗證的效能和容量評估，就需要在線上環境裡的預發或beta環境中完成。這裡就已經涉及到了軟體的部署釋出。

下一期文章，我將分享線上釋出的整個過程，並對整個持續交付體系內容做一個收尾。歡迎你留言與我討論。

附：原始碼安全審計工具https://github.com/wufeifei/cobra