0. 前言美團外賣自2013年建立以來，業務一直在高速發展，從早期單一的美食業務發展成為包含閃購、跑腿、閃付、營銷、廣告等在內的平臺業務。每個業務團隊雖然都有不同的業務形態，但是幾乎都有相同的訴求：需求能不能儘快的上線？本文將從外賣的歷史實踐中，淺談一個好的持續交付需要綜合考慮哪些關鍵因素，希望對大家有所幫助或啟發。
美團外賣自2013年建立以來，業務一直在高速發展，目前日訂單量已突破3000萬單，已成為美團點評最重要的業務之一。美團外賣所承載的業務，從早期單一的美食業務發展成為了外賣平臺業務。目前除餐飲業務外，閃購、跑腿、閃付、營銷、廣告等產品形態的業務也陸續在外賣平臺上線。參與到美團外賣平臺的業務團隊，也從早期的單一的外賣團隊發展成為多業務團隊。每個業務團隊雖然都有不同的業務形態，但是幾乎都有相同的訴求：需求能不能儘快地上線？
然而，Native應用的釋出依賴於應用市場的更新，週期非常長，非常不利於產品的快速迭代、快速試錯。同時，作為平臺方，我們需要考慮到各個業務團隊的訴求，統籌考慮如何建立怎麼樣的模型、配套什麼樣的技術手段，才能實現最佳的狀態，滿足各業務更短週期、高品質的交付業務的訴求。本文會首先回顧美團外賣從早期的月交付，逐漸演變成雙週交付，再從雙週交付演變成雙週版本交付配合周動態交付的過程。然後從外賣的歷史實踐中，淺談一個好的持續交付需要綜合考慮哪些關鍵因素，希望對大家有所幫助或啟發。
1. 交付模型
一個需求從產生到交付再到使用者的手上，要經歷需求調研、需求分析、程式設計、程式碼開發、測試、部署上線等多個環節。在整個過程中，由於涉及到不同角色的人員，而不同角色人員的認知存在差異，不同的程式語言存在差異，不同的開發方式也存在差異。在整個交付需求的過程中，還面臨著需求可能會被變更、交付週期可能會被變更等各種情況。這些情況使得需求的交付變得非常複雜、不可預期。
而軟體開發的首要任務就是持續、儘早地交付有價值的軟體。怎麼解決這一問題，是軟體工程一直在研究的話題。早在20世紀50年代，軟體領域就在積極地探索設計什麼樣的模型可以解決這些問題。常見的包括瀑布流模型、迭代模型、螺旋模型、敏捷模型等等。由於篇幅原因，本文不再做詳細的介紹。
2. 什麼是持續交付
關注持續交付，不同的企業、不同的團隊站在不同的角度存在不同的定義。《持續交付2.0：業務引領的DevOps精要》一書認為，站在企業的角度，將持續交付定位為一個產品價值的開發框架，是一個工具集，其中包含了一系列的原則和眾多實踐，幫助提升企業的內部運轉速度和交付效率。
從知乎話題“如何理解持續整合、持續交付、持續部署”，我們可以看到大部分研發團隊，會從軟體研發的角度進行定義，他們將軟體的開發步驟拆解為持續整合、持續交付、持續部署，其中持續整合指開發人員從編碼到構建的過程。持續交付指將已經整合構建完成的程式碼，交付給測試團隊進行測試的過程。持續部署指將測試通過的軟體交付給使用者的過程。而產品團隊會站在產品的角度來看，他們認為持續交付，是從需求的PRD文件提出來，到使用者能夠感受到這個需求的週期。
從美團外賣業務的角度，我們可以將持續交付定位為“外賣使用者”和“外賣團隊”之間的緊密反饋流。而外賣團隊涉及到PM、UI/UE、RD和QA角色。如下圖所示，產品同學從市場或使用者的需求和反饋中收集到需求，轉換為需求PRD文件，交由設計互動同學設計成期望使用者所見的介面和行為，然後交給研發團隊進行調研實現。研發團隊實現後，再交給測試團隊進行測試。等測試團隊完成測試後，提交到應用市場，最終交付到使用者手上，這個過程是本文所考慮的交付。“持續”指的是，外賣團隊將外賣的業務拆分成不同維度的子業務，每個子業務持續通過這個迭代流程不斷地優化各個子業務達到最優，從而使整個外賣業務達到最優。
3. 外賣持續交付模型的變遷史
3.1 外賣的早期交付模型
早期外賣的交付模式為“序列交付”，一個版本完成後，開啟下一個版本。整個交付過程包括需求評審、需求開發、迭代提測、一輪提測、二輪提測、三輪提測、灰度提測和全量釋出8個環節：
由於美團的外賣業務是一個雙平臺業務，需要同時開發外賣App和美團App。在人力安排上，我們會分成兩個組，App組和頻道組並行開發。App組開發當前的版本業務，頻道組同步上個版本的業務到當前的美團平臺版本。整個版本週期耗時六週半左右，遇到節假日會順延，全年能發版11～12個，版本交付週期如下圖所示：
交付模型中關鍵點
需求評審分為主打需求、非主打需求和統計需求。主打需求：客戶端開發10d之前進行評審，評審8d後UI提供初稿，評審14d後UI定稿。非主打需求：兩個三方評審視窗，視窗1為視窗2的前5d，視窗2為上一版本二輪測試地一天，UI定稿需要在客戶端開發第一週內完成。統計需求：需求收集截止到立項評審前一天，三方評審為非主打需求評審後第二天。伺服器在需求評審後，客戶端開發第一週前，提供介面文件。客戶端開發週期為兩週，客戶端開發第5個自然日API提測，客戶端開發第5天發迭代提測包，第二週結束髮提測包。QA驗收提測包，一輪3d、二輪3d、三輪1d。灰度3d，需避開節假日前發灰度。全量釋出電子市場。單月發版優缺點
優點：
每個版本可根據當版的情況控制版本的週期，可同時支援多個大需求的並行開發。版本較為固定，各角色的分工明確，開發人員在開發期較為專注，開發效率高。測試周期長，App能夠得到充分的測試。缺點：
版本迭代週期較長，從需求評審開始到需求灰度，需要6.5周。無法滿足日益增長的業務訴求，對於一些嘗試性專案，無法滿足PM急迫上線驗證效果的需求。發版頻率低，每年只有11~12個版本。對標其他網際網路公司，業務產出相對較低。每個角色的利用率不高，如RD在開發期的時候，QA處在待測試狀態。3.2 雙週迭代的交付模型實踐
為了滿足日益增長的業務訴求，我們提出了雙週發版的交付模式，從而實現業務的快速迭代。貫徹的總體原則為：評審、開發、測試完全並行，以兩週為固定週期，以需求維度持續交付。
3.2.1 雙週迭代模型
在切換雙週迭代模式之前，需要落地一些準備工作。例如統一版本排期的時間表、確定專案中各個角色的交付時間，讓PM、UI、客戶端RD、服務端RD和QA，各角色都能夠清晰的知道自己接入的時間點，並在規定的時間點交付內容。由於各角色的任務和分工得到了明確，減少了協作中的溝通成本，各角色也可以如齒輪一樣，持續產出交付給下游團隊，整個交付週期效率得到了有效的提升，一個版本的週期縮短為5.5周，發版次數上升到22~24版本。
版本各個角色分工詳情示意圖如下所示：
雙週模型中關鍵點：
W1需求評審：週三PM組織三方評審業務需求+埋點需求+UI需求。W2排期：週三API RD出排期，週四客戶端RD出排期，UI產出視覺初稿。客戶端RD排期需細化至需求可提測時間點，便於QA、PM和UI提前協調測試、驗收時間。W3介面評審+服務端先行開發：介面文件，UI資源週四前到位。W4客戶端開發，週四API提測（最晚）。W5客戶端開發+冒煙測試：RD開發完後直接冒煙測試，以需求維度交付給QA，不需要等到最後一天集中冒煙測試；需求交付後，PM與UI可介入驗收環節。W6客戶端測試+週二服務端上線：客戶端一輪測試結束前，PM與UI應完成需求驗收。W7灰度+週二全量理想狀態一個版本的週期為五週半。W3時，PM會繼續組織三方評審；W4時，API繼續開發下版本；W5時，客戶端RD會繼續下一個版本的開發。3.2.2 分組交付
雙週迭代模式的變化也推動我們在人力分配方面的改進，人力安排演變經歷了三個過程：
在雙週迭代的過程中，客戶端的交付是連貫的，理想狀態是每個RD可以隔版進行需求開發。但是大家都知道，寫完需求是不可能沒有Bug的，需求的估時也不可能都是5的倍數，這樣就會造成很多RD既要開發當前版本，又要解決上個版本的Bug。這間接引入了2個問題：
後來我們經過內部研究，提出了AB分組的方案，保證AB組是隔版本進行開發。當組內需求拆分有衝突時，需要在內部協調消化，避免RD出現每個版本都會參與開發的情況發生。
AB分組施行以後每個RD都是各版本開發的，不會出現同一個時間段內，要處理上個版本的Bug和當版需求的情況。但業務的熟悉度和RD的強對應關係還是沒有得到解決，所以我們就進一步的思考，提出採用業務維度AB組。如下圖所示，我們先將同學進行業務劃分，在以業務組進行AB的劃分。當然這個業務組人員的數量需要考慮業務的規劃情況，當某一個業務需求量增長上來的時候，業務組的大小也需要同步進行增長。
3.2.3 雙週迭代的優缺點
雙週迭代的優點：
提高了業務迭代效率，從而提升了業務的產出，以一月能夠完成二個版本的交付速度，持續地交付版本，達到一年交付20-24個版本的交付目標。在人力整合利用上更加合理化，各角色都能夠持續的產出，版本的交付週期變為5.5周。雙週迭代的不足：
相比之前的當月發版，雖然雙週迭代帶來一定收益，但還是存在一些客觀的問題：
從評審到交付，釋出週期還是太長，產品快速上線的訴求依然不能得到很好的滿足。敏捷性受到一定影響，對於特定需求和小需求不是很友好。3.3 雙週結合周交付的模型實踐
外賣在歷經了雙週迭代後，一定程度的縮短了版本交付週期，提高了業務迭代效率，優化了人力安排，但是仍然存在一些問題。對於一些簡單的需求來說，像外賣中“我的頁面”模組的點選熱區擴大（“我的頁面”已經是RN頁面），實際上開發只需要2天，卻仍然要跟隨版本迭代的節奏，5.5周後才能上線，需求交付週期仍需進一步縮短。另外，外賣自研動態化框架Mach在大量業務的應用落地，多種開發流程及交付需要，使得雙週交付越來越難滿足外賣業務版本迭代及交付的節奏。
3.3.1 動態化能力的建設
為了滿足業務需求的快速上線及外賣面臨的包體積的壓力，外賣引入了動態化來解決此類痛點問題。外賣動態化能力建設的思路主要是：核心流程頁面區域動態化，區域動態化方案採用外賣自研的Mach動態化框架，核心流程採用區域動態化，保證頁面的穩定性及使用者體驗，非核心流程頁面MRN化（Meituan React Native），通過MRN來替換所有的低PV頁面，下線Native頁面。具體技術細節可參考《React Native在美團外賣客戶端的實踐》一文。
目前外賣低PV的MRN頁面數量已達：56/67。已經覆蓋了外賣所有的低PV頁面，除核心流量頁面均為MRN頁面，從頁面數量維度，MRN頁面佔比已達83.58%。
Mach區域動態化覆蓋了首頁核心流量區、二級金剛頁、訂單頁、點菜頁及搜尋頁。目前上線的模板數已達43個。
3.3.2 雙週迭代&周迭代
在完成了外賣動態化能力的建設後，外賣業務逐漸演進出了兩類需求：
主版本需求，主版本需求主要是Native方式實現，結合少部分動態化需求。敏捷開發需求，主要通過動態化和敏捷模型的加入實現高效的版本迭代，動態化主要指上節所介紹的動態化能力的建設，敏捷模型採用前文所說的敏捷模型。面對上述兩類需求，現有雙週迭代及分組交付流程，對於部分特定需求及小需求不太友好。目前無法做到需求最快速上線，如上述“我的頁面”點選熱區擴大。
因此，我們在雙週迭代的基礎上，演進出了現在的雙週迭代結合周迭代的交付模型。交付模型圖如下：
雙週迭代結合周迭代的交付模型是在原有雙週迭代的基礎上，保持主版本需求雙週迭代不變，增加每週的動態上線視窗。以每週二為動態上線視窗時間，週五為提測DeadLine，根據動態化需求的開發及提測時間來動態搭車上線。
目前，外賣的周迭代需求分為兩類：
純動態化需求，根據需求開發及測試排期選擇上線視窗，搭最近一次的上線視窗。動態化結合Native需求，跟隨主版本交付流程，在提測周發版上線，主要面向敏捷迭代內容。純動態化需求由於不依賴Native發版，無需依賴Native的全迴歸，開發完成可隨時提測，提測後功能測試完成即可上線，可以做到需求的最快速上線。敏捷迭代內容，不依賴主版本的評審，採用自主評審，自主決策跟版的策略。
而多種動態化方案的開發模式，需要統一的動態化發版及上線能力的支撐。外賣周迭代發版及上線具體可以分為兩步：
發版。將動態化模板進行打包，得到Bundle並上傳，通過Talos平臺（美團內部自研）進行打包。Talos是基於前後端分離思想設計的一套前端DevOps解決方案。上線。將通過Talos打包得到的Bundle上線釋出，釋出通過EVA客戶端動態分發平臺進行線上釋出。具體流程如下圖所示：
截止目前，外賣周迭代發版經過了15個上線視窗，共計發版50+次。
雙週迭代結合周迭代的交付方式進一步縮短了版本的交付週期，從需求收集評審到需求上線對於敏捷需求可以縮短到3.5周。對於純動態化需求可縮短到1周，最終做到了需求評審做到了需求的快速上線、快速驗證、快速修復，敏捷迭代。
3.4 自動化版本管理系統
在施行了雙週迭代結合周迭代後，大大縮短了需求的上線週期，但是同時也提升了版本流程管理的複雜度。怎麼樣保證版本流程的正常運作呢？外賣C端涉及開發人員分為A、B組及敏捷開發人力；同時涉及美團頻道及外賣App雙平臺，需要考慮雙平臺的版本迭代週期；涉及階段多，各階段都需要人工操作，執行事件多，雙端執行事件總計40+；涉及雙版本並行開發，倉庫程式碼管理複雜。
原有版本迭代流程，版本各階段的所有事件都由相應負責人執行。
分支建立、版本降級檢查、每日QA包號周知，倉庫整合及基礎庫同步、打包，提測郵件等都由迭代工程小組人員負責執行。倉庫拉出Release分支，提審灰度後分支合併、整合、發版由外賣各倉庫負責人負責執行。周迭代、迭代、一輪、二輪、三輪提測階段冒煙周知，則通過排班的形式，在冒煙提測當天，由人工提醒並監督。在版本迭代流程上會耗費了大量的人力。如何解放這部分人力，讓整個版本迭代流程自動化，做到無人值守，減少人工操作的失誤。這是此前外賣前端技術團隊面臨的非常頭疼的問題。
在我們規範了雙週迭代&周迭代的流程後，版本各階段的時間能夠基本固定。為了能夠做到自動化，我們把版本各階段需要人工操作的事件整理歸類，把事件確定到當前版本的固定一天固定時間點。以一個版本為例，我們整理歸類如下：
確定好所有事件的執行時間後，我們便嘗試把所有需要人工操作的事件自動化。並通過在確定的時間去觸發，來做到整個版本流程的自動化。
早期的版本管理，我們依託於Gulf（美團內部日期管理系統）、QA-Assistant系統（美團內部事件通知系統）、CI及大象（美團內部通訊工具）訊息，通過在Gulf系統提前配置好各版本各事件的時間，並通過QA-Assistant配置人員名單及訊息，在固定時間節點，Gulf去觸發QA-Assistant，通過上述方式，做到了各類提醒的自動化，並且在CI上部署上自動化Job，由人工觸發。
但是通過這種方式，存在一些弊端：
版本各節點事件都需人工單獨一個個配置，且Gulf和QA-Assistant系統的觸發一直需要關注。仍然需要大量人工操作，只能做到流程的半自動化，人力還是無法做到解放。版本流程無法做到視覺化。為了解決上述問題，我們和Tide版本管理系統（美團內部元件）共建，實現了現在的外賣C端自動化流程管理。
以Gulfstream的版本排期為基準，通過Tide版本管理系統進行事件觸發。通過指令碼將CI、Stash倉庫管理系統、HyperloopX發版打包系統、大象整合，做到程式碼/分支管理自動化、打包整合自動化、周知提醒自動化、版本流程視覺化。
在版本開始前配置好當前版本，後續則會在版本的每個關鍵節點自動執行需要執行的事件。
Tide版本管理視覺化介面如下，按照版本各階段及時間線順序排列：
各類事件提醒及執行通知如下：
各類提醒確認結果即時展示：
3.5 CI建設在CI建設方面，我們工作主要集中在以下5個階段：準備階段、PR檢測、開發階段、提測階段和發版階段。
下面介紹三個CI工作中，外賣場景下的特定檢查：
Aimeituan工程獨立編譯自動配置：同事反饋配置團App原始碼依賴的配置項較繁瑣，切換開發分支時需要反覆進行配置，為了提供RD的開發體驗。通過指令碼自動修改WM提測分支的原始碼依賴配置項，只需修改Aimeituan的gradle.properties一個屬性實現原始碼依賴切換，實現一鍵切換的功能，提高版本開發效率，優化項包括：業務方依賴只保留團首頁和外賣業務。只保留開發除錯必要的外掛：ServiceLoader和WmRouter，提高編譯速度。只保留除錯Flavor：提高編譯速度。業務庫檢測是否有PR未合入：版本快速迭代對程式碼管理也帶來了挑戰，發生了幾次因為RD未及時合入程式碼，影響QA提測進度的問題。因此在打提測包之前增加了一個檢測環節，如果檢測到有PR未合入提測分支，將在大象群統一週知發起人，提高版本的交付品質。定時檢測殼工程是否有更新，自動觸發打包，保證QA第二天能迴歸前一天所有的修改，避免測試返工的問題，提高版本測試有效性。總結
Aimeituan獨立編譯配置從5～10分鐘（同事反饋從修改配置到同步完成的耗時）降低到45s左右，優化了80%～90%。在經過了幾個版本的實踐證明，自動化檢測PR合入是有必要的，而且能夠有效降低開發人為失誤導致漏提交程式碼發生的概率。每天早上同步Aimeituan的Release分支，及時周知負責人同步結果，減少人工Check的重複工作。3.6 部署釋出
部署和釋出，對於移動App來說，已經到了最後的環節。我們認為的部署行為主要指將一個還處在測試的版本提交到測試環境，然後讓QA進行測試，釋出行為主要指將測試完成的穩定版本提交到線上環境交付給使用者。當然對於部署和釋出，每個團隊都可以思考自己的定義。例如我們進一步的細化部署和釋出的行為，可以劃分為部署測試環境、部署線上環境、部署回滾、釋出灰度、釋出灰度監控、釋出全量、釋出回滾、釋出監控等等。下面主要介紹外賣業務在部署釋出中，建設的業務事務流和無人灰度監控。
3.6.1 釋出事務流
釋出在整個交付過程中是最重要的一環，而這個環節涉及的角色主要是RD和QA。我們需要明確的定義這個環節RD和QA的事務，避免角色間溝通不暢，跨角色的任務不清的問題。外賣通過持續的優化流程，明確流程的操作行為，來監督流程的正常執行，形成當前的事務流，如下圖所示：
這裡需要重點講解圖中的關鍵點：
事務流中，RD負責交付程式碼到測試環境，QA同學負責測試環境的和線上環境的驗證。RD和QA角色按照時間順序，各自前面工作和後面工作，事項歸屬清晰明確。流程中設定TL Approve和QA Approve。同時RD作為程式碼的完成者，只具備測試環境的部署許可權，最終線上的許可權由QA掌控，做到了上線的雙角色Check，避免了RD即是“裁判員”又是“運動員”的情況。當完成測試時候，部署線上環境和線上環境釋出，都做到自動執行，通過自動化的手段節約重複的工作。3.6.2 無人值守灰度
一個功能上線，往往要經歷灰度到全量的過程。由於灰度已經是到了交付到使用者手上的最終環境，灰度前的檢查和放量都非常重要，需要做到萬無一失。灰度的次數往往是全量次數的2~3倍，這使得灰度的成本在整個交付流程中也變得非常高。理想情況下，我們希望釋出前的流程都做到自動化，灰度的過程，也無需人工參與，自動的放量、停灰、全量，出現異常自動執行灰度SOP、監控項也在灰度的時候自動開啟，出現異常自動同步資訊給相關方。但在實際過程中，由於平臺的差異，部分環節還是很難做到，例如iOS的釋出。下圖是外賣業務無人值守灰度的流程：
其中幾個關鍵點：
起始點來源於我們錄入的GulfStream日期。由於雙週迭代後，版本的迭代週期是可預期的，所以能夠以季度維度錄入GulfStream中，由此處觸發整個鏈條的啟動。我們利用Tide版本管理系統，將版本的日期自動讀入，在需要釋出的節點前，自動檢查，做好自動化檢查。部分無法自動化的，由Tide系統提醒RD和QA去做檢查。定義好灰度放量策略，在釋出時按照設定策略，自動釋出放量。外賣業務非常複雜，監控的內容也很複雜，對這個環節不是很熟悉的同學，是很難勝任監控運維工作的，自動化更是無法執行。因此外賣的策略是將監控報警標準化，制定SLA，分級別定義監控、報警、預案、執行人，當版本釋出後，觸發監控Job，以分鐘級去CAT（已經開源）、Sniffer、Crash等等平臺去拉取當前灰度版本的資料和定義的指標比較。如果在合理定義範圍內，繼續監控。如果出現異常，大象定向通知相關處理人。這樣使得灰度的自動化監控工作的執行過程是可操作的。4. 外賣持續交付的總結
美團外賣業務，應該建立怎麼樣的模型、配套什麼的技術手段，才可以在更短的週期內，高品質地交付業務，滿足各團隊的發展呢？我們從早期的單月交付，到雙週交付，再到雙週交付結合周交付，我們在不斷地嘗試和演進外賣的持續交付模型。隨著不斷的深入了解，我們發現這是一個很大的話題。到目前為止，美團外賣團隊在這條路上只能算得上是剛剛起步。不過，在實踐的過程中，我們也逐漸地摸索到一些經驗，在此分享一下我們的思考。
4.1 遵循原則
首先我們認為持續交付需要遵循以下的原則。
持續自動化
在我們整個交付的過程中，有大量的工作是會重複進行的，如果我們不能將這些重複的操作逐漸變成自動化，我們就需要頻繁、反覆地去做一些看不到收益，但是又不得不去進行的事情。隨著交付的內容變得越來越多，交付的速度要越來越快，團隊的疲勞感會越來越重，最終疲於奔命。在實際的工作中，由於釋出的形態流程的不標準、生成環境和資料的不一致，我們無法一次性做到所有環節自動化，但這不影響我們先站在全域性去思考，去持續地拆解子問題，將子問題逐漸地變成自動化。隨著整個交付過程的自動化程度不斷提升，整個流程會變得簡單容易，這樣開發人員可以更加聚焦在完成功能本身的工作上。
前置解決
大部分人心理上對於比較麻煩、比較痛苦的事項，都傾向不做或者拖到最後去做。由於存在這樣的心理，如果在交付流程中遇到問題，我們的方案很容易掉到一個陷阱中，傾向保持現狀或延後再處理。但是，對於一個多人協作交付的業務來說，這是非常不可取的，越往後處理，對整個交付的影響越大，處理效率越低下。舉個例子來說，一個PR可能導致一個歷史功能不可用，如果我們在這個同學提這個PR的時候就攔截到，那麼只會影響這個同學，也不需要回溯問題；如果延到程式碼整合環節，那麼就需要想辦法去找到是誰，然後因為什麼原因提這段程式碼，本次整合就可能直接導致失敗，影響其他正在整合的程式碼。如果拖到測試環境，那麼就會涉及至少RD和QA等兩個角色去追尋這個問題。所以在持續交付的過程中，我們儘可能儘早地將問題在剛出現時就解決掉，保障整個交付流水線的通暢。
版本化
在我們持續交付的過程中，要將每個環節儘可能的版本化。不僅僅從程式碼方面版本化，針對資料、配置、環境都可以進一步的版本化。版本化的好處是不言而喻的，首先在實現版本化的過程中，儘可能地將各個環節解耦開，讓環節和環節之間沒有強依賴。當某一個環節出現異常的時候，我們可以很快地降級到無問題的版本，從而保障整個流水線的持續運轉。版本化的另一個好處，就是可回溯，當出現異常的時候，我們可以很快地對比歷史版本和當前版本的差異，縮小範圍，快速的定位問題。
持續反饋
在整個交付的過程中，每個環節都可能出錯。當出錯的時候，需要快速地反饋到相關的負責人。該負責人也需要儘快地將反饋的問題處理，給予一個穩定的版本。如果沒有反饋這個環節，導致了整個交付流水線被阻塞的人，可能完全不知道自己造成了阻塞。另外，在一個功能的交付過程中，可能會有多次提交程式碼、多次整合、多次測試，如果每次是什麼樣的結果，都無法得到反饋，那麼整個交付的風險會逐漸累積。只有將問題更早地反饋、更早地處理，才能有效地降低整個功能交付的風險。
持續分解改進
不管我們當前將整個交付的過程做到了多麼高效，未來隨著業務的發展，組織成員的加入和離開，交付的過程都在逐漸發生衍變。而這個變化，隨著時間的推移，交付的效率又會開始逐漸下降。如果要長久地保持交付效率能夠有持續的改善，我們需要不斷地對抽象的交付過程進行分析，層層剝離，將整個交付過程轉變成一系列小而可以解決的問題，然後持續地解決這些小問題。
不管我們當前將整個交付的過程做到了多麼高效，未來隨著業務的發展，新成員的加入和離開，交付的過程都在逐漸發生衍變。正如《談談持續整合，持續交付，持續部署之間的區別》一文提到的“持續部署是理想的工作流”一樣，想一勞永逸解決所有問題是一種理想的工作狀態。
隨著時間的推移，交付的過程會出現新的問題，交付的效率又會開始逐漸下降。如果要長久地保持交付效率能夠有持續的改善，我們需要不斷地對抽象的交付過程進行分析，層層剝離，將整個交付過程轉變成一系列小而可以解決的問題，然後持續地解決這些小問題。
4.2 關鍵步驟
針對上述原則，我們可以進一步地來指導外賣持續交付中的關鍵過程。通過前文所講，我們認為持續交付就是從產品同學收集到需求，提交到研發團隊，最終形成穩定的產品交給使用者手上的過程，針對這個過程主要細化包括：
提需求
持續交付啟動的第一環對應的就是PM提需求。俗話說“萬事開頭難”，“提需求”看似是一件容易的事情，其實背後是一個非常複雜的問題，涉及到策略選擇、動態規劃、排隊論等一系列的理論。往往在大部分的團隊中，“提需求”被認為是最簡單的事情，這使得整個交付流程後續的工作，無法高效開展。我們細分析下，需求根據大小可以分成大需求、小需求；根據優先順序可以分成高、中、低需求；根據開發的人員不同，又可以分成前端需求、後端需求、策略需求等等。
需求提出來後，怎麼快速地判斷出如何劃分這個需求，需求的優先順序是什麼，需求的上線時間怎麼樣，誰來做這個需求，這個需求會涉及到誰。在涉及到這個需求和其他需求的比較時，才能回答剛才提到的問題，這又涉及到需求的定義，需求產出比的基線問題。在外賣的交付模型中，對於“提需求”，主要遵循的是組織管理原則，即以組織結構為單位，當前組織下的PM給予當前組織下的RD提出需求，需求的優先順序也以當前組織下的事項進行綜合考慮。這樣的好處，不言而喻，比較敏捷。劣勢是當遇到跨組織需求，工作成本會急劇增加。
同時，我們通過交付模型，將提需求的時間點可預見，在每次提需求的環節，嚴格要求每一組織下的需求給予明確的優先順序。每次提出的需求數量、需求評審時長標準化。並且配套標準的需求模板，讓PM在提出需求時，自我完成需求邊界檢查，需求涉及方的前置溝通。通過這樣的組織管理手段、模板管理手段、流程標準化手段，來儘可能地保證提需求的品質。
提程式碼
當單個RD同學認為已經基本完成了功能開發後，就會進入到提程式碼的環節，也可以叫做程式碼整合環節。這個環節是個人行為和整體交付產生對接的環節。在這個環節我們要確保個人的行為不影響整體的流水線的進行。如何保障，我們採用的手段主要是本地檢查+CI檢查+整合測試。當代碼檢查通過後，程式碼的整合是自動完成，無需個人干預。
不過，這裡也存在一個矛盾點，如果本地檢查+CI檢查項+整合測試項越來越多，檢查的時間將會非常長，這將會使得每次提交程式碼變得異常痛苦。而如何解決這個問題？最好的手段，我們認為是通過持續優化程式碼的架構，來讓每次RD的程式碼修改儘可能範圍小。這樣對於有特定範圍的修改，本次CI檢查就存在可簡化的可能性。
部署測試
當完成程式碼整合後，就需要進入到測試環節了。那首先我們需要將程式碼部署到測試環境，因為外賣主要提供App供測試包，所以我們的部署，主要就是打出App包來，周知QA測試。目前外賣的測試，分位一輪新功能測試、二輪全迴歸測試、三輪主流程迴歸測試。新功能因為新引入，可能存在前置條件，而在本次測試的過程中，存在需要編寫自動化用例和人工測試的用例。
但對於老功能，我們希望未來能夠儘可能地採用自動化為主的方式。而在實踐的過程中，我們發現自動化測試的一個很重要的前置條件是，資料和環境的可配置性、穩定性。試想下，資料不穩定，一會返回是空，一會返回不為空，是沒辦法自動化測試校驗的。對於這個問題，目前我們的思路是通過建立各環節下根據標準協議定義的Mock資料，將複雜的全鏈條，拆分成不同節點，在通過配置去控制資料的環境。通過保障每個環節下的品質，來確保整體的品質。
線上監控
保障外賣業務正常線上執行，會需要監控多項的指標。對於如何做好線上監控，我們的思路是設立好各項基線的標準基線，通過指令碼獲取線上的版本，當檢測到新版本，就會自動的建立當前版本的監控。當監控發現線上指標的值和設定的指標基線出現降低時，發生報警行為。而自動化監控最需要考慮的是誤報率的問題。版本的釋出正常通常又會分為2個階段，灰度階段和全量階段。
全量階段量大，比較穩定，誤報率較低。而灰度階段，量小，不穩定，容易出現誤報。而解決這個問題，最好的辦法是，本次灰度對比上一次灰度的指標，而非對比上一次全量的指標，維度一樣，可以有效地減少誤報率。
5. 展望
當前，美團外賣業務仍然處於快速增長階段，建立怎麼樣的流程、配套什麼的技術手段，才能滿足在更短的週期內，高品質地交付業務，進而滿足各個業務的發展呢？毫無疑問，持續交付是解決這個問題的重要一環。但針對持續交付這個主題，美團外賣也算是剛剛起步。
未來我們的建設主要集中在2個方向，精細化運營持續整合和建設自動化測試。如上文所述，隨著業務越來越複雜，涉及的角色越來越多，程式碼整合的管控需更加嚴格，而嚴格的程式碼整合管控將增加團隊成員每次提程式碼的痛苦。如何做到差異化的檢查和准入，將是未來持續整合的建設方向。
我們可以針對不同型別的PR，不同時間節點下的PR，實施不同的差異化定製規則檢查，在合入品質和檢查週期上尋找到一個合適的平衡點。另外對於測試環節，目前美團外賣還是主要集中在人工保障環節，大量的測試Case。我們希望未來能夠儘可能地採用自動化為主的方式進行測試，而讓QA可以集中精力測試新功能或非常邊界異常的場景驗證。
6. 參考文獻
如何理解持續整合、持續交付、持續部署談談持續整合、持續交付、持續部署的區別持續交付2.0：業務引領的DevOps精要作者簡介
曉飛，2015年加入美團，美團外賣團隊技術專家。王鵬，2017年加入美團，美團外賣團隊高階工程師。江偉，2018年加入美團，美團外賣團隊高階工程師。招聘資訊
美團外賣長期招聘Android、iOS、FE高階/資深工程師和技術專家，Base北京、上海、成都，歡迎有興趣的同學投簡歷到[email protected]（郵件標題註明：美團外賣前端團隊）。