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有效率，并且能夠快速定位問題
利用場景回放，以及記錄回放中間産物，解決在單測時場景構造問題
随着持續傳遞快速通道的搭建完成，期望通過以持續傳遞體系為契機，在多個縱向次元進行深入挖掘，并完善整個持續傳遞體系，最終在更早（快）的傳遞業務價值的前提下，能夠有更高的品質以及更低的人工成本，保證市場競争的先機，讓高德在激烈的競争中優勢更為明顯。