如何構建高效可信的持續交付能力，華爲雲有絕活！

摘要：持續交付的最終目的是高效和可信二者的結合。

1、高效可信的持續交付

1.1 軟件研發的目的

持續交付是一個你們平時提得比較多的話題，高效是持續交付的目的，具體到華爲雲的場景下，持續交付的最終目的是高效和可信二者的結合。

整體而言，軟件研發的目的是持續而且快速地交付高質量的有價值的軟件給客戶。首先研發是一個快速且持續交付的過程；其次研發是面向客戶的，交付的軟件必須是對客戶而言高質量且有價值的，而質量是多方位多維度的，其衡量標準除了價值之外，還包括穩定性、安全性、可靠性、可擴展性等。

1.2 軟件生命週期

從軟件生命週期管理的全過程來看，產品的idea產生後，進入開發，而後到部署發佈，最後到運維，這是一個端到端的完整的流程，每一個環節缺一不可。

• 開發環節，會有針對性地作各類測試，包括靜態測試、動態測試、黑盒測試、白盒測試、灰盒測試等，這些測試會在不一樣的環境之上分層進行，由不一樣的角色去承載；
• 發佈環節包括對在製品的管理，發佈什麼是由前端的發佈計劃決定的；
• 每一個環節都有部署的動做，自動化部署的過程會銜接前端的開發過程。

往深一層：

• 整個前端更多的是創新的過程，在這個過程當中能夠看到不少方法論，好比設計思惟、精益創業、數字化轉型等，這裏的創新表明的是業務側的訴求，傳統業務須要經過新的方法、新的技術來實現賦能和轉型；
• 創新的idea落到研發環節去實現，開發部署發佈有CI/CD進行支撐；
• 最後到運維和運營，不僅是上線後須要運營，像如今服務類的產品都講究雲化，既然是一個service，就須要對service構建整套面向用戶、面向內容、面向產品的運營體系。

回到業務側，將上述從產品到研發的流程映射到整個產品生命週期。

• 偏前端的階段是增值類的，產品創新是有價值的，寫的代碼也是有價值的；
• 而偏後端的階段則是非增值的，好比測試，對最終客戶來講是必要但不增值的。

增值的部分，咱們追求的是最終的效果；非增值的部分，咱們追求的是效率，即我要高效地完成這個過程，以便於達到最後的結果。

要經過過程來保證效果，所以過程也是必不可少的。但在這些過程當中有不少工做是重複的，好比測試、部署，咱們須要經過自動化的方式去賦能。這就是咱們一般講的DevOps的意義，經過自動化的流程和工具，讓機器去完成重複性的工做。

觀全貌咱們不難發現，在整個軟件/產品生命週期，質量經過逐層的測試、驗證、反饋等貫穿始終。另外，其中也包括大量安全類的活動，好比在產品創新階段要考慮安全性的訴求；在開發過程經過黑盒、白盒、靜態、動態等測試保證安全。

最後落到可信的層面，華爲整個研發體系服務於總體的業務訴求，你們都知道，華爲處於通訊行業，通訊是一個關乎國計民生的領域，對安全的要求很是高，提供的產品和服務必須可靠可信，所以咱們作了不少可信工程的設計。

2、可信工程

2.1 華爲軟件工程建設歷程

自上世紀四五十年代起，開始有了第一臺大型計算機，軟件工程也隨之興起並發展至今。華爲成立於1987年，最開始是單兵做業或小團隊做業的方式，後來隨着業務的增加團隊規模不斷擴大，如何支撐大規模集團軍做業？爲解決這一問題，咱們開始引入IPD，由此進入IPD1.0時代。隨着互聯網技術的發展，有了敏捷開發、CMMI、DevOps持續交付、雲原生等方法論和實踐，咱們將這些優秀的方法論和實踐合併到IPD1.0的框架中，使之更靈活地適應實際的軟件研發需求。

2019年起，咱們開始作IPD2.0，其中一個很是關鍵的點是可信。

2.2 何爲「可信」

咱們先來給「可信」下個定義。

可信是每一個系統在業務意圖以外同時具備韌性、Security安全性、隱私性、Safety安全性、可靠性、可用性六個特徵的肯定性程度。

也就是說，每一個系統在業務意圖（即功能性訴求）以外，還須要同時具有6個特性：

• 韌性，服務宕機是否可以自動拉起來？系統可否經受得住大規模併發衝擊？
• 安全性，這裏有兩個單詞表明安全性特質：Security和Safety。其中Security側重數據安全、信息安全，Safety側重環境安全等。
• 除此之外，還須要考慮隱私性、可靠性、可用性等特質。

華爲的可信工程將這6個特性做爲基本的訴求，再關聯業務意圖，高效地完成業務目標，帶給客戶價值的同時兼顧可信。

2.3 可信價值流框架

若是你們瞭解精益等實踐，就知道研發其實是一個價值流交付的過程。那麼，可信價值流框架是什麼樣的呢？可信價值流框架是產品生命週期端到端的過程，以終爲始，咱們要的是結果安全、結果可信、過程可信，即咱們經過過程的可信達到結果可信賴、可依賴、安全的目標。

將整個產品生命週期進行拆解：

• 在安全治理層面，咱們須要有可信治理，包括可信要求、責任和權利、分層級治理、人才和文化等；
• 在過程可信層面，要有相關的肯定性預防、肯定性應對、機密性、完整性、一致性和雙向可跟蹤性、風險管理等，在過程當中作到總體把控；
• 最後到結果可信層面，包括前文提到的6個特性。

再細化下來，又涉及到產品定義階段、產品實現階段、產品預發佈階段、產品使用階段等，每一個階段都在傳統軟件工程的基礎之上，加入具體的動做去知足總體可信的要求。好比，產品定義階段，在規劃和設計中考慮可信訴求；產品實現階段，考慮編碼是否安全、編譯是否屢次可用，交付給不一樣客戶的軟件包是否正確，測試是否可重複……在產品預發佈和使用階段也會有不少相應的策略實現可信。

技術層面，咱們經過使用建模和仿真技術、密碼學的加解密協議、操做系統可信等技術使能可信。

這是一條完整的經過過程可信達到結果可信的路徑，最終咱們經過各級度量進行持續改進。

2.4 華爲雲HE2E DevOps框架v2.0

華爲雲集合業界先進理念和華爲30年研發經驗，總結出一套可操做可落地的端到端一站式開發方法論和工具鏈——華爲雲HE2E DevOps框架。

• 首先，它是端到端的DevOps開發框架，包括從規劃設計到迭代開發到持續測試再到持續交付的全過程。咱們認爲僅僅只作好工程端不足以支撐整個業務，必定要延伸並回歸到業務側，實現端到端的閉環。
• 其次，它的整個過程融合了大量以可信爲目的的手段，去支撐整個DevOps流程。

華爲雲HE2E DevOps自2018年發佈1.0版本，到今年發展爲2.0版本。華爲雲HE2E DevOps框架v2.0總體分爲6大階段：規劃與設計、開發與集成、測試與反饋、安全與審計、部署與發佈、運維與監控。本文將着重介紹工程端的內容，包括開發與集成、測試與反饋、安全與審計、部署與發佈。

3、開發與集成

3.1 CloudNative實踐

雲的服務自己就是生於雲長於雲的，所以咱們一直在作CloudNative實踐，在架構、工程交付、全功能團隊、雲環境四部分不斷優化，持續提高質量。

• 架構優化，架構總體進行微服務改造，統一微服務框架到SpringCloud裏，進行業務拆分架構解耦，輕量級通訊。
• 全功能團隊，架構拆分後，團隊須要根據架構作相應的驗收和匹配。咱們試點服務化全功能團隊，單個Service由2-Pizza小團隊對開發、測試、部署上線、運維端到端負責。
• 工程交付，踐行DevOps交付模式，構建端到端交付流水線，微服務獨立開發、構建、測試、部署、發佈、現網運維。
• 研發全雲化，依賴研發雲I層和P層資源和成熟基礎服務，基於華爲雲打造雲化服務工具鏈和環境。

3.2 Cloud Native能力構建鐵三角

從以上4個方面咱們不可貴出構建雲原生的Cloud Native能力必不可少的鐵三角：架構、組織、工程，我認爲中間還應該加上價值交付。回到最初那句話：研發的目的是持續而且快速的交付高質量的有價值的軟件給客戶。

1）架構層面

• 採用服務化架構/微服務架構實現全面解耦。把系統劃分爲多個功能內聚、粒度合適、業務邊界清晰、獨立自治的服務/微服務。
• 使用自服務、敏捷的雲化基礎設施服務。依賴底層雲化基礎設施的服務提供運行資源，使用雲監控服務監控自身運行狀態，同時根據運行狀態出發運維事件，實現彈性伸縮、故障自愈等。
• 經過API重用雲原生公共服務提供的基礎能力和架構能力。無論內部仍是外部的服務之間，均可以經過API的方式自動生成相關接口和用例，來進行構建和定義，包括數字化轉型裏的開放平臺、開放銀行等都是經過API來進行支撐。如今比較流行的說法「API經濟」能夠了解一下，此處不展開。

2）工程層面

• 系統與環境、流程、配置解耦，人員團隊之間也進行相應的解耦與匹配。
• DevOps，運維和開發相互融合，高度協同，共擔職責。
• 實踐極速迭代，持續交付，快速相應業務變化，縮短TTM。

3）組織層面

• 全功能團隊，團隊中包括產品、架構、設計、開發、測試、運維等角色，吃本身的狗糧，本身的產品必定要本身去上線發佈和維護，每一個人輪崗去負責發佈的過程，這樣全部人都知道產品上線發佈的流程。這樣作有幾個好處：技能的相互傳遞、打造全棧，不會依賴於某一個角色。
• 雲化運維團隊，基於雲平臺提供的監控、報警等能力，成立專門的團隊負責系統運行時的質量，保證系統可用性和業務無中斷的升級、回滾。運維團隊更多的是構建工具平臺和流程，進行賦能。

3.3微服務化目標

• 系統解耦，功能內聚，提高需求交付效率。經過業務的拆解和解耦，讓系統敏捷起來。
• 踐行API First。經過服務化，讓服務提供者和消費者之間經過微服務API創建契約。
• 低成本可伸縮架構。可靈活進行水平、橫向擴展，平滑上雲，架構上支撐應用市場業務的快速發展。
• 服務自治。經過在線的微服務治理結合雲平臺，實現微服務的彈性伸縮、熔斷降級等。
• 探索一體化服務團隊。創建2-Pizza Team，經過全功能團隊的建設，讓業務真正敏捷起來。

3.4微服務實踐 - 頂層統一設計

總結起來是：大兵團做戰，頂層設計，統一認識，組織賦能。角色上分爲研發&運維團隊、設計&開發&測試骨幹、架構師，每一個角色要作什麼，經過培訓和賦能的方式來進行定義和支撐。

3.5 微服務12設計原則

咱們有一套一站式的微服務管理平臺來支撐微服務的12設計原則。

3.6 Clean Code

1）Clean Code機制

業界一致認爲，編寫Clean Code能有效減小漏洞，下降系統脆弱性，是實現軟件可信的重要舉措。咱們內部也很是強調Clean Code（代碼整潔），創建起一整套完整、具有快速反饋能力、可持續生成好代碼的機制。

華爲有本身的Clean Code定義和文化。經過Committer機制、門禁機制、代碼極致共享等作相關過程的支撐，經過開發者測試對總體質量進行把控；並創建三層模型和六級標準，支撐實時代碼評估、版本交付階段性評估和產品長期演進的年度評估。

2）Clean Code評估

業界Clean Code評估標準是：高效、可移植、安全、簡介、可靠、可測試。華爲持續對業界最新標準進行有效的代碼評估，並結合實踐創建了三層質量模型和六級質量評分標準。

關鍵舉措包括：建設分級標準，咱們會對不一樣系統進行評級；開發可視化工具；創建按期評估指導場景；持續對標業界刷新評估模型。

3.7 華爲Committer工程實踐

Committer來源於開源社區，你們都知道開源社區的協做模式是分佈在全球各地的開發者以協同貢獻的方式進行開發，代碼貢獻者的能力、水平、責任心等良莠不齊，所以必須在代碼入庫以前進行Committer評審以保證質量。華爲內部也有開源的機制，借鑑這一實踐，造成本身的Committer機制。

華爲的Committer機制其實是一套流程來保證總體的代碼質量，包括三個角色：

• Developer，負責建立本地代碼分支、本地開發、開發自檢與測試等工做；
• Reviewer，負責對代碼進行檢視；
• Committer，負責作最後的質量把關。

底層經過IT基礎設施來保證編譯部署、測試等過程，經過自動化工具使能，減輕評審的重複勞動。

整個Committer流程由幾個核心點：

• 代碼的開發、提交與合入權限應要分離，以免攻擊者冒用員工權限植入惡意代碼；
• 經過檢視和審覈的意見對工程師進行輔導提高團隊軟件能力。
• 入庫審覈還能反向驅動前端代碼檢視提高，促進Developer具有編寫Clean Code的能力。

4、測試與反饋

4.1 華爲雲全場景測試服務框架

華爲雲全場景測試服務框架提供一站式端到端測試自動化智能化解決方案，爲企業構建測試中臺，提高企業測試專業度及測試效能。整個測試框架分爲三大塊：測試設計、設計執行、測試分析，包括測試設計、測試用例管理、服務接口測試、WebUI測試、終端測試、性能測試、安全測試、導流測試、在線測試及測試分析報告等功能。底層有一套完整的測試管理平臺來支撐。

全場景測試服務有3個要點：

• Test Left，測試左移。在研發或產品生命週期的早期階段就能夠介入和開展測試，而且測試的工做不是隻由測試人員來承擔，也就是說測試是一個活動，而不是一個獨立的角色。
• Automate Everything：儘量多自動化。在業務早期階段，快速構建起來作一些驗證，全部這些測試用例逐漸都要變成自動化的方式，這樣才能重複性地、一遍一遍地支撐業務快速交付的過程。
• Test Right，測試右移。類生產環境始終不是真正的生產環境，沒辦法模擬全部生產環境的場景，咱們還須要開展大量的線上測試。

全流程測試，每一個階段都有對應的測試動做：開發環節有驗收測試、單元測試、功能測試、coding裏的代碼質量把控也是測試；測試環節有迴歸測試、集成測試、性能測試、安全合規類測試等；部署環節有A/B測試、在線上環境和生產環境作一些複雜測試，還包括吃本身的狗糧等。

整個測試會分三級進行，分別是我的級、服務級、產品級。每級的流水線都會涉及到質量活動，流水線也會分層分級：

• 我的級流水線的質量活動是從本地開發環境到Alpha環境，包括代碼檢查單元測試、編譯構建、安全掃描、接口測試等，而後經過分支合併到Beta環境；
• 服務級流水線的質量活動是從Beta環境到Gamma環境，除了上述測試之外，還須要跑老特性迴歸測試、瀏覽器兼容性測試、性能測試等；
• 產品級流水線的質量活動是從Gamma環境到生產環境，本層級須要加入專項測試，好比產品級性能測試、可靠性測試、長穩測試、安全測試等。

4.2 微服務交付過程持續開展質量活動

在微服務交付過程當中有不一樣的環境，好比Alpha環境、Beta環境、Gamma環境等，每一個環節有相關的質量檢查門禁和驗收標準，以及現網的質量活動。這些質量活動由不一樣的角色來承擔：

• 前端設計階段，參與的主要是架構師和開發工程師；
• 開發過程主要由開發工程師來承擔，架構師也會承擔開發的工做，但他作得更多的是關鍵的跨服務之間的設計和開發；
• 發佈階段，開發工程師執行發佈的動做，測試工程師會從端到端進行質量把控，並對開發工程師進行支撐和賦能。
• 生產環境，開發工程師和運維工程師一塊兒對系統進行支撐，測試工程師會作一些現網測試、導流測試、混沌測試等。

4.3 測試度量指標體系

除了流程之外，咱們還會有一些質量定義和度量標準。測試度量標準整體分爲兩類：過程指標和結果指標。過程度量包括：覆蓋率、執行率、測試效率等；結果度量包括：功能測試、性能測試、安全測試、可靠性測試等。

5、安全與審計

5.1 DevSecOps的價值和實踐

安全和可信直接相關，說到可信，你們天然會聯想到安全。權衡DevOps速度與現有安全要求的需求，催生了一個名爲DevSecOps的模型。

什麼是DevSecOps？DevSecOps基於「安全問題，人人有責」的原則，它強調應用程序開發人員能夠怎樣把安全檢查與他們的集成和部署流水線構建到一塊兒。簡單來講，就是把安全層面的活動滲入到DevOps開發過程的各個環節中。 在華爲雲的實踐中，咱們更關注在軟件開發過程當中植入安全活動保證軟件生產的可信可靠和穩定。

5.2 華爲企業級安全工程實踐

一樣從軟件生命週期來看，華爲企業級安全工程實踐基於DevOps流水線，在計劃、編碼與構建、驗證、發佈與運維運營等每一個階段都有相應的安全考覈點和實踐介入，底層會有標準和規範、技術和能力、工具和流程來支撐，全流程保障網絡安全，實現安全設計、安全編碼、安全測試、安全運維。

5.3 CodeCheck安全

華爲內部自研了一個工具：CodeCheck，以應對嚴苛的安全要求，保證總體代碼質量和安全。咱們分別從能力、效率和生態運營來看CodeCheck。

• 能力上對應三個級別：桌面級-編碼開發環節，嵌入IDE，編碼時執行快速檢查；我的門禁級-代碼提交入庫時，提供入庫門禁和規則集，快速檢查；版本級-持續集成、持續交付的過程當中，提供全量檢查、告警閉環處理工程化能力。
• 效率上，前端桌面級和我的門禁級可作到秒級至分鐘級標準；到了線上環節，由於要跑的環節很是多，因此是小時級。
• 生態運營上，咱們的工具是對內作服務，對外作客戶支撐。

5.4 安全規則

咱們的安全規則來源於兩個層面：

• 外部視角：借鑑外部的規則，將業界的標準和最佳實踐沉澱下來，變成安全編碼的知識庫和規則集。
• 內部視角：華爲內部有大量的產品線和產品形態，咱們定義出TOP10的質量和安全問題，將長期場景梳理和安全檢查的經驗積累成規則。

業界常常說起的靜態分析安全測試（SAST）包括四層：編譯、構建、語法分析、語義分析，安全檢查涉及的技術棧明顯更深，華爲提供全棧能力、多語言支持，支持深刻的語義分析能力。若是把質量和安全結合到一塊兒，須要一些規則和引擎來支撐，還須要引入一些智能化的手段，自動檢查、自動修復。

華爲內部將規則集分爲三層：公司級、產品線級、產品級/版本級/工程級。公司級規則集包括強制規則集，好比低誤報，默認必須掃除，而檢視規則集則可根據須要勾選；產品線級規則集和產品級規則集，產品線管理員配置爲強制要求，其他的規則集可根據產品特性進行選擇。

整個工具不只僅是簡單的安裝+運行，而是一個MN矩陣式的運營體系。從規則定義上來說，有公司級、產品線級、產品級等不一樣層級的規則；從時間週期上看，哪些規則放在開發者桌面IDE裏、哪些規則要放在流水線裏、哪些規則要放在版本構建裏，都有一個設計的過程。

5.5 企業級專家服務

在安全層面，咱們提供了企業級專家服務，其服務策略相似於醫院看診。普通「發燒感冒」的診治，提供基礎服務；針對「大病重症」，提供專業的自動化檢查能力及工程配套能力；針對「疑難雜症」，提供顧問式專家服務。

6、部署與發佈

6.1 持續交付核心實踐

持續交付的過程是和持續開發與集成、自動化測試等關聯在一塊兒的。好比分層快速閉環，在測試的時候就會分不一樣的層級去執行，分層的目的是爲了快速反饋和閉環。

持續交付的核心實踐除分層快速閉環外，還包括：小迭代高節奏交付、自動化&可視化流水線、自動化持續部署、縮短單點耗時、高效標準化環境等。

6.2 發佈的分支模型和CI/CD流水線

自動化部署的背後是標準化環境，須要代碼的分支結構和總體的CI/CD流水線有很好的匹配和映射關係。

咱們從代碼主幹上拉出來一個代碼分支，在上面作相關的開發，提交後自動拉起來一個CI流水線，對代碼進行靜態檢查和自動化構建，包括部署包準備、代碼合併等，最終經過我的級別的流水線後，跑到生產環境上，整個過程都是和CI/CD流水線關聯在一塊兒的。

6.3 可信Built-In的流水線

咱們把可信的概念內建到整個流水線裏，自動化檢查、驗證，過程當中獲取反饋，支持實現CI/CD過程的高效可信。

若是代碼層面是可信的，到編譯構建的時候，能夠可重複地高效地構建出來；同時，測試活動中也會加入可信相關的檢查點；到上線後，Chaos Monkey等實踐也都是跟可信直接相關的，好比咱們常常強調的彈性、穩定性等。

6.4 Everything as Code 一切皆代碼

可能有人會問：怎麼防範個人環境裏被人植入漏洞？其實環境也好、過程也好，均可以代碼化，代碼化後就能夠把它歸入到整個版本管控中，這樣的話全部的修改和變動均可以自動化，也能夠針對這些環境和過程進行安全審計。

咱們稱之爲Everything as Code 一切皆代碼。除了基礎設施之外，編排、配置、測試、數據庫、流水線、代碼均可以這種方式呈現出來，這樣就能夠實現版本化、自動化和標準化。再往上到Service也如此，Service as Code實際上就是咱們想要強調的API。

6.5 灰度發佈策略驅動自動化部署與回滾

在發佈的時候，咱們會有各級發佈的機制。首先咱們會作一級的灰度發佈，找一些重點MVP客戶，或者內部使用者，發佈給自用環境；沒問題的話再進行二級灰度，這時會適度擴大範圍，開放給全網10%左右的用戶；而後再作三級灰度；最後纔是全量發佈。

在這個過程當中，一旦任何一級出現問題，立刻就能夠進行修復和回滾。同時咱們會作一些在線導流測試，結合AB測試進行業務層面的探索，咱們一直強調經過技術的手段賦能業務。

7、總結

以上介紹的是華爲雲的DevOps體系，其核心除了一般咱們所說的「高效」、「持續交付」之外，更重要的一點是「可信」。咱們將這一體系稱爲「雲與安生時代的DevOps體系框架」。

頂層是商業決策，咱們會持續規劃、按期審視，固定節奏對其進行相應調整；往下是服務化組織、架構解耦，開發&運維落地；再往下是工具、環境支撐；最底下是服務流程支撐。

如何去構建這樣一套體系？咱們要始終圍繞總體的研發效率目標，選擇應用相關的研發工具，以工具承載新型能力，支撐高效做業、持續交付、高效協同、智能化輔助開發、持續反饋與改進，進而構建整個的持續交付能力。

——————————————————————————————————————

內容來源：【2020 CSDI SUMMIT中國軟件研發管理行業技術峯會】分享實錄，原文首發於「百林哲」。做者：姚冬

嘉賓簡介：華爲雲應用平臺部首席技術解決方案架構師，資深DevOps與精益/敏捷專家，華爲雲享專家，中國DevOps社區核心組織者，IDCF（國際DevOps教練聯合會）發起人

 

點擊關注，第一時間瞭解華爲雲新鮮技術~