支付寶 App 是如何建設移動 DevOps 的？

本文系InfoQ對螞蟻金服技術專家洪鋒的採訪，洪鋒老師即將在 QCon 上海站 2019 分享《移動研發 DevOps 在支付寶 App 內的落地實踐》，歡迎關注。

微軟 MSDN 上的一篇文章有這樣一段話：「移動應用的理想環境須要知足兩個條件，一是能夠確切知道客戶腦海中當即浮現的需求，二是爲了知足這些需求而編寫的代碼能夠當即傳遞給這些客戶，簡單來講，就是客戶需求、開發和傳遞之間沒有任何間隙。」

這段話中提到的移動應用開發想要的理想環境，恰好 DevOps 均可以知足，所以一些超大規模 APP 的研發模式，尤爲是偏項目式研發協同的人員、模塊較多的研發，都開始慢慢研究 DevOps 體系。那麼，移動 DevOps 建設與 Web DevOps 建設有什麼不一樣之處？移動 DevOps 的建設有哪些難點？移動 DevOps 如何面對新技術的衝擊？…爲了解開這些疑問，InfoQ採訪了螞蟻金服技術專家洪鋒。

移動DevOps 與 Web DevOps

近兩年，DevOps 已經成爲企業軟件研發的主流，被衆多企業所採用，有關 DevOps 的實踐分享分享也特別多，但大多集中在 Web DevOps，相比之下，移動端 DevOps 的實踐分享就比較少。

之因此會出現這種狀況，琉克認爲是由於Web DevOps 具備更加穩定的執行和驗證環境，一般在服務器上能夠直接進行全部的開發、驗證、交付等流程。而移動 DevOps 最大的難題是移動應用沒有一個穩定的驗證環境，大多數移動應用均可以在多個設備上使用，也就意味着要處理各類技術規範，操做系統版本，屏幕尺寸等。目前移動端主流的操做系統有兩個，分別是 Android 和 iOS。其中Android 以各自爲政而出名，每一個設備商都建立了本身的操做系統，存量設備差別極大，而 iOS 也具備多個變體，存量設備 OS 版本跨度大。除此以外，移動應用還具有人機交互的特性，例如當前比較流行的掃碼、人臉識別等技術，那麼如何在移動 DevOps 中儘可能減小人工干預，讓總體變得更順暢，提高總體的研發效率，這是咱們要思考的問題。

雖然移動 DevOps 建設存在一些難題，但其實移動開發與 DevOps 是自然契合的，由於客戶端開發，尤爲是智能終端，原本就是新興的領域，技術的迭代更新比較快，再加上端產品的特殊性，好比沒法實時回滾降級等，因此客戶端產品的核心建設主要集中在研發協同、研發效率、新技術落地、質量保障等方面，這與 DevOps 的建設目標也不謀而合。

除了 DevOps 是否適用於移動開發，相信不少人都會關心什麼時候建設 DevOps。琉克認爲：「DevOps 的主要目的是爲了提升總體的研發效率，因此 DevOps 應用的最佳時機就是當公司業務發展出現多個業務並行發展，且規模均達到數十人。由於這時企業的研發效率和質量就會成爲一個瓶頸，爲了打破這個瓶頸，就會有不少員工投入到工具研發中，以實現必定的自動化能力，不免會出現不少重複造輪子的工做，這時進行 DevOps 建設，統一收口，就能夠避免重複造輪子。」

支付寶移動 DevOps 建設

DevOps 與業務發展是緊密相關的，沒有業務場景的DevOps 等於空談，因此支付寶的 DevOps 建設也是在業務發展到必定階段纔開始進行的。

據琉克介紹，支付寶的技術和業務發展大體能夠分爲如下幾個過程：

• 初期階段

一個倉庫，一套代碼，而後是工具化組件化，最後是動態化生態化和智能化。在初期開發人員多是個位數，業務功能也並不複雜，此時幾個開發，幾個測試就搞定整個研發，這時候投入建設 DevOps 是投入遠遠大於產出的，沒有建設的必要。

• 中期階段

隨着業務的快速發展和客戶端技術的爆發，支付寶也落地了組件化和模塊化技術，此時研發人員也達到了幾十號人，人和人之間的溝通協做，質量保障已經變的很是困難，也是在這個時候進行了統一的建設。

初期階段一個代碼倉庫、一套代碼所有搞定的模式，在代碼量增多的狀況下帶來了不少問題，包括互相之間耦合嚴重，一次編譯構建時間太長，再加上當時業務發展帶來了線上問題，急需線上修復能力，因此支付寶自研了模塊化方案，實現了模塊隔離，提早編譯，動態更新等能力。

在 DevOps 的建設過程當中，支付寶主要集中在了研發協同、研發效率和質量保障三個方面。

以質量保障爲例，當代碼量從一個倉庫發展到數百個倉庫，百萬級代碼，簡單的單測或黑盒測試已經不能保障總體質量。所以，琉克所在的團隊經過分析支付寶的業務特色和業務場景，結合支付寶技術框架，進行了深度的定製開發，落地了不少靜態和動態的質量保障能力，其中靜態質量保障能力包括定製的靜態代碼分析，依賴分析等，而動態質量保障能力包括真機性能穩定性測試，用例錄製回放等。

做爲最終產物的生成方，支付寶團隊也承載了構建工做，由於大型 APP 對性能和包大小有極致的追求，每一點點的性能提高和包大小縮減均可能直接影響用戶的留存。支付寶團隊經過構建深挖，開發了文件重排、代碼重排、debuginfo 刪除等構建技術，並經過線上的灰度逐步驗證到最後正式上線。

移動DevOps 建設的難點

Gartner 研究總監 Jason Wong 曾在一篇博客中指出：「並不是全部的 DevOps 公司都會將DevOps 用於移動開發，根據 Gartner 調查結果顯示，只有 42％實施 DevOps 的人表示DevOps 用於支持移動應用開發。」 爲何在移動應用開發場景下 DevOps 的實踐不多呢？

琉克認爲主要緣由在於投入產出比，除了超級 App，大部分移動 App 的開發都是採起小團隊小步快走的方式，開發和測試人員都不多，幾乎都是個位數。可是移動應用因爲其特殊性，要實現自動化用例測試、真機測試等 CI 能力，每每須要投入比較大的人力成本和資金成本，好比實驗室的搭建，大量終端設備的採購，一整套自動化系統的搭建等。相比較而言，小型 App 因爲自己複雜度不會很高，大部分場景能夠經過開發測試同窗的單元測試，手工用例編寫和測試等手段保證 App 的質量。

在移動 DevOps 的具體建設中，琉克認爲包括如下難點：

首先，移動應用技術棧是割裂的，Android和 iOS 是兩套徹底不一樣的技術棧，如何統一兩套技術棧的研發流程，這是一個挑戰。支付寶的解決方法是抽象出一個移動端的研發模型，好比統一抽象模塊化構建，統一依賴管理模型，統一迭代研發流等，具體的差別點放在每個模型的實施路由上，好比 Android 模塊構建會經過路由配置到 Linux 服務器上經過 Docker 構建，iOS 模塊構建經過路由配置到 Mac 物理機進行構建。

其次，移動應用的驗證很是複雜，尤爲是支付寶百萬級代碼，千人研發的狀況下，每次的代碼改動均可以有大量的代碼和功能受到影響。在代碼級別，支付寶經過深刻編譯以及在框架層自研深度定製的代碼掃描和依賴分析能力，精確跟蹤每個 Method 的影響面，並經過評估系統把控每個變更帶來的風險。在真機驗證環境，支付寶有一整套完整的真機實驗室，全方位監控移動應用總體的兼容性，穩定性，性能等。

第三，持續集成也是移動 DevOps 建設的難點之一。持續集成須要有快速穩定的反饋能力，所以在持續集成節點上，支付寶選擇了單點突破，並作了不少優化，好比構建性能等；在 UI 自動化測試方面，支付寶自研搭建了實驗室，定製硬件，從而支持更多的設備，且提高穩定性和吞吐量；面對集團內部各類驗證服務能力對接，也借鑑業界 Gitlab CI、Github Action 等 CI 工具，開發了本身的 CI 編排工具，爲開發測試同窗提供超高體驗；任務執行 DSL 咱們又直接使用 Jenkins Pipeline 不重複造輪子。

除此以外，移動應用最近幾年的新技術發展也很是迅猛，例如 Facebook 的 React 生態、Google 的 Flutter，以及近日熱度很高的華爲方舟編譯器和鴻蒙系統，對於移動 DevOps 來講，因爲不少場景都是基於當時的技術場景和技術水位定製的，因此新技術的出現對生態及技術選型的衝擊比較大。

爲了面對新技術的變革，移動DevOps 建設須要把新技術耦合部分和非耦合部分拆分開，儘可能減小衝擊。舉個例子，在與端技術有關的質量工程方面，支付寶會提早進行預研和技術儲備，好比在靜態分析領域，以前只有 Java、OC 語言，可是隨着小程序的出現，JavaScript、TypeScript 語言也漸漸被引入進來了，同時還會對前端語言作靜態分析和 Native 分析，以保障整個客戶端產品的質量；在與端技術無關的方面，會有相關的團隊協做能力，包括需求管控，分支管理，依賴管理，人員管理等。