<b>作者簡介</b>：<b>魯小川</b>，09年大學畢業于浙江大學軟體學院，之後就一直就職于阿裡巴巴b2b品質保障部，目前是雲效持續內建與持續傳遞解決方案的負責人。
<b></b>
<b>以下内容根據演講嘉賓分享以及ppt整理而成。</b>
今天分享的議題是《超大型系統的持續內建與持續傳遞解決方案及案例分析》，主要就是和大家聊聊阿裡巴巴b2b技術部這幾年來在持續內建與持續傳遞上實踐經驗，以及為什麼要做宙斯盾系統平台産品來支撐持續傳遞。宙斯盾平台在阿裡内部經過了5年多的積累沉澱，現在已經對外服務輸出了，對外服務産品的名字叫做雲效平台，後面還會介紹雲效平台的解決方案，以及真實客戶的案例分析。隻要是在做it行業、網際網路行業技術相關的同學，應該都可以通過本次分享有所收獲。
<b>本次分享的目錄</b>
一、持續內建與持續傳遞的背景
二、持續傳遞解決方案的演變
三、自動化驗證—創新高效的自動化支撐
四、雲效産品架構及應用架構
五、雲效解決方案及案例分析
首先會給大家介紹下持續內建與持續傳遞的背景，以及阿裡自己對持續內建與持續傳遞的了解。然後會為大家分享阿裡持續傳遞解決方案的演變過程，和阿裡巴巴b2b做持續傳遞的實踐。接下來給大家介紹一下持續內建與持續傳遞中的自動化，讓大家一起來看看自動化到底是不是測試的銀彈，是否能幫助我們提升效率。最後兩部分就和雲效相關了，為大家介紹一下雲效産品架構以及應用架構，以及雲效解決方案和真實客戶的案例分析。
<b>一、持續內建與持續傳遞的背景</b>
首先來看什麼是持續內建。大師martin fowler，靈活開發方法的創始人之一，提出的靈活開發方法是一種思想，可以為軟體的研發提供指導性的建議。而持續內建則是靈活開發具體實踐的一個建議環節，通過這個環節可以在研發過程中快速得到代碼品質的回報。fowler對持續內建是這樣定義的：持續內建是一種軟體開發實踐，即團隊開發成員經常內建他們的工作，通常每個成員每天至少內建一次，也就意味着每天可能會發生多次內建。每次內建都通過自動化的建構（包括編譯，部署，自動化測試)來驗證，進而盡快地發現內建錯誤。自動化建構驗證可以大大減少內建的問題，讓團隊能夠更快的開發内聚的軟體。
從下圖我們可以更好的了解持續內建的工作模式，就是開發人員将代碼check in到source repository代碼倉庫以後，ci server，也就是持續內建伺服器，會對代碼工程進行工程編譯，靜态掃描，單元測試，元件接口測試以及安全掃描等等一些列建構工作，最終産生一份報告回報給開發人員。可以看到如果針對每次check in做內建，這個內建的頻率會非常高，特别是對于有一定研發團隊規模的公司，至少我們自己團隊以前在業務壓力比較大，涉及子產品比較多的時候，可能送出得比較頻繁，甚至在未正式進行送出測試之前，連編譯不通過的代碼也可以送出。可以根據內建的耗時來設定不同的內建頻率，比如說工程編譯、靜态掃描、單元測試都會比較快等，對他們設定內建的頻率可能就會比較高，而對于需要部署并執行更多的自動化，耗時就會更多些，內建頻率就會更低一些，注意這裡的部署都會是在內建伺服器上來完成的，是比較輕量級的啟動，并沒有進行真實環境的部署。無論以哪種頻率內建，其實都希望它能夠快速、準确并且穩定地完成。快速回報就是靈活所提倡的，而真正大規模的持續內建，如果不夠準确穩定，開發人員就會疲于處理報告中的問題，而內建伺服器壓力也會非常大。
再來看一下持續傳遞的背景，持續傳遞(continuous delivery)是一系列的開發實踐方法，用來確定讓代碼能夠快速、安全的部署到産品環境中，它通過将每一次改動都送出到一個模拟産品環境中，使用嚴格的自動化測試，來確定業務應用和服務能符合預期。因為使用完全的自動化過程來把每個變更自動的送出到測試環境中，是以當業務開發完成時，開發者隻需要按一次按鈕就能将應用安全的部署到産品環境中。
從下圖大家也能看到持續傳遞和持續內建的差別，其實持續傳遞包含了持續內建的過程，額外還需要将程式的包真正部署到模拟産品環境的伺服器上，進行更為嚴格的自動化測試，可能有ui互動級别的自動化，有遠端服務接口級别的自動化等。持續傳遞并不是指軟體每一個改動都要盡快的部署到産品環境中。它指的是任何的修改都已證明可以在任何時候實施部署。
既然持續傳遞包含了持續內建，後面就針對持續傳遞做進一步的分享。
本次分享對持續內建與持續傳遞的定義：在24小時系統中任何應用（一個應用就是一個可部署的包）随時送出釋出并在較短時間内(1-2小時)完成獨立驗證并釋出上線，而沒有釋出視窗限制。
從圖中可以看到，從應用代碼變更到測試環境部署驗證，再到內建環境或者準生産環境部署驗證最後再到生産環境，我們期望通過自動化進行快速進行釋出。這其中的兩個方案非常的重要，一個是內建環境自動化部署的解決方案，無論面對多大規模的系統，如果想要單獨快速的釋出一個應用，并且對這個應用進行有效的驗證，內建測試環境的自動化部署方案就非常重要，現在的系統往往都會涉及到幾十個應用，如果每次內建都需要全部部署，驗證所有功能，1到2小時肯定是無法完成的。另外對于分層自動化測試的解決方案，同樣的要求就是需要分層自動化能快速有效的對要釋出的應用進行驗證，并且需要非常高效。自動化的天敵就是變更或者變化，一旦有變化就需要對自動化進行維護，如果采用傳統編寫腳本的自動化方案，開發人員往往要維護大量的腳本，另外要做持續傳遞疊代就會非常的快，并且變化也大，自動化解決方案需要跟得上快速疊代變化的節奏。
<b>二、持續傳遞解決方案的演變</b>
在大緻了解背景後，來看一下阿裡巴巴持續傳遞解決方案的演變過程以及阿裡b2b的一些實踐經驗。
相比傳統工業的工程，軟體工程誕生得比較晚，是以當軟體工程規模化之後，也會參考傳統行業的工程流程，通過瀑布式的流程及相關變形的研發模式，來協同軟體工程項目中各個角色。這樣的流程有一個非常明顯的缺點就是一次項目釋出周期非常長，存在非常多的環節，并且每一個環節都會有嚴謹的評審來保障這一環節的品質。
<b>企業研發模式的變遷</b>
自從網際網路誕生起，特别是b/s的模式通過浏覽器統一了用戶端之後，軟體的釋出隻需要釋出服務端就可以快速提供服務，傳統瀑布研發模式逐漸無法支撐網際網路所需要快速釋出，是以軟體研發模式逐漸演進到了靈活研發模式。靈活研發模式弱化了流程，強調了溝通與回報，在實踐的時候我們發現在小規模團隊中靈活研發運作還可以提升效率，但是在較大規模團隊中仿佛就失去了它應有的一些光彩，如果一個100-200人研發團隊的公司在全體實施靈活而沒有相關工具支撐的話，互相的協同、溝通以及研發測試工作反而會更耗時，同時也無法召開100到200人的靈活會議。是以基于此我們演進到了持續傳遞的模式，持續傳遞強調使用者的回報和體驗，開發者希望能将産品盡可能快地傳遞到客戶手中。
<b>瀑布式研發模式</b>
大家在剛加入工作時，主管會讓你背一張圖，也就是項目工程圖，這張圖包含了軟體瀑布式研發模式的各個環節。從需求分析到用例模組化再到需求評審，之後軟體開發工程師會介入進行概要設計，測試同學也會介入進行測試分析，将用例模型轉化成測試模型，之後就可以進入開發的編碼階段，編碼完成之後就會交給測試人員進行測試，測試完成之後會進行釋出評審之後還進行預釋出，釋出之後還要進行釋出的跟蹤。所有的這些工作都是通過郵件和文檔以及各個工具的平台支撐的，因為每個過程都要依靠文檔，當某些地方發生變化的時候，需要文檔疊代釋出非常迅速，因為業務也需要小步快跑，是以文檔也會在各個人員之間傳來傳去，項目流程進度、人力資源把控、項目品質保證等所有活動全靠人肉（通訊基本靠吼）。
<b>靈活研發模式</b>
在2010年以後，我們開始嘗試靈活研發模式。靈活研發模式，就是某一個小團隊針對客戶市場會調研出一些需求，之後會對這些需求進行快速的疊代跟進，産品負責人會根據産品的創意、功能以及需求做成一個産品功能清單，小團隊會針對這樣的一個功能表進行疊代任務的拆分和研發實施。實施的過程基本上就是通過小團隊進行每日例會以及其他方式的溝通進行協作，送出代碼之後也會進行一些內建，內建完成之後，代碼就會形成一個可部署的包，之後就可以釋出到線上，這樣小團隊就可以靈活地實作小塊的業務。
我們在探索靈活研發過程時也遇到了一些問題，将一個小團隊的最佳實踐推廣到其他團隊的時候往往就會遇到非常多的阻礙。比方說一個需求可能涉及到許多團隊進行協同開發，這個項目的規模可能涉及到上百人，但是對于幾百人想要實作靈活開發中的每日例會将是不可能的事情。另外一個問題就是靈活部署，對于小團隊而言，程式可以非常容易地在自己團隊的機器上進行部署，但是對于大型項目而言，往往在聯調的時候需要很多團隊進行協作，需要保證參與各方的環境都是穩定的，這種場景下靈活研發模式往往不能發揮出其優勢。
<b>持續傳遞的演變-階段1</b>
雖然靈活研發在較大規模情況下難以實施，但還是可以依靠平台進行持續傳遞的。下圖是大多數公司采取的大型的內建方案，在這個方案中會設定一個固定時間的視窗，代碼會從開發環境到內建測試環境，通過一整套內建測試的驗證之後将程式釋出到生産環境。但是會因為釋出周期比較長，導緻研發速度比較慢。可以看到，圖的左邊是一個個研發的代碼分支，每天都會有新代碼進行內建合并，合并完成之後會約定時間手工部署到內建測試環境上去，之後對于整套環境進行手工測試驗證。當然，在這其中還會有許多的自動化測試腳本去進行驗證。圖中內建測試環境下的各個代碼分支之間的連線代表需要這幾個分支共同提供服務才能進行自動化的驗證。是以這樣的內建測試方案必然會對于釋出時間進行限制，需要将全部的内容都驗證通過之後才能進行統一的釋出。<b></b>
<b>這樣就出現了一些問題：</b>
研發疊代速度慢，業務釋出周期長。
內建測試環境不穩定，每天都會有新代碼合并進來，并且還會有緊急需求代碼的穿插，難以得到有效驗證。
測試效率低，負責需求的測試随時可能被沖掉，是以每次更新都需要全部測試一遍。
自動化測試腳本的誤報率高，由于執行全網回歸腳本多，回歸時間長，排查問題難。
<b>持續傳遞的演變-階段2</b>
因為內建環境還是不穩定，是以可以在其上增加多套測試環境。在持續傳遞的演變的第二階段，就在內建測試之前加上了項目需求測試環境。隻有在通過了項目需求測試之後才能夠進入到內建測試環境，而後面的整體流程不變，如此可以保證內建測試環境的穩定性。但是與此同時測試環境就更加複雜，不僅要不斷驗證內建測試環境中代碼的品質，還需要保證項目需求的品質，是以說在第二階段也隻是保障了內建測試環境的穩定性，并沒有解決釋出視窗的時間限制，可能還是需要進行全網回歸測試。
<b>持續內建與持續傳遞的關鍵點-自動化測試的解耦</b>
持續內建與持續傳遞的關鍵點就是自動化測試的解耦。測試某個場景确實需要一些環境都部署好的時候，如果想要快速疊代釋出就需要運作全網的回歸測試。但是通過自動化測試的解耦方式就會好很多，比方說需要将全網的場景都耦合起來進行測試，為了保證環境的穩定，可以從應用的次元去解耦自動化的腳本，這樣就可以将自動化測試定義成為套件。
<b>雲效-持續傳遞實作原理</b>
為什麼雲效平台能夠做到所有應用随時提測并釋出，并且無釋出視窗限制呢？其實是因為我們擁有預釋出內建測試環境，在半個小時内就能完成自動化測試并且不需要人員進行值守。舉例說明，如果自動化測試套件解耦的效果比較好的話，比方說某個測試套件隻測試abcd四個套件，這四個套件作為一個小組。如果此時某個項目改動了c，之後就會在內建環境進行自動部署，部署完成之後會鎖定abcd釋出隊列，當內建測試和手工驗證通過之後才會将c釋出到正式的生産環境，其他的分組的處理流程也是一樣，不需要進行全網回歸，而且隻有小組内的子產品變化時需要進行排隊變更，這樣的運作時間也會大大縮短，基本上沒有任何的釋出視窗的限制，可以實作随到随發。
對于自動化測試環境的核心點，比方說在部署abcd四個測試套件的環境的時候，如何保證測試環境和生産環境是一樣的呢？首先對于環境類型管理，測試環境可以人工一鍵自動部署，核心部分存在公共環境，這個公共環境的部署包是與生産環境的包保持一緻的，并且這個公共環境沒有人員進行手工部署，而是進行自動部署的。對于項目環境的部署而言，項目環境的部署是從動态伺服器資源池動态地擷取伺服器資源，之後進行動态的一鍵部署，這個過程有可能會依賴公共環境，而公共環境與生産環境的包的一緻能確定測試的有效性，對于分圈應用也是一樣的。
這裡當然也會存在一些問題需要解決，目前網際網路上往往會有一些遠端服務化的方案，假如abc之間是存在依賴的，a需要調用b的服務化接口，b也要調用c的服務化接口，而對于預設部署的公共環境而言，a将會調用公共環境的b進而調用公共環境的c，當需求中改變了a，此時會向動态伺服器資源池中申請一台伺服器來部署a'，當需要時a'會連接配接公共環境的b和c，這樣在釋出時不改動其他隻改動a就可以了。而對于另外一種場景就是同時修改了abc，但是由于服務架構的負載均衡會導緻項目環境無法進行有效的測試。在整個核心解決方案中，存在一個服務化的自動路由，這樣就可以保證項目内部調用的有效測試。
<b>三、自動化驗證—創新高效的自動化支撐</b>
在網際網路時代，對于網站而言，頁面的變化是非常快的，這時候就需要高效的自動化測試進行支撐。
那麼自動化測試到底是不是銀彈呢？在業界有一個這樣的自動化測試的金字塔模型，可以看到從頂層的使用者界面的測試，到api層面的驗收測試再到單元測試群組件測試。在金字塔模型中越往下的成本就越低，同時的效率也就越高，并且缺陷也就越容易定位；而從下向上則越來越接近業務，越來越能反映真實的需求。如果ui自動化測試工具的成本和效率比單元測試更低的話，在測試層面可以做成倒三角模型，使得使用者界面層測試既貼近使用者需求和業務也能夠非常的高效，是以需要創新高效的工具支援測試的自動化的實作。
接下來分享一下阿裡在自動化測試産品方面的創新。對于自動化測試而言，會存在自動化成本。這個<b>自動化成本=腳本建立成本+維護次數×維護調試成本+腳本失敗次數×腳本排錯成本</b>，而<b>自動化收益=有效疊代次數×手工測試成本</b>。業界通常通過錄制生成腳本代替手工編寫腳本，但是也同時出現了一些問題，就是錄制生成腳本是由機器自動産生的，不同團隊之間寫作和維護成本也會很高。是以我們得出一個結論，通過寫腳本的方式是無法收回持續內建測試的成本的。
而通過雲效-aui錄制代替寫腳本的方式，就避免了團隊之間的代碼互相維護以及由于業務邏輯的不熟悉造成的困擾，這樣可以很清楚地讓團隊之間看到每個案例是怎樣的，可以在短短幾分鐘之内就完成對于腳本代碼的維護。雲效aui産品解決了以往ui自動化測試成本高，難維護的核心問題，提升了效率，并且解決了一次錄制，多浏覽器執行的問題。
回想剛才的金字塔，如果工具能幫助我們投入較小的成本來保證更高的品質，那麼就沒有必要一定要建構這樣的金字塔的模型。
從項目一生看持續內建的排程，當有項目需要開發，可以在雲效平台上拉一個變更的分支，在平台上還可以添加項目開發成員。之後就可以對于該分支進行開發編碼，以及代碼的送出，在完成代碼送出之後幾分鐘之内就會收到一封關于項目代碼情況的郵件提醒，包括單元測試的建構結果以及覆寫率等代碼的詳細情況都會回報給送出者，這樣就減少了單元測試的成本，并且由于不依賴本地環境使得單元測試的複用成本降低，而且提供了資料采集的看闆，可以很友善地看到團隊自己的測試資料。
在完成品質測試之後，雲效平台還提供了一鍵部署的環境，并且可以實時檢視部署的日志。雲效平台還提供了制造資料的功能，當環境部署成功之後可能需要一些資料來支撐測試，是以雲效平台提供了資料銀行來制造資料，并且提供了豐富的制造資料的方式。而且對于資料制造而言，不光是自動化測試需要，手工測試也需要。另一方面，雲效平台的用例系統和普通的用例系統有所不同，雲效平台的用例系統會區分主幹用例和項目用例，這與網際網路分支開發模式有些類似，存在一個穩定的主幹，當有新的業務需求之後，往往會通過新的分支進行開發。對于用例系統而言，往往會有一些很核心的業務，基本上不會有太大的改動，是以對應的就會有一些主幹用例，在項目中可以複用，而對于項目中新産生的用例則可以在項目釋出之後可以歸庫以友善其他人使用。
可以看到整個持續內建排程平台amon，日建構內建能夠達到10萬+，并且擁有大量的節點，可以支撐大規模的內建子產品。
通過看闆可以看到一個應用的整個內建自動化釋出過程，這樣的內建自動化給了開發人員極大的信心。
有了平台支撐之後，整個持續內建和持續傳遞的研發工作有了很大的轉變。
下圖是在阿裡巴巴内部整個宙斯盾平台落地的效果，可以看到研發測試比逐年提升，目前基本上達到了1:7.5，這樣更多的開發資源可以投入在産品研發上，來支撐業務快速發展。測試資源通過高效的自動化工具産品，提供分層自動化測試套件進行自動內建。目前50%的需求會由測試接手進行一些手工的測試，而另外的50%則是由開發人員進行的自測，因為平台已經提供了非常友善和快捷的研發測試方式，很多功能隻需要一鍵部署申請，是以對于開發人員而言測試工作也是非常簡單和高效的。而業務技術團隊隻需要判斷是否需要測試人員接手人工測試。對于測試同學而言的要求是可以有不經過手工測試的需求釋出上線，但是不能沒有品質資料監控的需求釋出上線，這些資料都将在釋出前上傳到雲效平台上。雖然測試人員的比重并沒有增加，但是線上故障逐年下降，并且品質有所保障，業務釋出頻率也是飛速增長。
<b>四、雲效産品架構及應用架構</b>
宙斯盾對外輸出稱為雲效平台。雲效平台提出了一個理念就是産品需求研發閉環，其實雲效平台的目标并不在于一定要去支撐靈活開發，因為雲效平台不是一個單純支撐靈活開發的工具，因為對于一些規模比較大的團隊而言，靈活開發方式可能比較難以實施，其實雲效平台想做是持續傳遞。想要實作持續傳遞的一個理念就是實作産品需求和研發的閉環，從需求開始可以依靠平台進行快速的建立和審批，再到對于項目和任務的管理，如此形成産品的閉環。在開發階段，雲效平台會提供一些配置管理的工具去支撐，之後會有代碼內建和環境管了解決方案，釋出前會提供一些自動化內建工具，可以通過不編寫腳本實作快速疊代，隻需要填寫幾個資料就可實作校驗，另外在測試資料方面還提供資料銀行制造資料。在測試階段，雲效平台還會提供用例的管理以及缺陷的管理和一些創新的自動化測試工具。在釋出階段，平台還提供內建自動化産品實作回歸測試，以及由平台支撐持續傳遞。在最後的總結階段，可以通過整個平台收集的資料對商業結果以及項目進行度量，并且可以進行故障分析。
細化到産品的架構，可以看到産品架構也是形成一個閉環。在産品架構中存在一個指揮官的角色，從需求管理到立項管理再到資源和配置管理。在開發完成之後，會提供單測內建和環境管理，在手工測試方面也會提供用例管理和缺陷管理，在分層自動化方面将會提供分層自動化測試的工具，最終彙合到內建自動化，進而進行線上釋出。
<b>雲效的應用架構</b>
整個雲效平台的部署結構也是解耦的比較清楚的，會分為前台業務和中台業務等，可以做到産品獨立部署的服務。
雲效平台不依賴于任何作業系統，隻要支援docker容器就可以進行自動部署到企業的内部。
并且雲效平台具有很多的核心技術，擁有的理論、技術實作細節專利達到了50餘項，核心的就是持續內建的系統和方法。
<b>五、雲效解決方案及案例分析</b>
接下來分享一下雲效的解決方案和真實的案例。
其實剛才也提到了，雲效方案是由許多個子產品組成的，這樣就可以自由組合子產品形成解決方案。比方說可以從需求分析開始到最終的內建自動化形成一套完整的産品研發閉環的解決方案。如果沒有很多的需求，也可以從需求池開始形成需求研發的閉環。如果覺得單測內建或者ui自動化有比較多的創新點的話，也可以形成分層自動化的完整解決方案。
接下來分享一個真實的案例，衆安保險是國内首家網際網路保險公司，同時也是雲效平台的早期客戶。
基于上圖對于衆安保險的內建開發的痛點和研發背景的分析，雲效平台為衆安保險提供的解決方案就是将衆安已有的平台和雲效服務之間進行打通。衆安方面具有自己的配置管理平台、運維釋出平台和自建的資料銀行，而雲效平台則通過接口提供雲內建、部署和測試的服務，并且提供ui自動化和接口自動化方案，這樣方案就幫助衆安建設完成了持續內建的通道并且實作了核心功能。