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有效率，并且能夠快速定位問題

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

隨著持續交付快速通道的搭建完成，期望通過以持續交付體系為貧訓，在多個縱向維度進行深入挖掘，并完善整個持續交付體系，最終在更早（快）的交付業務價值的前提下，能夠有更高的質量以及更低的人工成本，保證市場競爭的先機，讓高德在激烈的競爭中優勢更為明顯，

標籤：Html/Css

上一篇：CSS雪碧圖（精靈圖）使用

下一篇：webPack 4.0的零基礎學習