阿里CI/CD、DevOps、分層自動化技術

原文地址：http://www.infoq.com/cn/news/2017/01/alibaba-yunxiao-cicd-devops

在互聯網時代，產品快速迭代的重要性不言而喻。不論是傳統企業仍是初創企業，在提高研發效能方面都有很強的需求，若是能使用一套對項目流程管理和專項自動化提效工具，來支持項目的快速迭代發佈，實現24小時持續集成、持續交付整個流程，不但能夠提升研發效率，還能加強產品的競爭力！

1月12日，阿里巴巴旗下一站式研發提效平臺——雲效聯手 InfoQ 在阿里巴巴西溪園區舉辦了一場旨在幫助研發團隊提高研發效率的線下沙龍，邀請了阿里巴巴技術專家之嶽、許曉斌、魯小川和一佛，分享了阿里雲效平臺從生態規劃，到 CI/CD 流程，再到自動化測試的整個技術實現過程，幫助參會者深刻了解研發提效的迫切性和重要性，以及具體該怎麼作的一些思路。

大型互聯網無線團隊的雲上研發閉環

之嶽：阿里巴巴B2B事業羣高級技術專家。2011年加入阿里巴巴，擔任阿里巴巴 B2B 研發效能平臺和對外雲效平臺的產品負責人，阿里巴巴 B2B 技術風險負責人，技術質量和技術風險架構師。精通研發質量效能平臺產品，在敏捷研發、持續交付、研發團隊管理等方面有豐富的經驗。本次演講中他主要分享大型研發團隊如何得到敏捷快速的研發過程？如何實現高透明化的研發管理等內容。

一般狀況下，業務量增長以後，研發團隊也會急劇擴張，可是這給管理帶來了難度，發現原先那一套研發模式和研發管理，跟不上業務的發展。之嶽說，阿里巴巴內部的技術團隊，也面臨着一樣的問題，像 B2B 技術部上千人的團隊，支撐着幾大核心業務，在幾年前就發覺了純人肉管理、沒有系統支撐的研發模式是不合適的。爲此，阿里巴巴創建了強有力的技術中臺：綜合管理和研發效能平臺，主要目的是實行研發管理的平臺化和透明化，提高研發工程效能。目前 B2B 的技術中臺已經比較成熟，很好的支撐着1000多人的研發團隊。

阿里巴巴的使命是讓天下沒有難作的生意，因此衍生出的雲效平臺的使命就是讓天下沒有難作的研發。阿里雲效決定上雲， 提供 PaaS 和 SaaS 的服務，包含綜合管理和研發工程效能，其中綜合管理效能稱之爲「指揮部平臺」。

綜合管理效能分爲六塊：從整個業務戰略規劃，到技術資源和業務資源兵力部署，再到整個做戰內容實現做戰協同，來知足用戶需求，最終還會根據效果來複盤，從整個流程的角度來看須要改進的地方。指揮部產品適合企業管理層、項目經理、產品經理、研發人員使用，能夠實現業務技術管理平臺化、線上化和數據透明化，精準化資源投入，保障資源投入的高 ROI，極大的提高資源運做的效率和效果。

無線測試是產品研發提效的一個重點，由於無線測試有太多的碎片化，包括品牌碎片化、設備碎片化、操做系統碎片化、分辨率碎片化等等，對於整個兼容性測試都有很大影響。因此基於此，雲效考慮了一些適配測試的技術和方案。

• 智能化：定製化事件，防跳出，防霸屏；
• 有效性：覆蓋安裝，App登陸；
• 定製化：首頁遍歷，指定場景遍歷，自定義腳本，自定義執行事件。

無線測試平臺包括無線適配測試和真機遠程使用：

• 無線適配測試平臺：支持 Android 和 iOS 的智能適配，提高隨機執行有效性和覆蓋度，包括隨機事件百分比、定製化、防跳出功能、自定義腳本執行和固定場景Monkey 執行，而且支持 App 登錄後的 Monkey 執行，控件便利。還能夠爲開發和測試人員提供直觀的 Crash、ANR、Activity 覆蓋度結果報表，提供精準的設備推薦策略，進行獨立機房快速搭建和底層設備管理調度系統高效運維，有效下降 Crash率，提高 App 穩定性。
• 真機遠程使用：真機遠程使用平臺，有大量 Android 真機設備高效管理、真機設備Web化遠程在線使用，方便快捷。而且支持Native、H5 代碼遠程調試，與無線適配測試平臺設備共享使用，提高設備利用率。

面向微服務架構的 DevOps

許曉斌是 AliExpress 高級技術專家，目前在 AliExpress 從事微服務實施、研發效率提高等相關工做 AliExpress 在業務擴張和團隊壯大以後，仍然能保持研發團隊高效快速響應用戶需求，而這背後的技術力量，就是許曉彬老師所講解的 AliExpress 微服務架構及核心基礎設施，DevOps 文化及工具鏈，以及 SRE（Site Reliability Engieering）方法。

介紹一下背景，AliExpress 是阿⾥裏巴巴旗下的 2C 跨境電商網站，其後臺語言100%是用 Java 代碼編寫的；最先的代碼來自 Alibaba B2B，已有10年以上的歷史了；數百位工程師推崇 DevOps；且已有數百可獨⽴發佈的應用，這個數字還在不斷增⻓。

微服務的優點是：1.每一個服務足夠簡單，下降學習維護成本；2.獨⽴立測試和部署；3. 獨⽴立擴容、性能優化更簡單；4. 使⽤用新框架新技術變得更簡單；5. 更容易適配團隊組織架構。首先，許曉斌說，作微服務就必定要確保通訊協議是標準的，AliExpress 是多數據中心的，其服務不只分佈在中國各地，在美國、俄羅斯等地區都有部署。

微服務開發發佈的關鍵點在於，必定要走發佈系統上線，這麼作的目的是標準化流程化，還對提高穩定性很是有好處。在微服務的前提下，再來談談 DevOps，寫代碼的工程師是對本身的代碼負責任，每一個工程師都是微服務應用的owner，這就是 DevOps 的核心理念。

• 發佈環節須要注意事項包括：預發佈(Staging)環境驗證、藍綠髮布、分批發布、基於用戶 Beta 發佈、自動回滾。
• 監控和報警這一環節須要統一的監控系統、系統監控、應用監控和業務監控。
• 標準化要求則須要在部署結構、命名規範、日誌規範、代碼結構、交互協議等方面嚴格要求。
• SRE 團隊在 DevOps 領域的意義也是很關鍵的，每一個工程師對本身的應用負責，包括對應用的功能、性能、可用性等方面時刻關注；同時，SRE 團隊對網站總體可用性負責，具有應急故障處理能力，深刻掌握容災演習，容災切換等技術；熟悉穩定性治理技術。

最後，許曉斌引用了 AWS 對 DevOps 的定義：DevOps 集文化理念、實踐和工具於一身，能夠提升組織高速交付應用程序和服務的能力，與使用傳統軟件開發和基礎設施管理流程相比，可以幫助組織更快地發展和改進產品。這種速度使組織可以更好地服務其客戶，並在市場上更高效地參與競爭。

持續集成與持續交付實踐之路

魯小川是阿里巴巴B2B事業羣高級專家，主要負責阿里巴巴雲效平臺解決方案服務輸出。目前互聯網電商、金融等公司業務蓬勃發展，技術團隊規模和應用規模也在快速擴大、測試環境日益複雜，可是測試力量依然薄弱、應用驗證成本不斷提高。在這種狀況下，傳統企業的項目集成及交付軟件已經不能知足需求。隨即，這些公司硬件及中間件基礎設施陸續搬到雲上，企業對基於雲端提高效率的持續集成持續交付的平臺需求也日益迫切。魯小川基於這樣的背景，結合案例分析，講解了如何幫助雲端企業實現持續集成持續交付。

持續交付並非指軟件每個改動都要儘快的部署到產品環境中，而是指任何的修改都被證實能夠在任什麼時候候實施部署。持續交付(Continuous Delivery)是一系列的開發實踐方法，用來確保讓代碼可以快速、安全的部署到產品環境中，它經過將每一次改動都提交到一個模擬產品環境中，使用嚴格的自動化測試，確保業務應用和服務能符合預期。由於使用徹底的自動化過程來把每一個變動自動的提交到測試環境中，因此當業務開發完成時，你有信心只須要按一次按鈕就能將應用安全的部署到產品環境中。

大型系統持續集成持續交付難點

• 應用數量衆多(數百甚至上千)，應用之間調用關係千絲萬縷、錯中複雜
• 開發團隊人數衆多(數百甚至上千) 
• 並行開發的項目小需求衆多(數百甚至上千)，各項目小需求的商業上線時間各不相同
• 傳統的項目集成及交付軟件已經不能知足需求。

在大集成環境的全網迴歸環境下，迴歸驗證必然會有發佈窗口限制，沒辦法快速交付。會暴露出不少問題，例如：功能的交付與大應用相比並沒有改觀；手工部署的應用更多，更復雜；自動化排查問題效率低；痛苦的回滾，剔除問題代碼提交。

爲了實現持續交付，該怎麼作呢？單個應用實現快速交付，沒有全網自動化迴歸，面對複雜的服務化依賴較大質量風險，給了質量保證部很大壓力。既要快速交付，還要集成質量。質量向前，把一切能自動化的自動化起來，提高項目組成員的工做效能。完成這一系列過程，這其中的核心就是實現自動化。

分層自動化看上去就是一個金字塔，基本上分爲兩部分，業務邏輯自動化測試，和代碼級別自動化測試。而這裏面重點是UI自動化存在不少痛點，用下面這個公式能夠說明：

• 自動化收益=有效迭代次數×手工測試成本
• 自動化成本=腳本建立成本+維護次數×維護調試成本+腳本失敗次數×腳本排錯成本

其次就是在服務化接口測試上作了不少改進，包括：無需編碼，自動解析接口及所需參數，頁面建立接口自動化測試用例；頁面直接填寫調用參數，支撐多種參數類型；直接指定IP進行服務調用。

在線性能壓測方面，實行了在線編輯性能壓測腳本；分佈式集羣壓測執行調度，執行結果實時統計；Linux服務器資源在線監控。

經過一系列的改進，給 質量保證團隊帶來的變化很明顯，好比：開發測試比逐年提高，更多的開發資源投入在產品研發上，支撐業務快速發展；測試資源經過高效的自動化工具產品，提供分層自動化測試套件進行自動集成；業務技術團隊判斷是否須要測試人員接手人工測試；能夠有不通過手工測試的需求發佈上線，可是不能沒有質量數據監控的需求發佈上線。

阿里巴巴CI/CD之分層自動化

一佛是阿里巴巴B2B事業羣高級產品經理。從事多年互聯網系統的研發和測試工做，目前主要負責雲效分層自動化測試的產品設計。由於自動化測試在實踐過程當中，老是碰到各類各樣的問題，致使進入自動化測試盲區。因此，一佛就根據當下環境並結合解決案例，來說解了如何把握分層自動化的分層策略，如何將分層自動化融入到項目流程中，如何作好自動化測試等現實問題。

自動化誕生的背景，一佛說，手工測試的效率低下，尤爲是發佈頻繁的狀況下，迴歸量大，成本高，重複勞動，枯燥多。而自動化以後，就能夠替代重複勞動，N次測試，只須要投入一次就夠了。

可是自動化也是有煩惱的，問題就在於成本高（代碼能力、自動化框架、IDE 準備、調度、多環境），效果差（瀏覽器影響、執行機影響、依賴環境影響、腳本健壯性不強），覆蓋率低（框架不萬能、上下層難全、接口參數排列多），及時性低（代碼變動頻繁、遺漏的變動、項目結束才發現）等等。

因此說，爲了下降成本，提升準確性，就要考慮下降人員成本、製做成本、運維成本、運行成本，同時擴大覆蓋率、數據獨立、提供好的方法和腳本。固然，就須要實行分層自動化。

在阿里實踐分層自動化就須要不少分層工具，包括配置管理Aton、UI測試的AUI、單元測試的Amon、環境管理的Aenv、接口測試SAT、性能測試Perf、集成自動化Pre等。這裏來介紹幾個革命性工具：

UI自動化—AUI

• 創新型web-ui自動化測試框架，無需安裝複雜底層環境和 IDE
• 建立和維護腳本，都無需接觸代碼，所有爲 Web 頁面可視化使用
• 支持本地回放，支持雲端執行，解放機器，釋放雙手
• 支持項目持續集成，線上監控等各類複雜場景

接口自動化—SAT

• 可視化的接口測試，無需編寫代碼
• 支持普通接口調試和複雜後臺交互的接口測試的用例沉澱
• 支持主幹，項目用例的沉澱與迴歸
• 支持項目持續集成

性能壓測—Perf

• 基於 Jmeter 的性能壓測平臺
• 集腳本，場景，壓測，監控和報表爲一體，可快速施壓的平臺
• 支持多種協議，適合 http，service 接口等測試
• 比 LoadRunner 易上手，更輕量

單元測試—Amon

• 可對代碼主幹及各項目分支進行單測集成
• 對有代碼變動的項目分支自定義頻率集成
• 對有代碼變動的應用主幹自定義頻率集成
• 擁有單測用例結果、覆蓋率結果、靜態掃描結果、sonar 代碼分析等質量數據

集成自動化—Pre

• 支持多種自動化框架接入
• 支持項目集成相關全部自動化的自動統一觸發
• 支持多種自動化框架不一樣環境觸發
• 支持平常持續集成
• 支持自動化失敗的緣由彙總與總結

阿里分層自動化實踐所帶來的成果是很是有價值的，在阿里內部，大幅提升了研發測試比，減小了重複勞動帶來的加班，同時帶動了更多高效工具的誕生；在研發方面，單測成本下降了，覆蓋率可視化了，自測有保障了，故障下降了；在測試方面下降了測試要求，增長了工做成就感；對雲效客戶來講，給企業賦能了，提升了研發測試效率。