2017年5月9日，雲效平台資深研發工程師向禹通過直播分享了《持續集成與持續交付實踐之路》。他從雲效背景、雲效方案、雲效價值三個方面進行了分享。他主要分享了持續集成持續交付的解決方案和案例，並且對大型系統如何實現持續集成、持續交付、進行產品迭代發布進行了詳細介紹。

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

雲效背景——阿里巴巴《持續交付》之路

大應用下的交付

在七八年之前，阿里巴巴的B2B一直沿用瀑布的模式來進行項目管理，當時已經感覺到瀑布模式對應用持續快速的發展產生了很大的影響。並且當時很多的應用都是以大應用的方式來開發的，一個應用可能有幾十萬行、上百萬行代碼量，如果此時進行小的功能點的修改會比較麻煩。改了幾行代碼，花費幾個小時進行編譯打包，發布到測試環境上去，運行全網的自動化回歸（積累了兩千多個自動化腳本，總共幾萬行）也非常耗時，降低了開發效率。所以，當時開始準備把大應用進行服務化的拆分，將大應用的邏輯拆分成了會員中心、產品中心、訂單中心、交易中心等服務化模塊，每個模塊下面又有微服務來支撐。

做完第一步改造之後，又遇到一些問題，最明顯的是環境上的問題。每一家公司環境管理的方式是類似的，都會劃分為開發環境、測試環境、集成環境以及線上的生產環境。微服務化之後，在開發環境下，由於應用變多，調用鏈路變得更加複雜，很難保證整個環境中所有應用的穩定性。問題難以排查，修改程序之後，很難判斷是應用出現問題還是鏈路出現問題。在集成環境，為了保證穩定性，規定了每周的交付窗口時間，將所有項目代碼合成到集成分支上，編譯打包部署到集成環境中，運行全網自動化回歸腳本。如果出現問題，排查比較麻煩，首先判斷是哪一個應用引起的問題，然後再細分到項目組進行排查，修改後重新交付測試。

既然現在已經是微服務了，是否可以跳過集成環境，在開發測試環境將應用完善測試好？經過嘗試發現，即使在開發測試環境將某個要發布應用的所有功能測得再詳細，也很難保證應用上面的鏈路和下面的鏈路的業務邏輯都是正常的。

自動化

如果僅僅通過開發方式的轉變是沒有辦法很好的完成持續集成、持續交付的理念。我們應該創造一個持續集成、持續交付的自動化平台來保證在每個環節裡面效率的提升，以及整個鏈路的打通。

上圖是我們在平台上解決的核心問題：並發項目配管方案，在並發項目很多的時候需要進行代碼分支的管理；持續部署方案也是需要解決的核心問題；持續驗證方案，在持續部署之後要快速進行驗證，如果用手工的方式是不現實的；通過持續部署和持續驗證達到持續交付的目標；為了讓各個團隊更好的適應角色的變化、使用平台來提高效率，提出了落地使用推廣方案。

雲效方案——核心解決方案內容

針對需要解決的問題，我們所建設平台核心的原則是核心化、流程化、自動化，希望能夠建立持續部署的流程、代碼管理的流程，通過自動化的方式實現出來。在上述基礎上，雲效平台建立了配置管理、持續集成、持續交付等相關子系統。通過這些子系統，創造了可靠、可重複的交付流水線。此外，與項目管理進行結合，開發的效率很好的沉澱到了平台上，在平台上建了與項目管理相關的一些子系統，將其數據打通就能達到業務和產品的相互促進。多個角色的團隊都會在平台上用相關的系統來進行相互工作上的協作，所以對組織和團隊的協作也產生了促進作用。雲效平台在內部是部署在專有雲平台上，對於託管的應用支持EDAS/Dubbo分散式服務化架構、SpringBoot微服務架構、Docker容器化架構。

並發項目配管方案——SCM管理

並發項目配管方案即項目分支管理方案。很多公司在開發一個項目的時候會首先由相關的PM或者運維人員拉出來一個分支交給開發人員。為了簡化上述過程，在平台上提供了開發人員直接拉取分支的功能。如上圖所示，項目1和項目2同時進行開發，分別拉取了V1.0的分支。如果項目1提前開發完成，就會觸發提交集成的操作，會把項目1最新的分支代碼重新拉出來一個集成分支，把主幹代碼合成到集成分支中，針對集成分支進行編譯打包，自動部署到集成的測試環境中。在集成環境運行雲效的測試用例，如果沒有問題就合併回主幹。

持續部署方案-環境管理

每個公司都有相同的環境建設方式，包括開發環境、測試環境、集成環境。為了規避開發環境不穩定的情況，摒棄了各種環境的概念，在雲效平台上劃分為了公共環境和功能環境。公共環境可以認為和線上服務的環境一致，是由線上同步回來的，不需要人為手工參與部署。測試時，如上圖需求1，每個項目組根據項目開發的應用在雲效平台上申請一台伺服器，通過雲效一鍵部署的功能把應用部署到伺服器上去，如果需要調用其他伺服器，則通過服務化路由的方式路由到其他伺服器上。針對每個項目組來說，他們都可以認為自己有一個獨立的、供他們使用的測試環境，互相之間沒有相互的干擾。對於服務化自動路由，各個系統間相互調用的方式有HTTP、RPC、HSF、Dubbo框架等，使用HTTP的話可以利用本機host綁定達到路由效果，可以使用雲效平台自動託管；如果使用Dubbo和HSF，則有一些註冊中心和路由規則，可以在本地部署伺服器上直接生成HSF的路由文件，動態改變服務的路由。

分層自動化

在測試環節，傾向於認為沒有某一種的測試方式能從效率、質量達到一個很好的平衡，涵蓋所有測試的業務邏輯。如果把所有的功能都通過UI自動化實現的話，UI自動化的創建、維護成本很高，穩定性也有一定問題。建議在不同的業務層次使用不同的、適合的測試環境。在方法層面，檢測方法是否有問題，可以利用單元測試來進行。介面則可以通過服務化介面測試來涵蓋，再往上更長流程的業務邏輯可以通過界面自動化測試來實現。很少一部分的測試場景通過自動化的方式是沒法實現的，只能通過手工的方式來實現。

單元測試

在分支上進行提交的時候，每一次後台都會及時檢測到觸發提交後針對最新代碼的編譯、單元測試、代碼掃描。平台掃描的結果會及時通過郵件反饋到開發人員，相關的數據也會沉澱到系統上。在雲效平台上，阻塞問題是最嚴重的問題，通過提示信息可以方便開發人員及時進行相關排查。

服務化介面測試

在雲效平台上，所有的自動化測試都希望不寫代碼，直接在頁面上配置，通過最直觀的方式進行。介面測試方面，如果是HTTP介面，則會直接在頁面上輸入需要測試介面的地址、入參、出參的校驗規則；如果是Dubbo或者HFS介面，則需要寫單元測試用例啟動一個容器才能進行相關的測試。為了減輕寫單元測試的工作，在雲效平台上，可以解析到某一個jar包里的介面，只需要指定針對Dubbo介面往哪一個IP服務上發送相關請求，平台會自動生成相關的一些測試用例，把入參進行傳遞，把出參進行校驗。

雲效價值——實際效果與客戶案例

在阿里巴巴內部，雲效平台是從2012年開始建設，當初開發測試的配比大約是3:1，到2015年提高到了6:1，目前已經接近8:1。由於業務在持續快速的發展，在平台的保障下，歷年故障數有明顯的下降，集成驗證發布耗時也有顯著縮減。有了平台上自動化工具的保證，50%的小需求不需要進行測試。也沒有了發布窗口的限制，隨時可以發布。

對於外部客戶來說，現在使用雲效的客戶也有不少，比如眾安保險、五礦電商、紅嶺創投等，主要使用的是環境部署、自動化集成、自動化用例的建設，大大提升了企業研發效率。