2017年5月9日，雲效平台資深研發工程師向禹通過直播分享了《持續內建與持續傳遞實踐之路》。他從雲效背景、雲效方案、雲效價值三個方面進行了分享。他主要分享了持續內建持續傳遞的解決方案和案例，并且對大型系統如何實作持續內建、持續傳遞、進行産品疊代釋出進行了詳細介紹。
以下内容根據直播視訊整理而成。
在七八年之前，阿裡巴巴的b2b一直沿用瀑布的模式來進行項目管理，當時已經感覺到瀑布模式對應用持續快速的發展産生了很大的影響。并且當時很多的應用都是以大應用的方式來開發的，一個應用可能有幾十萬行、上百萬行代碼量，如果此時進行小的功能點的修改會比較麻煩。改了幾行代碼，花費幾個小時進行編譯打包，釋出到測試環境上去，運作全網的自動化回歸（積累了兩千多個自動化腳本，總共幾萬行）也非常耗時，降低了開發效率。是以，當時開始準備把大應用進行服務化的拆分，将大應用的邏輯拆分成了會員中心、産品中心、訂單中心、交易中心等服務化子產品，每個子產品下面又有微服務來支撐。
做完第一步改造之後，又遇到一些問題，最明顯的是環境上的問題。每一家公司環境管理的方式是類似的，都會劃分為開發環境、測試環境、內建環境以及線上的生産環境。微服務化之後，在開發環境下，由于應用變多，調用鍊路變得更加複雜，很難保證整個環境中所有應用的穩定性。問題難以排查，修改程式之後，很難判斷是應用出現問題還是鍊路出現問題。在內建環境，為了保證穩定性，規定了每周的傳遞視窗時間，将所有項目代碼合成到內建分支上，編譯打包部署到內建環境中，運作全網自動化回歸腳本。如果出現問題，排查比較麻煩，首先判斷是哪一個應用引起的問題，然後再細分到項目組進行排查，修改後重新傳遞測試。
既然現在已經是微服務了，是否可以跳過內建環境，在開發測試環境将應用完善測試好？經過嘗試發現，即使在開發測試環境将某個要釋出應用的所有功能測得再詳細，也很難保證應用上面的鍊路和下面的鍊路的業務邏輯都是正常的。
如果僅僅通過開發方式的轉變是沒有辦法很好的完成持續內建、持續傳遞的理念。我們應該創造一個持續內建、持續傳遞的自動化平台來保證在每個環節裡面效率的提升，以及整個鍊路的打通。
上圖是我們在平台上解決的核心問題：并發項目配管方案，在并發項目很多的時候需要進行代碼分支的管理；持續部署方案也是需要解決的核心問題；持續驗證方案，在持續部署之後要快速進行驗證，如果用手工的方式是不現實的；通過持續部署和持續驗證達到持續傳遞的目标；為了讓各個團隊更好的适應角色的變化、使用平台來提高效率，提出了落地使用推廣方案。
針對需要解決的問題，我們所建設平台核心的原則是核心化、流程化、自動化，希望能夠建立持續部署的流程、代碼管理的流程，通過自動化的方式實作出來。在上述基礎上，雲效平台建立了配置管理、持續內建、持續傳遞等相關子系統。通過這些子系統，創造了可靠、可重複的傳遞流水線。此外，與項目管理進行結合，開發的效率很好的沉澱到了平台上，在平台上建了與項目管理相關的一些子系統，将其資料打通就能達到業務和産品的互相促進。多個角色的團隊都會在平台上用相關的系統來進行互相工作上的協作，是以對組織和團隊的協作也産生了促進作用。雲效平台在内部是部署在專有雲平台上，對于托管的應用支援edas/dubbo分布式服務化架構、springboot微服務架構、docker容器化架構。
并發項目配管方案即項目分支管理方案。很多公司在開發一個項目的時候會首先由相關的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%的小需求不需要進行測試。也沒有了釋出視窗的限制，随時可以釋出。
對于外部客戶來說，現在使用雲效的客戶也有不少，比如衆安保險、五礦電商、紅嶺創投等，主要使用的是環境部署、自動化內建、自動化用例的建設，大大提升了企業研發效率。