在2017在線技術峰會——首屆阿里巴巴研發效能嘉年華上，來自阿里雲研發協同的技術專家懷虎分享了《阿里巴巴1582.73億背後的持續交付如何玩》。他詳細介紹了阿里巴巴的企業級持續交付，從研發參與者的各個角色解析阿里持續交付的流程和環節，並對RDC的理念進行了解析。

以下內容根據直播視頻整理而成。

直播視頻：https://yq.aliyun.com/edu/lesson/547

PDF下載：https://yq.aliyun.com/attachment/download/?id=1840

持續交付的目標

新的業務需要新的應用來承載，所以我們希望能夠快速上線新的應用。有了代碼之後，希望其構建過程是標準的，不需要針對每個環境、應用再去調構建過程。當應用上線之後，需要有新的功能來迭代，功能被提出來之後希望能夠快速高效的完成，並且可以在各個環境中進行驗證，最後可以一鍵發布到線上。

阿里巴巴的企業級持續交付

最開始，阿里巴巴也是使用開源套件的，比如Jenkins，但是逐漸難以滿足需求：不能滿足如此大的規模，資源管理、持續交付在運維的過程中使用Jenkins很難串起來，使用開源套件難以和現有的系統有機結合。所以，研發了自研平台，今年將這套體系推到阿里雲上供阿里雲的用戶使用。RDC和內部平台的核心是一致的，不同的是內部平台有自己的機房，有自己的資源管理方式。但是上雲之後，資料庫、負載均衡等基礎設施都會使用阿里雲上的。

持續交付中有三種角色：開發人員，把需求實現，保證其可以交付上線；開發負責人，團隊建設，保證團隊在指定時間內完成高優先順序的任務；運維人員，負責發布和運維。

開發人員：日常開發feature

開發人員開發一個新的feature需要上圖所示的工作。首先需要拉分支來開發新的功能，然後為分支配置持續集成，開發測試完成之後需要合入集成分支。此時需要從主幹分支拉取release分支出來，把需要合并的一個或者多個分支合并進入。解決衝突的過程中需要對集成分支上部署的版本進行測試，需要為新的分支創建集成分支的配置。測試完成後使用集成分支進行發布到預發環境、線上。最後，再將其合并回主幹。實際上，開發人員需要花時間做的只有開發測試和在集成分支上測試，上圖中除了這兩個步驟，其他步驟都是可以自動化完成的。

這樣流程的好處是能夠靈活掌握開發節奏。分支模式不是真正的數據集成，因為一定要等到所有的東西都集成到一個分支之後才知道是不是可行。即使在一個fetch分支上測試好也不代表集成分支上也能工作。主幹模式是指隨時想做任何變動，則調用某個方法的所有地方都需要做一個改變，主幹模式做這件事情比較簡單，結果可以立即看出，而分支模式則需要集成之後才知道結果。RDC提供了自由模式（一種主幹模式）、分支模式、Git flow模式（所有的用戶都在develop分支上開發，進入之前需要code review來實現）。

自由模式和develop模式有幾個環節：版本製作、日常、預發、灰度。日常和預發之間有一個按鈕用於在製作好之後預發布。

開發人員：可怕的發布

首先，我們需要有充分的測試，包括單元測試、API測試、階段檢查。此外，發明了另外一種測試方法，截取線上的一部分流量進行存儲，在預發環境進行回放，看結果是否一致。人工的代碼review更多涉及到代碼架構，所以希望每次的代碼提交都能經過代碼review過程。靈活的發布工具也很重要，規模小的時候怎麼發布都可以，但是當規模比較大時靈活發布很重要。發布方式目前支持分批發布，分布策略可以根據分組、機房來分。

發布一定要是可靠的，一定是可重複的，一個包發100次一定是同樣的結果。如果發布之後發現線上有問題，則需要回滾代碼，只需要把發了的部分進行回滾即可。回滾包括發布中回滾和發布後回滾。所有的過程一定要減少人為的介入，讓這些都自動化的發生，所以希望有一個流程和卡點，如果不滿足此刻要求就不能繼續往下走。

發布的問題總結來說：使用單元測試，功能測試，介面測試等多層保護；通過系統卡點的方式保證上述測試真的被執行，且真正有效；提供靈活，可靠的發布方案；提供靈活，可靠的回滾方案；使用和線上的環境進行測試（預發）。

開發人員：定位問題

定位問題花費的時間往往比編碼還要多，問題可能出現在測試環境，也可能出現在線上。線上版本和上次發布之間有哪些變化？這些都要考慮清楚才能進一步定位問題。

平台有統一的流程將這些問題記錄下來：創建分支，提交集成區，提交發布。在這樣整個標準的變更流程中，會把很多信息記錄下來。上圖中的列表是一個發布的列表，包括發布內容、發布結果、操作人、版本詳情等內容。所有信息都可以幫助追溯之前發生的事情，並且進行問題解決。

運維人員：線上變更充滿危險

最初的時候採用了腳本批量執行，後來使用了聲明式的基線管理，但是還是難以避免線上的基線被人手工篡改，而且不能保證基線變更失敗後如何處理。2016年開始，阿里使用Docker容器鏡像，問題變得迎刃而解，因為每次部署的都是新的鏡像，環境保證一模一樣。Docker化基礎設施是在阿里內部的，而RDC在阿里雲上怎麼辦？我們會去對接阿里雲上的基礎設施、已有服務，使用其整個服務來對接前面RDC的研發。

RDC發源於阿里內部，紮根於阿里雲，後面所有的生態建設都會圍繞阿里雲已有的生態來建設。上圖中，企業入駐RDC企業級研發協同平台後就可以享受整個阿里雲的基礎設施。EDAS也是阿里雲正在做的事情，ECS、SLB等資源也可以通過RDC進行整合。

RDC是一個SaaS產品，不是私有雲產品。由於沒有部署到機房裡，所以它可能訪問不到VPC裡面的機器，但是有時卻有這樣的需求。有時需要做預發、API測試，這些需要在公網裡進行，但是公網卻沒有訪問許可權。目前的一個可行方案是，可以通過代理享受更多的服務。

上圖中藍色部分是已經發布上線的。構建和發布目前是基於關聯ECS並且自定義腳本的方式來發布。EDAS和容器正在對接。

這樣，開發過程的角色會有一定的轉變。企業的現狀是，有開發會做本地、測試環境的編碼和日常測試，有專門的測試在QA環境進行功能驗證，有運維去專門管理staging環境和正式環境。DevOps是開發自運維，運維人員做好了很好的平台，開發可以進行測試，可以從發布流水線收到反饋，自己去編寫測試用例，做新應用的發布上線，做日常功能的開發、線上變更、擴容縮容、線上故障處理。

總結

RDC的理念是自動化一切可以自動化的事情，提供盡量多的模式，有安全、靈活的發布流程，使用工具流程來保證開發團隊按照最佳實踐工作，對開發過程的數據提供足夠的可追溯性，依託阿里雲基礎設施，助力企業的Devops。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！