在互聯網時代，產品快速迭代的重要性不言而喻。不管是傳統企業還是初創企業，在提升研發效能方面都有很強的需求，如果能使用一套對項目流程管理和專項自動化提效工具，來支持項目的快速迭代發布，實現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
支持多種自動化框架接入支持項目集成相關所有自動化的自動統一觸發支持多種自動化框架不同環境觸發支持日常持續集成支持自動化失敗的原因匯總與總結阿里分層自動化實踐所帶來的成果是非常有價值的，在阿里內部，大幅提高了研發測試比，減少了重復勞動帶來的加班，同時帶動了更多高效工具的誕生；在研發方面，單測成本降低了，覆蓋率可視化了，自測有保障了，故障降低了；在測試方面降低了測試要求，增加了工作成就感；對云效客戶來說，給企業賦能了，提高了研發測試效率。
京公網安備 11010502049343號