微軟 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 分析，以保障整個客戶端產品的質量；在與端技術無關的方面，會有相關的團隊協作能力，包括需求管控，分支管理，依賴管理，人員管理等。
閱讀更多 螞蟻金服科技 的文章
