持續交付體系在高德的實踐歷程

1. 前序

對於工程團隊來講，構建一套具備可持續性的、多方面質量保證的交付體系建設，可以爲業務價值的快速交付搭建起高速公路，也能爲交付過程當中的質量起到保駕護航的做用。本文爲你們介紹持續交付體系在高德的演進與落地。

2. 持續交付

正如前序中所總結的，咱們須要構建一套持續交付體系，從而保證在質量不降低的前提下，在業務價值交付上有更進一步的突破。那麼咱們先了解一下什麼是持續交付以及集團在持續交付的建設上有哪些指引。

2.1 持續交付概念

引用Martin Fowler大師在2013年時發表的文章，對於持續交付的概念有以下的解釋：Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

在上述文中，能夠提取幾個關鍵詞：

• 軟件開發的標準化準則

• 能夠作到隨時隨地的發佈

什麼狀況下就能夠算是團隊達到了持續發佈的狀態呢？Martin Fowler大師也給出了標準的答案：

• Your software is deployable throughout its lifecycle

• Your team prioritizes keeping the software deployable over working on new features

• Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them

• You can perform push-button deployments of any version of the software to any environment on demand

那麼基於以上的觀點，咱們在創建自身的持續交付體系時，須要抓住如下幾個重點：

標準化流程流轉 當有變動進入時，可以快速、準確且自動的獲得反饋 解決部署問題的優先級高於功能開發 一鍵發佈

2.2 集團的持續交付建設

從理論基礎上對於持續交付有了初步瞭解後，咱們從集團層面瞭解一下是如何定義持續交付的能力，而且對於持續交付提出了哪些效能改進目標，參見阿里技術公衆號的文章 《如何衡量研發效能？阿里資深技術專家提出了5組指標》

文章中將持續價值交付的能力拆分爲3個層面的5組指標，從不一樣角度對持續價值交付能力進行了衡量。

有了上面專業層面的衡量指標，那咱們是如何定義一個優秀的持續交付衡量目標呢？

管理學之父德魯克說：「若是你不能度量它，就沒法改進它」。度量幫助咱們更深入認識研發效能，設定改進方向，並衡量改進效果，因此想要進行效能提高的前提是先可以識別交付過程當中的質效瓶頸。

所以，集團在基於部分BU的優秀實踐下提出了2-1-1的願景。

• 1小時的發佈前置時間是對於基礎設施能力的要求，須要保證當達到交付標準後，經過交付流水線可以達到1小時內的打包、部署和驗證的能力；

• 1周的開發週期涉及產品需求拆分、研發QA協做能力、持續測試以及快速反饋能力方面提出了挑戰；

• 2周的需求交付週期是之前兩項爲基礎，不只是涉及到產研測三方，還包括其餘協同部門的通力合做才能保證業務價值的快速交付。

3. 持續交付在高德

在基於集團願景的指導下，反觀現有高德服務端的交付流程，咱們發如今整個流程中，存在不少效率上的豎井，這些效率問題彙總起來，便會成爲整個交付流程上的效能瓶頸，進而影響業務價值的儘早交付。

咱們先從一個總體的Milestone來回顧一下整個持續交付所通過的一些重要時間節點：

• 2018/08 構思與工程能力建設：項目啓動階段，工程效率團隊與業務線明確了持續交付的目標，並啓動了工程能力建設

• 2018/12 初步落地與試點：項目試點階段，完成了初步的持續交付流程搭建，並在一個項目中驗證流程卡點以及質量標準的基礎能力驗證。最終創建了基礎的質量標準以及下降流程中的耗時

• 2019/04 推動接入與平臺優化：項目推動階段，持續交付項目質量項優化並在高德的服務端的6條業務線中進行推廣，在9月份完成6條業務線以及11個應用的持續交付落地

• 2019/09 覆盤與展望：項目推動總結，對整個推動過程進行復盤與後續持續交付如何落地進行復盤與展望，總體產出業務推動中出現的問題以及改進方法 將來：在交付流程上進行貼合業務線的微創新，並對效能瓶頸點進行縱深挖掘。結合各縱向平臺進行縱深挖掘，例如：覆蓋率與精準迴歸、雲歌Case平臺、代碼掃描平臺等

• 經過milestone的展現，對於高德持續交付體系的演進有了大體的瞭解後，下面對於落地的過程以及改進的內容進行一下詳細的梳理。

3.1 接入持續交付前的交付流程

首先先介紹一下在接入持續交付體系以前，高德的服務端是如何進行迭代的開發與上線的。

與大部分互聯網公司同樣，咱們將軟件的交付拆分爲多個週期，進行迭代式的交付，以便增量式的進行用戶價值的交付。上圖描述了一個正常迭代週期內的研發、測試以及發佈的流程，咱們能夠拆分爲如下幾個方面：

1.迭代週期起始於代碼庫的變動

2.在功能開發完成後，研發經過CI系統進行冒煙測試驗證，保證服務能夠正常啓動以及基礎功能可用

3.在規定的提測時間前，研發將Feature分支經過CR和MR合併到迭代分支，部署到平常環境進行提測

4.QA在收到提測郵件後，參與到平常環境的測試中

5.當平常環境測試完成後，QA會進行測試報告的產出，並確認平常環境測試經過，能夠發佈到預發環境

6.部署到預發環境後，會進行流量回放等測試，並最終經過線上的灰度驗證，最終發佈到正式環境

經過上述的圖片和描述，咱們能夠看到在看似完善的軟件交付過程當中，卻仍然存在以下一些質量、效率問題：

1.需求堆積提測、發佈：

目前高德服務端大部分服務採用的是固定迭代週期進行需求發佈，規劃到迭代週期內的需求，不管需求大小，均須要等到迭代提測時間點進行提測，在迭代的發佈窗口進行發佈上線。在這種模式下，好的一點是有固定的版本節奏，總體迭代規劃性比較強。可是因爲提測、發佈窗口固定，從而也帶來了總體業務價值交付上的等待。所以，須要經過需求拆分來下降需求內部的耦合性，經過改變研發、QA的開發測試模式來下降需求提測中間的豎井等待，從而提高業務價值交付的效率。

2.質量標準不透明，沒法及時反饋：

從代碼提交一直到最終產品發佈，通常狀況下，會經歷平常、預發、灰度、正式發佈幾個階段，每一個階段均有每一個階段須要重點解決的問題以及對質量上的要求也不盡然相同。目前結果的收集彙總和通知都是經過跟版人進行人工收集和統計，並郵件通知項目成員。這樣全部的標準控制都是有每一個版本的跟版人進行把控，存在信息不透明，反饋不及時的問題。經過質量項標準的創建，以及大盤結果透明和及時的通知，可以解決溝通層面的低效以及在傳遞過程當中信息損耗，從而提高溝通效率，而且避免溝通中的誤解。在解決了當前透明化和及時通知的問題後，咱們須要進一步從如下兩方面進行優化：

將通知進行分類以及優先級處理，下降通知帶來的負面影響

經過信息內容優化，輔助業務進行問題的快速定位與排查

3.部署與流程流轉過程須要人工參與：

對於持續發佈流程來講，有人工參與的地方勢必會影響到其中的效率。因此咱們將部署和階段流轉拆分爲兩個方面看：

階段流轉：結合上述的階段標準，經過程序來計算是否可以知足當前的質量狀況是否能夠進行階段的流轉，從而排除人爲因素以及在階段流轉中的耗時，作到準確

部署：提取相應環境的配置信息，結合Docker化，將打包、部署、健康檢查等一些列活動轉換爲機器的標準化執行，經過標準化來避免人爲參與所形成的偏差或部署失敗的問題

4.多機房正式發佈驗證人工監督：

目前在應用的正式發佈流程中，因爲涉及的機房和機器數量較多，業務上會進行分批驗證，每發佈完成一批機器，研發會通知QA進行這批機器中部分機器的抽檢（部分自動化測試），在這其中也存在着效率上的問題。因此如何節約每次上線過程當中的人力損耗，也是在追求效能極致上須要解決的問題。

上述的每一個細節的問題，都在咱們通往快速業務價值交付的道路上設置了障礙。所以，爲了達成更早（快）的交付業務價值的目標下，咱們必需要在交付效率、質量標準以及結果快速反饋這幾方面的進行優化。

3.2 持續交付在高德的落地

基於上節拆分出來的4方面的問題，從工程角度來講，因爲迭代的排期，需求的分解與拆分須要進行長期的實踐與規劃，而且依賴於產、研、測、項乃至於其餘部門的支撐，是一個須要進行逐步探索和調整的過程。因此咱們將着眼點放到後3方面的建設上，指望在短時間內先創建起快速發佈的能力，清除在交付過程當中效率低下的點。

那麼在解決效率問題的建設上，藉助於集團提供的發佈流程以及較好的部署能力，咱們將目前拆解爲以下幾個維度的抓手：

依託於集團的發佈流程，在持續交付體系中創建與集團發佈流程對應的標準化流程流起色制

創建服務端質量標準體系，拉通質量標準，去人工化

打通各環節的快速反饋機制，並對發佈流程進行管控，讓變動結果隨時可見

下降發佈過程當中的人爲參與，讓整個發佈流程作到全程無人值守

經過下面持續交付流程圖，咱們經過接入後的流程圖中看一下以上4個抓手是如何串聯起總體高德持續交付流程，而且這幾項是如何在高德服務端交付流程中進行落地的。

創建標準化的流程流起色制

FY19高德服務端發生的線上問題中，其中因爲變動或發佈引起的問題佔比約12%。經過這組數據，咱們指望可以經過創建一套完整的交付流轉流程，實現對於變動的控制和管理，下降或避免此類問題的發生。

基於以上立論，咱們結合當前服務端交付特色，首先先確立以集團標準發佈流程爲試點，打通總體持續交付流程；其次，針對各應用中不一樣的需求，例如：須要性能環境、覆蓋率環境等，結合流水線配置，將整個持續交付的流程流轉進行優化；最終沉澱爲各服務的標準化流程流起色制。經過這種先僵化，後優化，再固化的方式，最終在服務端落地了多套標準的交付流程，避免了在交付環節上的遺漏，以及不規範的操做。

拉通並落地服務端質量體系標準

在高德現有的交付流程中，總體的質量保障手段大部分是在平常階段進行的，在迭代交付的過程當中，各項質量保障手段執行了哪些，執行結果是什麼，目前仍是經過QA人員進行人工問題收集與彙總，並斷定階段結果的經過與否。在這種狀況下，會出現因爲跟版人交替致使的質量項遺漏，以及質量標準難以把控的狀況。

因此基於這幾方面的問題，咱們但願經過用機器把控替代原有的人工把控的方式，經過創建標準化的質量模板，來避免總體執行標準不透明，執行結果無沉澱的狀況。而且，經過拉通標準，也進一步的規避掉了非重點服務質量檢查點遺漏的狀況。

經過與業務團隊的溝通，咱們在第一階段將現有服務端的質量保證手段進行拆分，提取了在不一樣階段中相對重要的12項質量項，經過機器監督替代原有的人爲統計的方式。具體覆蓋了以下幾個維度：

打通各環節的快速反饋機制，並對發佈流程進行管控，讓變動結果隨時可見

當創建起有效的質量體系後，在各階段有了質量要求以及准入準出標準，解決了信息收集方面的問題，那麼接下來咱們要思考的就是如何將收集上來的各類信息，有效的反饋到項目中的各個干係人，以便進行後續的決策支撐，而且當未達到階段準出標準時，有效的控制項目的階段流轉。

咱們將問題拆解爲兩方面看，一是有效反饋、決策支撐，二是流程流轉的管控。

從有效反饋、決策支撐方面看：

在接入持續交付以前，各業務線的針對不一樣類型的自動化測試任務，大部分都有經過Jenkins或測試用例工程反饋結果的通知。可是此類反饋有一個致命的問題，就是經過單項反饋沒法縱觀全局，不足以支撐後續的決策。

在接入持續交付後，除了原有業務上的反饋機制，平臺提供能針對當期版本的總體狀態全覽，能夠經過平臺隨時觀測到當前版本是否達到可發佈的狀態或者仍然存在哪些不足。將二者結合起來後，針對項目執行人仍然能夠經過原有反饋機制瞭解到單點的質量結果；對於跟版人、一線、二線管理者這類須要縱觀全局的角色來講，經過質量大盤，能夠有效且明確的知道當前版本與待發布狀態的差距，並支撐後續決策以及調整關注的重點

從流程管控方面看：

在接入持續交付以前，可部署的產物不管是否通過階段驗證，均可人爲的部署到任意環境下，雖然靈活性比較高，可是也存在必定的質量風險。

在設計持續交付流程時，對於靈活性以及規範性的取捨方面，咱們也與業務同窗進行了討論。從全局看，爲了不流程不規範引發漏測或其它線上事故，最終肯定在第一版時先保證流程流轉的規範性，從而下降靈活部署上所帶來質量上的風險。平臺經過集團實驗室插件與集團的部署發佈系統打通，當階段中存在質量項還沒有達標的狀況下，阻止發佈流程進入到下一階段（環節）。

當基礎的持續交付流程落地後，爲了知足業務上對靈活性的要求，目前咱們也在嘗試經過自定義流水線來進行多環境的分發與部署，從而在保證主要階段流轉有管控的同時，增長部署的靈活性，以適應不一樣的業務形態。

下降流程發佈過程當中的人爲參與，讓整個流程作到全程無人值守

咱們知道，線上環境部署的複雜程度要遠高於在平常和預發環境的部署。因爲部分業務線，線上的機器數量衆多，且分佈在不一樣機房，爲了保證部署時的服務可用性，線上部署時會將上千臺機器拆分爲多批次進行部署。

在接入持續交付前，爲了保證部署後服務的可用性以及對質量上的高標準要求，在每批次部署完成後，QA都須要針對當前批次進行全批次驗證或抽測驗證，當驗證經過後，再進行下一批次的發佈以及後續驗證。雖然驗證自己是經過自動化腳本進行驗證，但因爲機器和批次比較多，整個發佈和驗證流程會持續數小時，存在較大的效率問題。

在瞭解到業務上此效率瓶頸後，經過打通上下游系統，集團標準流程、集團發佈系統以及原有業務的線上驗證工程，針對不一樣業務的發佈場景，進行發佈驗證策略的配置化。經過感知部署時的消息，獲取當批次部署的機器列表，依據各業務的驗證策略配置進行自動化的驗證。而且結合線上階段的報警監控，當某批次發佈驗證出現問題後，系統能夠第一時間定位到具體是哪一批次中的哪臺機器發佈出現問題，幫助業務進行部署問題的快速定位。

持續交付體系的業務架構

4. 落地效果

整個持續交付體系建設，目前在高德服務端落地已經有一段時間了，截止到目前爲止：

業務線覆蓋：整個持續交付體系已經覆蓋了高德服務端大部分重點業務

各階段質量項建設：12項

正式發佈階提效：50%~90%

在得到以上成果的同時，除了上述量化指標外，更有價值的是隱含在背後的研發、測試習慣上的變化。從研發、QA和項目主動發起的縮短項目週期，到QA對於質量項上提出更多的訴求等等，無一不感知到你們對於儘早且高質量的交付業務價值這件事情的重視。固然對於更早（快）的交付業務價值這個目標還有必定的差距，這個也是後續咱們與業務線須要共同解決的問題。

5. 持續交付的將來

有人將持續交付形容爲在價值交付上的高速公路，持續交付的落地，標誌着價值交付到用戶的快速路已經創建完成。可是最終是否能作到更早（快）的交付業務價值，還取決於在這條快速路上行駛的車輛。

根據這個理論，咱們除了要保證這條高速公路上不出現坑窪的同時，還要兼顧車輛自己的能力，以及車輛的性能。所以，在車輛出發前，咱們更須要經過對車輛的車況進行檢查，保證在高速路上行駛的車輛不會由於自身的緣由提不起速度。

5.1 車況檢查

目前，已有的持續集成系統，僅可以保證車輛在這條路上是能開起來的，車況的檢查都是在上了高速後纔開始的（大部分的質量保證手段是部署到平常環境後纔開始）。因此基於上面描述的指導方針，咱們須要儘早的作檢查，而且須要作更全面的檢查（質量保障手段左移）。

基於這個目標以及結合集團內其餘BU的優秀實踐，後續咱們但願能經過代碼門禁的手段，儘早落地這類全面的檢查。若要將代碼門禁落地，不管是對於工程效率團隊亦或是業務研發與QA團隊，都有着不小的挑戰，咱們須要作到如下的轉變：

QA 質量保證的同期化能力建設

質量保證的穩定性與耗時優化

RD 研發提交代碼流程的改變

單元測試能力的建設

Code Review的常態化落地以及規範總結

能力支撐 代碼覆蓋率，業務場景覆蓋率的支撐

代碼合併的門禁管控能力

代碼掃描結合CodeReview的總結的落地

當逐步完成以上任務的落地後，可以消除批量交付業務價值交付中相互等待的時間，而且也可以保證車輛在持續交付這條高速路上行駛得更快更穩定。

5.2 車輛性能提高

前面車輛檢查能夠說是在車輛上路以前的檢查與保障，將質量保證手段左移到研發階段。相對的，咱們但願經過車輛性能提高的方法，在車輛上路後，可以讓車輛行駛提速更快，拉高速度的上限。

縱向測試能力提高 精準迴歸：經過感知代碼的變化，推導出代碼變更所影響的Case，讓質量保障更爲精準且耗時更少

場景覆蓋：結合線上流量回放，經過代碼覆蓋、場景覆蓋進行查缺補漏，讓質量保障更完整

問題定位：結合失敗用例，快速的進行問題定位與反饋

同期化能力：結合雲歌Case平臺，經過接口定義進行測試代碼與研發代碼同期化編寫能力的增強，以及下降Case編寫和維護成本方面的探索

下降數據干擾：基於高頻、隔離和用完即拋的理論實踐，下降平常環境的數據干擾，讓質量保證更有效

與線上數據挖掘結合 大數據分析：

利用線上日誌分析，產出線上真實場景模型，下降壓測平臺語料準備耗時，場景篩選上作到精確、高效

大數據運用：

結合線上真實場景以及場景覆蓋率，構造線下回歸Case集，下降業務迴歸Case維護成本，提高Case有效率，而且可以快速定位問題

利用場景回放，以及記錄回放中間產物，解決在單測時場景構造問題

隨着持續交付快速通道的搭建完成，指望經過以持續交付體系爲契機，在多個縱向維度進行深刻挖掘，並完善整個持續交付體系，最終在更早（快）的交付業務價值的前提下，可以有更高的質量以及更低的人工成本，保證市場競爭的先機，讓高德在激烈的競爭中優點更爲明顯。