如何构建高效可信的持续交付能力，华为云有绝活！
摘要：持續(xù)交付的最終目的是高效和可信兩者的結合。
一、高效可信的持續(xù)交付
1.1 軟件研發(fā)的目的
持續(xù)交付是一個大家平時提得比較多的話題，高效是持續(xù)交付的目的，具體到華為云的場景下，持續(xù)交付的最終目的是高效和可信兩者的結合。
總體而言，軟件研發(fā)的目的是持續(xù)并且快速地交付高質量的有價值的軟件給客戶。首先研發(fā)是一個快速且持續(xù)交付的過程；其次研發(fā)是面向客戶的，交付的軟件必須是對客戶而言高質量且有價值的，而質量是多方位多維度的，其衡量標準除了價值以外，還包括穩(wěn)定性、安全性、可靠性、可擴展性等。
1.2 軟件生命周期
從軟件生命周期管理的全過程來看，產(chǎn)品的idea產(chǎn)生后，進入開發(fā)，然后到部署發(fā)布，最后到運維，這是一個端到端的完整的流程，每個環(huán)節(jié)缺一不可。
開發(fā)環(huán)節(jié)，會有針對性地做各種測試，包括靜態(tài)測試、動態(tài)測試、黑盒測試、白盒測試、灰盒測試等，這些測試會在不同的環(huán)境之上分層進行，由不同的角色去承載；
發(fā)布環(huán)節(jié)包括對在制品的管理，發(fā)布什么是由前端的發(fā)布計劃決定的；
每個環(huán)節(jié)都有部署的動作，自動化部署的過程會銜接前端的開發(fā)過程。
往深一層：
整個前端更多的是創(chuàng)新的過程，在這個過程中可以看到很多方法論，比如設計思維、精益創(chuàng)業(yè)、數(shù)字化轉型等，這里的創(chuàng)新代表的是業(yè)務側的訴求，傳統(tǒng)業(yè)務需要通過新的方法、新的技術來實現(xiàn)賦能和轉型；
創(chuàng)新的idea落到研發(fā)環(huán)節(jié)去實現(xiàn)，開發(fā)部署發(fā)布有CI/CD進行支撐；
最后到運維和運營，不只是上線后需要運營，像現(xiàn)在服務類的產(chǎn)品都講究云化，既然是一個service，就需要對service構建整套面向用戶、面向內容、面向產(chǎn)品的運營體系。
回到業(yè)務側，將上述從產(chǎn)品到研發(fā)的流程映射到整個產(chǎn)品生命周期。
偏前端的階段是增值類的，產(chǎn)品創(chuàng)新是有價值的，寫的代碼也是有價值的；
而偏后端的階段則是非增值的，比如測試，對最終客戶來說是必要但不增值的。
增值的部分，我們追求的是最終的效果；非增值的部分，我們追求的是效率，即我要高效地完成這個過程，以便于達到最后的結果。
要通過過程來保證效果，因此過程也是必不可少的。但在這些過程中有很多工作是重復的，比如測試、部署，我們需要通過自動化的方式去賦能。這就是我們通常講的DevOps的意義，通過自動化的流程和工具，讓機器去完成重復性的工作。
觀全貌我們不難發(fā)現(xiàn)，在整個軟件/產(chǎn)品生命周期，質量通過逐層的測試、驗證、反饋等貫穿始終。另外，其中也包括大量安全類的活動，比如在產(chǎn)品創(chuàng)新階段要考慮安全性的訴求；在開發(fā)過程通過黑盒、白盒、靜態(tài)、動態(tài)等測試保證安全。
最后落到可信的層面，華為整個研發(fā)體系服務于整體的業(yè)務訴求，大家都知道，華為處于通信行業(yè)，通信是一個關乎國計民生的領域，對安全的要求非常高，提供的產(chǎn)品和服務必須可靠可信，因此我們做了很多可信工程的設計。
二、可信工程
2.1 華為軟件工程建設歷程
自上世紀四五十年代起，開始有了第一臺大型計算機，軟件工程也隨之興起并發(fā)展至今。華為成立于1987年，最開始是單兵作業(yè)或小團隊作業(yè)的方式，后來隨著業(yè)務的增長團隊規(guī)模不斷擴大，如何支撐大規(guī)模集團軍作業(yè)？為解決這一問題，我們開始引入IPD，由此進入IPD1.0時代。隨著互聯(lián)網(wǎng)技術的發(fā)展，有了敏捷開發(fā)、CMMI、DevOps持續(xù)交付、云原生等方法論和實踐，我們將這些優(yōu)秀的方法論和實踐合并到IPD1.0的框架中，使之更靈活地適應實際的軟件研發(fā)需求。
2019年起，我們開始做IPD2.0，其中一個非常關鍵的點是可信。
2.2 何為“可信”
我們先來給“可信”下個定義。
可信是每個系統(tǒng)在業(yè)務意圖之外同時具有韌性、Security安全性、隱私性、Safety安全性、可靠性、可用性六個特征的確定性程度。
也就是說，每個系統(tǒng)在業(yè)務意圖（即功能性訴求）之外，還需要同時具備6個特性：
韌性，服務宕機是否能夠自動拉起來？系統(tǒng)能否經(jīng)受得住大規(guī)模并發(fā)沖擊？
安全性，這里有兩個單詞代表安全性特質：Security和Safety。其中Security側重數(shù)據(jù)安全、信息安全，Safety側重環(huán)境安全等。
除此以外，還需要考慮隱私性、可靠性、可用性等特質。
華為的可信工程將這6個特性作為基本的訴求，再關聯(lián)業(yè)務意圖，高效地完成業(yè)務目標，帶給客戶價值的同時兼顧可信。
2.3 可信價值流框架
如果大家了解精益等實踐，就知道研發(fā)實際上是一個價值流交付的過程。那么，可信價值流框架是什么樣的呢？可信價值流框架是產(chǎn)品生命周期端到端的過程，以終為始，我們要的是結果安全、結果可信、過程可信，即我們通過過程的可信達到結果可信賴、可依賴、安全的目標。
將整個產(chǎn)品生命周期進行拆解：
在安全治理層面，我們需要有可信治理，包括可信要求、責任和權利、分層級治理、人才和文化等；
在過程可信層面，要有相關的確定性預防、確定性應對、機密性、完整性、一致性和雙向可跟蹤性、風險管理等，在過程中做到整體把控；
最后到結果可信層面，包括前文提到的6個特性。
再細化下來，又涉及到產(chǎn)品定義階段、產(chǎn)品實現(xiàn)階段、產(chǎn)品預發(fā)布階段、產(chǎn)品使用階段等，每個階段都在傳統(tǒng)軟件工程的基礎之上，加入具體的動作去滿足整體可信的要求。比如，產(chǎn)品定義階段，在規(guī)劃和設計中考慮可信訴求；產(chǎn)品實現(xiàn)階段，考慮編碼是否安全、編譯是否多次可用，交付給不同客戶的軟件包是否正確，測試是否可重復……在產(chǎn)品預發(fā)布和使用階段也會有很多相應的策略實現(xiàn)可信。
技術層面，我們通過使用建模和仿真技術、密碼學的加解密協(xié)議、操作系統(tǒng)可信等技術使能可信。
這是一條完整的通過過程可信達到結果可信的路徑，最終我們通過各級度量進行持續(xù)改進。
2.4 華為云HE2E DevOps框架v2.0
華為云集合業(yè)界先進理念和華為30年研發(fā)經(jīng)驗，總結出一套可操作可落地的端到端一站式開發(fā)方法論和工具鏈——華為云HE2E DevOps框架。
首先，它是端到端的DevOps開發(fā)框架，包括從規(guī)劃設計到迭代開發(fā)到持續(xù)測試再到持續(xù)交付的全過程。我們認為僅僅只做好工程端不足以支撐整個業(yè)務，一定要延伸并回歸到業(yè)務側，實現(xiàn)端到端的閉環(huán)。
其次，它的整個過程融合了大量以可信為目的的手段，去支撐整個DevOps流程。
華為云HE2E DevOps自2018年發(fā)布1.0版本，到今年發(fā)展為2.0版本。華為云HE2E DevOps框架v2.0整體分為6大階段：規(guī)劃與設計、開發(fā)與集成、測試與反饋、安全與審計、部署與發(fā)布、運維與監(jiān)控。本文將著重介紹工程端的內容，包括開發(fā)與集成、測試與反饋、安全與審計、部署與發(fā)布。
三、開發(fā)與集成
3.1 CloudNative實踐
云的服務本身就是生于云長于云的，因此我們一直在做CloudNative實踐，在架構、工程交付、全功能團隊、云環(huán)境四部分不斷優(yōu)化，持續(xù)提升質量。
架構優(yōu)化，架構整體進行微服務改造，統(tǒng)一微服務框架到SpringCloud里，進行業(yè)務拆分架構解耦，輕量級通信。
全功能團隊，架構拆分后，團隊需要根據(jù)架構做相應的驗收和匹配。我們試點服務化全功能團隊，單個Service由2-Pizza小團隊對開發(fā)、測試、部署上線、運維端到端負責。
工程交付，踐行DevOps交付模式，構建端到端交付流水線，微服務獨立開發(fā)、構建、測試、部署、發(fā)布、現(xiàn)網(wǎng)運維。
研發(fā)全云化，依賴研發(fā)云I層和P層資源和成熟基礎服務，基于華為云打造云化服務工具鏈和環(huán)境。
3.2 Cloud Native能力構建鐵三角
從以上4個方面我們不難得出構建云原生的Cloud Native能力必不可少的鐵三角：架構、組織、工程，我認為中間還應該加上價值交付?；氐阶畛跄蔷湓挘貉邪l(fā)的目的是持續(xù)并且快速的交付高質量的有價值的軟件給客戶。
1）架構層面
采用服務化架構/微服務架構實現(xiàn)全面解耦。把系統(tǒng)劃分為多個功能內聚、粒度合適、業(yè)務邊界清晰、獨立自治的服務/微服務。
使用自服務、敏捷的云化基礎設施服務。依賴底層云化基礎設施的服務提供運行資源，使用云監(jiān)控服務監(jiān)控自身運行狀態(tài)，同時根據(jù)運行狀態(tài)出發(fā)運維事件，實現(xiàn)彈性伸縮、故障自愈等。
通過API重用云原生公共服務提供的基礎能力和架構能力。不管內部還是外部的服務之間，都可以通過API的方式自動生成相關接口和用例，來進行構建和定義，包括數(shù)字化轉型里的開放平臺、開放銀行等都是通過API來進行支撐?，F(xiàn)在比較流行的說法“API經(jīng)濟”可以了解一下，此處不展開。
2）工程層面
系統(tǒng)與環(huán)境、流程、配置解耦，人員團隊之間也進行相應的解耦與匹配。
DevOps，運維和開發(fā)相互融合，高度協(xié)同，共擔職責。
實踐極速迭代，持續(xù)交付，快速相應業(yè)務變化，縮短TTM。
3）組織層面
全功能團隊，團隊中包括產(chǎn)品、架構、設計、開發(fā)、測試、運維等角色，吃自己的狗糧，自己的產(chǎn)品一定要自己去上線發(fā)布和維護，每個人輪崗去負責發(fā)布的過程，這樣所有人都知道產(chǎn)品上線發(fā)布的流程。這樣做有幾個好處：技能的相互傳遞、打造全棧，不會依賴于某一個角色。
云化運維團隊，基于云平臺提供的監(jiān)控、報警等能力，成立專門的團隊負責系統(tǒng)運行時的質量，保證系統(tǒng)可用性和業(yè)務無中斷的升級、回滾。運維團隊更多的是構建工具平臺和流程，進行賦能。
3.3微服務化目標
系統(tǒng)解耦，功能內聚，提升需求交付效率。通過業(yè)務的拆解和解耦，讓系統(tǒng)敏捷起來。
踐行API First。通過服務化，讓服務提供者和消費者之間通過微服務API建立契約。
低成本可伸縮架構?？伸`活進行水平、橫向擴展，平滑上云，架構上支撐應用市場業(yè)務的快速發(fā)展。
服務自治。通過在線的微服務治理結合云平臺，實現(xiàn)微服務的彈性伸縮、熔斷降級等。
探索一體化服務團隊。建立2-Pizza Team，通過全功能團隊的建設，讓業(yè)務真正敏捷起來。
3.4微服務實踐 - 頂層統(tǒng)一設計
總結起來是：大兵團作戰(zhàn)，頂層設計，統(tǒng)一認識，組織賦能。角色上分為研發(fā)&運維團隊、設計&開發(fā)&測試骨干、架構師，每個角色要做什么，通過培訓和賦能的方式來進行定義和支撐。
3.5 微服務12設計原則
我們有一套一站式的微服務管理平臺來支撐微服務的12設計原則。
3.6 Clean Code
1）Clean Code機制
業(yè)界一致認為，編寫Clean Code能有效減少漏洞，降低系統(tǒng)脆弱性，是實現(xiàn)軟件可信的重要舉措。我們內部也非常強調Clean Code（代碼整潔），建立起一整套完整、具備快速反饋能力、可持續(xù)生成好代碼的機制。
華為有自己的Clean Code定義和文化。通過Committer機制、門禁機制、代碼極致共享等做相關過程的支撐，通過開發(fā)者測試對整體質量進行把控；并建立三層模型和六級標準，支撐實時代碼評估、版本交付階段性評估和產(chǎn)品長期演進的年度評估。
2）Clean Code評估
業(yè)界Clean Code評估標準是：高效、可移植、安全、簡介、可靠、可測試。華為持續(xù)對業(yè)界最新標準進行有效的代碼評估，并結合實踐建立了三層質量模型和六級質量評分標準。
關鍵舉措包括：建設分級標準，我們會對不同系統(tǒng)進行評級；開發(fā)可視化工具；建立定期評估指導場景；持續(xù)對標業(yè)界刷新評估模型。
3.7 華為Committer工程實踐
Committer來源于開源社區(qū)，大家都知道開源社區(qū)的協(xié)作模式是分布在全球各地的開發(fā)者以協(xié)同貢獻的方式進行開發(fā)，代碼貢獻者的能力、水平、責任心等參差不齊，因此必須在代碼入庫之前進行Committer評審以保證質量。華為內部也有開源的機制，借鑒這一實踐，形成自己的Committer機制。
華為的Committer機制實際上是一套流程來保證整體的代碼質量，包括三個角色：
Developer，負責創(chuàng)建本地代碼分支、本地開發(fā)、開發(fā)自檢與測試等工作；
Reviewer，負責對代碼進行檢視；
Committer，負責做最后的質量把關。
底層通過IT基礎設施來保證編譯部署、測試等過程，通過自動化工具使能，減輕評審的重復勞動。
整個Committer流程由幾個核心點：
代碼的開發(fā)、提交與合入權限應要分離，以避免攻擊者冒用員工權限植入惡意代碼；
通過檢視和審核的意見對工程師進行輔導提升團隊軟件能力。
入庫審核還能反向驅動前端代碼檢視提升，促進Developer具備編寫Clean Code的能力。
四、測試與反饋
4.1 華為云全場景測試服務框架
華為云全場景測試服務框架提供一站式端到端測試自動化智能化解決方案，為企業(yè)構建測試中臺，提升企業(yè)測試專業(yè)度及測試效能。整個測試框架分為三大塊：測試設計、設計執(zhí)行、測試分析，包括測試設計、測試用例管理、服務接口測試、WebUI測試、終端測試、性能測試、安全測試、導流測試、在線測試及測試分析報告等功能。底層有一套完整的測試管理平臺來支撐。
全場景測試服務有3個要點：
Test Left，測試左移。在研發(fā)或產(chǎn)品生命周期的早期階段就可以介入和開展測試，并且測試的工作不是只由測試人員來承擔，也就是說測試是一個活動，而不是一個獨立的角色。
Automate Everything：盡可能多自動化。在業(yè)務早期階段，快速構建起來做一些驗證，所有這些測試用例逐漸都要變成自動化的方式，這樣才能重復性地、一遍一遍地支撐業(yè)務快速交付的過程。
Test Right，測試右移。類生產(chǎn)環(huán)境始終不是真正的生產(chǎn)環(huán)境，沒辦法模擬所有生產(chǎn)環(huán)境的場景，我們還需要開展大量的線上測試。
全流程測試，每個階段都有對應的測試動作：開發(fā)環(huán)節(jié)有驗收測試、單元測試、功能測試、coding里的代碼質量把控也是測試；測試環(huán)節(jié)有回歸測試、集成測試、性能測試、安全合規(guī)類測試等；部署環(huán)節(jié)有A/B測試、在線上環(huán)境和生產(chǎn)環(huán)境做一些復雜測試，還包括吃自己的狗糧等。
整個測試會分三級進行，分別是個人級、服務級、產(chǎn)品級。每級的流水線都會涉及到質量活動，流水線也會分層分級：
個人級流水線的質量活動是從本地開發(fā)環(huán)境到Alpha環(huán)境，包括代碼檢查單元測試、編譯構建、安全掃描、接口測試等，然后通過分支合并到Beta環(huán)境；
服務級流水線的質量活動是從Beta環(huán)境到Gamma環(huán)境，除了上述測試以外，還需要跑老特性回歸測試、瀏覽器兼容性測試、性能測試等；
產(chǎn)品級流水線的質量活動是從Gamma環(huán)境到生產(chǎn)環(huán)境，本層級需要加入專項測試，比如產(chǎn)品級性能測試、可靠性測試、長穩(wěn)測試、安全測試等。
4.2 微服務交付過程持續(xù)開展質量活動
在微服務交付過程中有不同的環(huán)境，比如Alpha環(huán)境、Beta環(huán)境、Gamma環(huán)境等，每個環(huán)節(jié)有相關的質量檢查門禁和驗收標準，以及現(xiàn)網(wǎng)的質量活動。這些質量活動由不同的角色來承擔：
前端設計階段，參與的主要是架構師和開發(fā)工程師；
開發(fā)過程主要由開發(fā)工程師來承擔，架構師也會承擔開發(fā)的工作，但他做得更多的是關鍵的跨服務之間的設計和開發(fā)；
發(fā)布階段，開發(fā)工程師執(zhí)行發(fā)布的動作，測試工程師會從端到端進行質量把控，并對開發(fā)工程師進行支撐和賦能。
生產(chǎn)環(huán)境，開發(fā)工程師和運維工程師一起對系統(tǒng)進行支撐，測試工程師會做一些現(xiàn)網(wǎng)測試、導流測試、混沌測試等。
4.3 測試度量指標體系
除了流程以外，我們還會有一些質量定義和度量標準。測試度量標準總體分為兩類：過程指標和結果指標。過程度量包括：覆蓋率、執(zhí)行率、測試效率等；結果度量包括：功能測試、性能測試、安全測試、可靠性測試等。
五、安全與審計
5.1 DevSecOps的價值和實踐
安全和可信直接相關，說到可信，大家自然會聯(lián)想到安全。權衡DevOps速度與現(xiàn)有安全要求的需求，催生了一個名為DevSecOps的模型。
什么是DevSecOps？DevSecOps基于“安全問題，人人有責”的原則，它強調應用程序開發(fā)人員可以怎樣把安全檢查與他們的集成和部署流水線構建到一起。簡單來說，就是把安全層面的活動滲入到DevOps開發(fā)過程的各個環(huán)節(jié)中。 在華為云的實踐中，我們更關注在軟件開發(fā)過程中植入安全活動保證軟件生產(chǎn)的可信可靠和穩(wěn)定。
5.2 華為企業(yè)級安全工程實踐
同樣從軟件生命周期來看，華為企業(yè)級安全工程實踐基于DevOps流水線，在計劃、編碼與構建、驗證、發(fā)布與運維運營等每個階段都有相應的安全考核點和實踐介入，底層會有標準和規(guī)范、技術和能力、工具和流程來支撐，全流程保障網(wǎng)絡安全，實現(xiàn)安全設計、安全編碼、安全測試、安全運維。
5.3 CodeCheck安全
華為內部自研了一個工具：CodeCheck，以應對嚴苛的安全要求，保證整體代碼質量和安全。我們分別從能力、效率和生態(tài)運營來看CodeCheck。
能力上對應三個級別：桌面級-編碼開發(fā)環(huán)節(jié)，嵌入IDE，編碼時執(zhí)行快速檢查；個人門禁級-代碼提交入庫時，提供入庫門禁和規(guī)則集，快速檢查；版本級-持續(xù)集成、持續(xù)交付的過程中，提供全量檢查、告警閉環(huán)處理工程化能力。
效率上，前端桌面級和個人門禁級可做到秒級至分鐘級標準；到了線上環(huán)節(jié)，因為要跑的環(huán)節(jié)非常多，所以是小時級。
生態(tài)運營上，我們的工具是對內做服務，對外做客戶支撐。
5.4 安全規(guī)則
我們的安全規(guī)則來源于兩個層面：
外部視角：借鑒外部的規(guī)則，將業(yè)界的標準和最佳實踐沉淀下來，變成安全編碼的知識庫和規(guī)則集。
內部視角：華為內部有大量的產(chǎn)品線和產(chǎn)品形態(tài)，我們定義出TOP10的質量和安全問題，將長期場景梳理和安全檢查的經(jīng)驗積累成規(guī)則。
業(yè)界經(jīng)常提及的靜態(tài)分析安全測試（SAST）包括四層：編譯、構建、語法分析、語義分析，安全檢查涉及的技術棧明顯更深，華為提供全棧能力、多語言支持，支持深入的語義分析能力。如果把質量和安全結合到一起，需要一些規(guī)則和引擎來支撐，還需要引入一些智能化的手段，自動檢查、自動修復。
華為內部將規(guī)則集分為三層：公司級、產(chǎn)品線級、產(chǎn)品級/版本級/工程級。公司級規(guī)則集包括強制規(guī)則集，比如低誤報，默認必須掃除，而檢視規(guī)則集則可根據(jù)需要勾選；產(chǎn)品線級規(guī)則集和產(chǎn)品級規(guī)則集，產(chǎn)品線管理員配置為強制要求，其余的規(guī)則集可根據(jù)產(chǎn)品特性進行選擇。
整個工具不僅僅是簡單的安裝+運行，而是一個MN矩陣式的運營體系。從規(guī)則定義上來講，有公司級、產(chǎn)品線級、產(chǎn)品級等不同層級的規(guī)則；從時間周期上看，哪些規(guī)則放在開發(fā)者桌面IDE里、哪些規(guī)則要放在流水線里、哪些規(guī)則要放在版本構建里，都有一個設計的過程。
5.5 企業(yè)級專家服務
在安全層面，我們提供了企業(yè)級專家服務，其服務策略類似于醫(yī)院看診。普通“發(fā)燒感冒”的診治，提供基礎服務；針對“大病重癥”，提供專業(yè)的自動化檢查能力及工程配套能力；針對“疑難雜癥”，提供顧問式專家服務。
六、部署與發(fā)布
6.1 持續(xù)交付核心實踐
持續(xù)交付的過程是和持續(xù)開發(fā)與集成、自動化測試等關聯(lián)在一起的。比如分層快速閉環(huán)，在測試的時候就會分不同的層級去執(zhí)行，分層的目的是為了快速反饋和閉環(huán)。
持續(xù)交付的核心實踐除分層快速閉環(huán)外，還包括：小迭代高節(jié)奏交付、自動化&可視化流水線、自動化持續(xù)部署、縮短單點耗時、高效標準化環(huán)境等。
6.2 發(fā)布的分支模型和CI/CD流水線
自動化部署的背后是標準化環(huán)境，需要代碼的分支結構和整體的CI/CD流水線有很好的匹配和映射關系。
我們從代碼主干上拉出來一個代碼分支，在上面做相關的開發(fā)，提交后自動拉起來一個CI流水線，對代碼進行靜態(tài)檢查和自動化構建，包括部署包準備、代碼合并等，最終通過個人級別的流水線后，跑到生產(chǎn)環(huán)境上，整個過程都是和CI/CD流水線關聯(lián)在一起的。
6.3 可信Built-In的流水線
我們把可信的概念內建到整個流水線里，自動化檢查、驗證，過程中獲取反饋，支持實現(xiàn)CI/CD過程的高效可信。
如果代碼層面是可信的，到編譯構建的時候，可以可重復地高效地構建出來；同時，測試活動中也會加入可信相關的檢查點；到上線后，Chaos Monkey等實踐也都是跟可信直接相關的，比如我們經(jīng)常強調的彈性、穩(wěn)定性等。
6.4 Everything as Code 一切皆代碼
可能有人會問：怎么防范我的環(huán)境里被人植入漏洞？其實環(huán)境也好、過程也好，都可以代碼化，代碼化后就可以把它納入到整個版本管控中，這樣的話所有的修改和變更都可以自動化，也可以針對這些環(huán)境和過程進行安全審計。
我們稱之為Everything as Code 一切皆代碼。除了基礎設施以外，編排、配置、測試、數(shù)據(jù)庫、流水線、代碼都可以這種方式呈現(xiàn)出來，這樣就可以實現(xiàn)版本化、自動化和標準化。再往上到Service也如此，Service as Code實際上就是我們想要強調的API。
6.5 灰度發(fā)布策略驅動自動化部署與回滾
在發(fā)布的時候，我們會有各級發(fā)布的機制。首先我們會做一級的灰度發(fā)布，找一些重點MVP客戶，或者內部使用者，發(fā)布給自用環(huán)境；沒問題的話再進行二級灰度，這時會適度擴大范圍，開放給全網(wǎng)10%左右的用戶；然后再做三級灰度；最后才是全量發(fā)布。
在這個過程中，一旦任何一級出現(xiàn)問題，馬上就可以進行修復和回滾。同時我們會做一些在線導流測試，結合AB測試進行業(yè)務層面的探索，我們一直強調通過技術的手段賦能業(yè)務。
七、總結
以上介紹的是華為云的DevOps體系，其核心除了通常我們所說的“高效”、“持續(xù)交付”以外，更重要的一點是“可信”。我們將這一體系稱為“云與安生時代的DevOps體系框架”。
頂層是商業(yè)決策，我們會持續(xù)規(guī)劃、定期審視，固定節(jié)奏對其進行相應調整；往下是服務化組織、架構解耦，開發(fā)&運維落地；再往下是工具、環(huán)境支撐；最底下是服務流程支撐。
如何去構建這樣一套體系？我們要始終圍繞整體的研發(fā)效率目標，選擇應用相關的研發(fā)工具，以工具承載新型能力，支撐高效作業(yè)、持續(xù)交付、高效協(xié)同、智能化輔助開發(fā)、持續(xù)反饋與改進，進而構建整個的持續(xù)交付能力。
——————————————————————————————————————
內容來源：【2020 CSDI SUMMIT中國軟件研發(fā)管理行業(yè)技術峰會】分享實錄，原文首發(fā)于“百林哲”。作者：姚冬
嘉賓簡介：華為云應用平臺部首席技術解決方案架構師，資深DevOps與精益/敏捷專家，華為云享專家，中國DevOps社區(qū)核心組織者，IDCF（國際DevOps教練聯(lián)合會）發(fā)起人
點擊關注，第一時間了解華為云新鮮技術~
總結
以上是生活随笔為你收集整理的如何构建高效可信的持续交付能力，华为云有绝活！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android开发 RecyclerVi
- 下一篇： Elasticsearch 调优之 写入