前言
随着越來越多的企業将雲計算産品應用到基礎設施及其核心業務中，如何提高和保證軟件交付質量、減少軟件開發疊代周期、加速軟件發布頻率成為所有雲廠商面臨的關鍵問題。
根據IDC 2018年的預測，中國雲計算市場在未來5年将持續高速發展的态勢，主要表現為：中國傳統的非雲計算IT基礎架構占整體IT基礎架構的投入比例将從2018年的50.3%下降到2022年的40.7%;中國私有雲平台建設的市場規模将以年均24.8%的複合增長率快速增長;中國雲計算IT基礎架構支出占全球市場比将從2018年的12%上升到2022年的25%，屆時中國私有雲IT基礎架構支出将超過美國，成為全球第一大市場。在這一輪新的疊代更新中，更多的企業和行業開始部署或者建立更大規模的私有雲;而新應用(數據分析，AI，IoT，移動)和新場景(邊緣計算，智慧/平安城市，行業雲)也對雲平台提出了更高的需求。
ZStack憑借創新的産品化理念，在業内率先提出雲計算的4S标準 – 簡單Simple，健壯Strong，彈性Scalable，智能Smart。同時，ZStack企業版從第一版發布到的3.5.0版本，一直以每六周一次的周期疊代更新軟件版本，快速提升和擴展産品功能，積極應對雲計算市場對私有雲産品不斷增長的需求。而保證其私有雲産品化的關鍵要素有以下三點：
1、 流程 – 快速敏捷
2、 運維 – 智能高效
3、測試 – 嚴謹全面
#FormatImgID_1#注：ZStack堅持快速、簡潔、高效的開發、運維、測試流程，确保新需求六周便可實現
1. 流程-快速敏捷
ZStack開發流程依然定義了傳統開發模式中的幾個關鍵階段 - FF、CF、RC和GA。同時針對不同階段的任務和目标，進行有的放矢地優化。在Feature Freeze階段，主要以需求分析為主，要求産品經理将客戶的需求分片化、分級化，需求描述本地化，更有效地将需求安排到不同發布版本周期中。開發和測試工程師則需要将Code Freeze和Release Candidate的任務提前到Feature Freeze階段中，減少互相之間任務的依賴，提高各個階段的并發度。而測試不僅需要滲透到開發的每個環節中，同時也要通過模型測試、路徑測試、穩定性測試等方法，提高代碼的覆蓋度和測試效率。每個發布周期通過反複地從需求->開發->測試的快速疊代，保證了産品的新需求和問題始終能夠被快速滿足和解決。
注：ZStack産品開發流程高度并發，保證版本之間快速疊代
2. 運維-智能高效
作為私有雲産品開發的基礎保證，一套快速、穩定、高并發、可伸縮的運維系統是必要的。而傳統運維提供的簡單CI和CD功能是顯然無法滿足這樣快速疊代的需求。ZStack産品化過程中，搭建了一套以ZStack + Kubernetes為基礎、面向公司各個部門的整體性服務框架。這套框架中所包括的服務内容涵蓋從開發&測試人員使用的測試環境、到整個項目的管理工具。框架的底層以ZStack作為IaaS提供給上層可靠的、可擴展的物理資源，同時結合Kubernetes，将容器運行于雲主機中，既保證了隔離性、又充分利用了ZStack和Kubernetes對雲主機和Docker調度的優勢，起到了對上層服務高可用、高并發及可伸縮的雙重保障。
注：ZStack作為IaaS層向上層服務提供可靠的物理資源，而更重要的是，内部的ZStack環境也會随着發布版本更新，真正做到了自己的産品自己先用起來。
注：實際生産環境中，一次自動化測試至少在Jenkins上并發創建500+個請求，每個請求包含10~50個測試用例，ZStack + Kubernetes保證了這些請求幾秒内可以被處理
3. 測試-嚴謹全面
打造一個産品化的私有雲軟件需要全面且嚴謹的測試，這不僅僅是單元測試和集成測試能保證的。ZStack從以下四個方面入手強化測試：
3.1 測試高效化：整個産品流程中開發和測試要同步進行，這包括了對不同的開發分支需要有不同深度的測試代碼保證其質量——例如，對于Release分支，必須有持續性的Nightly測試把控每天進入的代碼質量;對于Feature分支，需要能快速檢測出patch對代碼核心功能影響的BAT測試。同時測試系統和CI系統要高度集成并且做到同步觸發。
高效化的另一個重點就是要做到所有測試都能運行在雲端，提高測試的并發度和資源利用率。ZStack内部的測試都是跑在雲端的，而雲端環境也是基于ZStack自身搭建的，利用其對底層硬件資源的抽象和管理，模拟出測試中需要的不同的硬件配置場景，包括網絡、存儲、虛拟化平台、甚至不同的ZStack功能配置，如企業管理、災備服務等。同時，為了滿足大規模資源需求的測試場景，例如1萬台或10萬台雲主機的測試場景，ZStack測試中還實現了simulator機制，即不真實分配硬件資源，而使用mock後端API的方式提供了對後端資源的調配，真正做到了有針對性的測試。
注：ZStack雲端測試的環境構建是通過XML配置文件實現的，測試工程師可以非常簡單地用幾分鐘配置出一台自動化環境。
3.2 測試标準化：ZStack所涵蓋的測試内容不僅包括功能性測試，還包括一套完整測試體系所需要的各種測試，如開發工程師需要做的集成/單元測試，測試工程師需要做的系統測試中的壓力、性能、可靠性測試、以及針對不同版本定制的發布測試。例如ZStack的可靠性測試就包括了兩類測試 – MTBF和DPMO測試，MTBF會對ZStack平台進行15,000小時長時間的真實用戶操作模拟;DPMO測試則會對ZStack平台進行高達10,000次的斷/上電、重啟等測試。
标準化的另一方面體現在對關鍵節點的标準把控上，對FF、CF、RC和GA各個階段都會有相應的代碼準入和驗收标準，例如CF階段後功能開發代碼禁止進入發布分支而隻能進入下一個發布版本的周期;又例如各個階段驗收時要求的bug數量限制，CF階段要求小于5個P0，GA階段要求沒有P0的bug。
3.3 測試覆蓋智能化：軟件測試沒法達到的覆蓋率，所以我們要做的是在資源有限的情況下，以盡量少的代價做到盡可能高的覆蓋率。要提高覆蓋率，需從兩方面入手，一方面是對代碼進行覆蓋率檢查，我們在日常CI的包中插入了代碼不同模塊的覆蓋率，不管是手動還是自動測試，或是日常bug的驗證，都會為覆蓋率提供數據。
另一方面我們增加了模型測試，它可以産生由随機API組合構成的場景，會持續運行直到遇到預定義的退出條件或者找到一個缺陷。這種模型測試很好地彌補了人為定義用例的不足，提高了測試場景和路徑的覆蓋率。由這種測試模型，也衍生出了三種不同場景的覆蓋率提高測試：
3.3.1 覆蓋率測試：
除常規有序的測試步驟外，運用模型測試，收集無序測試步驟下的測試覆蓋率。
3.3.2 MTBF測試:
從有序和無序兩種測試維度，對系統穩定性及可靠性進行測試。
3.3.3 路徑測試
通常一個系統測試用例最多5~6個操作步驟，而最終客戶的問題場景是極其複雜的，通常需要10~20個以上的步驟才能重現，運用模型測試的方法，可以有效減少構建測試用例的代碼量。
注：一個典型路徑測試，隻需要将測試對象和操作步驟寫到測試用例中即可完成
3.4 報告立體化：主要從兩方面實現，一是測試報告的結果自動化、可讀化，是通過對測試用例中插入DITA描述實現的。另一方面是結果的可追溯和可回放，這是通過記錄測試過程中API的調用順序和參數實現的。
注：一個測試結果的操作記錄及回放方法，能夠有效幫助開發測試工程師重現bug
總結
作為産品化的雲計算公司，ZStack一直緻力于打造自研的ZStack私有雲、ZStack混合雲、ZStackMini超融合一體機、ZStack CMP多雲管理平台、ZStack企業級分布式存儲等産品和方案。本文從開發流程、基礎運維以及測試能效等角度，介紹了 ZStack 團隊如何高效打造一個産品化的私有雲。
免責聲明：本文僅代表作者個人觀點，與每日科技網無關。其原創性以及文中陳述文字和内容未經本站證實，對本文以及其中全部或者部分内容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考，并請自行核實相關内容。
本網站有部分内容均轉載自其它媒體，轉載目的在于傳遞更多信息，并不代表本網贊同其觀點和對其真實性負責，若因作品内容、知識産權、版權和其他問題，請及時提供相關證明等材料并與我們聯系，本網站将在規定時間内給予删除等相關處理.
