移動研發 DevOps 落地實踐
摘要： 本文將圍繞支付寶如何隨著移動市場的高速發展，逐步沉澱優化出適用業務發展需求的研發效能實踐。
作者：姚蘭天（十鏡），螞蟻金服技術專家。
概要：傳統的研發模式已經無法適應企業在數字化轉型中快速迭代以及研發協同的要求，建設符合業務場景特性和有效支撐高併發、持續迭代整合需求的研發效能實踐迫在眉睫。
本文將圍繞支付寶如何隨著移動市場的高速發展，逐步沉澱優化出適用業務發展需求的研發效能實踐。現場視訊）：http://t.cn/Ai9HuCNT
大家好，我是來自支付寶終端工程技術團隊的十境。本文將帶領大家瞭解支付寶移動端如何隨著移動市場的告訴發展，逐步沉澱優化出適用業務發展需求的研發效能實踐。
0. 背景
- 如何解決百萬級程式碼的極速構建？
- 如何讓上百開發者在同一個 App 上高效研發協同？
- 如何保障程式碼頻繁變更下的交付質量？
顯然，傳統的研發模式已經無法適應企業在數字化轉型中快速迭代以及研發協同的要求，建設符合業務場景特性和有效支撐高併發、持續迭代整合需求的研發效能實踐迫在眉睫。
1. 研發協作平臺現狀
關於支付寶在移動端研發平臺構建的歷程，首先我們先展開看看目前平臺的現狀，並講述如何參考 DevOps “三步工作法” 來正向建模我們的交付價值流，以及這些活動中比較核心的分支模型，構建，持續整合等。
研發協作平臺大概從 2014 年開始建設，如今支援的 iOS 和 Android 客戶端程式碼量都已經超過 300w 行，拆分的 Bundle 數量也都在 300 個以上。我們每週的構建次數在 1.4W，安裝包平均每天會灰度 2~3 次，開發測試同學達到近千人的規模。
我們支撐了螞蟻集團支付寶、網商銀行、財富、口碑等產品的交付，支援的技術棧從最開始的 Android 和 iOS，演進到廠商 SDK、小程式、IoT 及桌面應用等。在這些能力輸出的下層是我們沉澱的一套研發協作流程，從需求到開發、測試、交付、及釋出後的反饋閉環。
支付寶業務的飛速發展，從工具到超級 App，程式碼量猛增到 300W+。技術架構上，採用了模組化動態載入的技術，這就給我們提了一個問題，如何將 300+ 個 Bundle，在不同的團隊裡開發，整合，變成一個高質量的 App 推送到使用者手機上。
2. DevOps 三步工作法
DevOps 三步工作法，第一步，我們正向價值流建模，把研發劃分為 5 個階段（需求階段、開發階段、測試階段、整合階段以及釋出階段）
通過正向價值流的建模，結合團隊的開發實踐，便可以得到研發協作平臺產品的一個資訊架構圖。
如上圖所示，隨時間演進，我們沉澱出了一套產品資訊圖：從最開始僅僅是安裝包構建的一個線上工具，到產物管理，版本管理，架構拆分後的模組資訊、模組構建管理，根據構建的產物及場景的不同，抽象出了構建配置、渠道配置、持續整合的配置，當然還有其它元資料如證書資訊的配置。
我們參考了敏捷、Scrum 實踐，抽象出迭代的概念來組織每個模組涉及的資源如程式碼倉庫、需求、缺陷、任務、持續整合流水線還有最重要的團隊和人員。釋出定義了我們交付的產物，同時也是各團隊工作整合到一起的大容器。
這是我們研發協作平臺的門戶首頁，開發者能直觀地看到自己關注專案的日常釋出、迭代資訊，以及每天需要解決的待辦等，每個類目和我們上一頁提煉的資訊架構相對應。
- 拆解「依賴配置」
前面提到我們通過架構拆分，團隊模組化協作的方式來應對激增的業務需求。那麼之所以有這張截圖，是想讓大家對我們的依賴配置有個直觀的感受，每個模組的產物可以理解為一個 Zip 包，在某一個安裝包釋出中管理這樣由 300 多個 Bundle 構成的一個依賴列表。我們的需求整合某種意義上就是這個依賴列表中中模組版本的升級。模組拆分也讓我們的小批量快速交付成為得以踐行、擁有 2 周釋出一個大版本的能力。
- 分支模型
需求管理我們可以藉助 Jira、Redmine 等工具，或對接內部的專案管理平臺。這裡我直接從開發階段的活動開始。
首先說下 MR，這是我們的分支模型：“基於分支開發，基於主幹釋出”。開發階段基於 Master 建立迭代分支，基於迭代分支建立 Feature 分支通過 MR 方式在合併到迭代分支前，做一次 Code Review 卡點。整合階段便可以直接基於 Master 分支建立 Bugfix 分支然後在 MR 回 Master 分支。釋出階段基於客戶端版本建立 Tag。
1. 構建的定義與技術架構
接下來說說構建。我把構建定義為程式碼和配置經過構建工具和指令碼在環境中執行而產生產物的過程。因此我們要關注這 4 個要素“程式碼、構建指令碼、執行環境、產物管理”。程式碼和構建指令碼由開發者提供，我們要幫忙管理的是環境和產物。比如 IoT 提個需求過來要支援他們的構建，其實就是給他們準備一個 Docker 映象，定義好輸入輸出，把他們產物釋出到 Maven 倉庫或雲端儲存中。
- 構建：技術架構
理解了構建的要素，技術架構也就很明確了，上面是我們支援的構建業務型別，排程是執行的核心能力，Docker 和 MacOS 是我們涉及的環境，藉助 Jenkins 來連線這些執行機器。環境管理這塊主要是 Docker，Windows 對 Docker 的支援也很好，我們的 IDE 構建就用的 Windows Docker。我們有 30 多臺 Mac Pro，為了更好的管理，採用 Ansible 來做一些預置和軟體升級的工作。
- 構建：Demo
這是我們的一次 Android 安裝包構建，時間是 3 分鐘，通過 Jenkins 的介面可以很直觀的看到經歷了那些步驟及耗費的時間，如果有錯誤也能很快定位到。
2. 自動化流水線架構設計
從構建的單項能力建設，慢慢擴充套件到了靜態掃描、自動化測試、包大小檢查，安全掃描等驗證的需求。我們首先會想到持續整合流水線，我們調研了 Jenkins、Gitlab、Drone、CircleCI、TravisCI 等主流的 CI 工具，最終還是決定自研一套 CI 平臺來連線公司內部的各個團隊的驗證服務。從這個架構圖可以看出 CI 的核心是 Pipeline 流水線的定義與解析，驗證執行，以及連線各服務的接入規約。上層是支援的業務型別，以及觸發流水線的機制設定。
流水線也讓我們不停的思考如何去更好的視覺化，以及 DevOps 實踐“三步工作法”中的逆向反饋設定。比如流水線編排時如何快速驗證，分層分級驗證，做到有效反饋。根據反饋再快速修復。
- 自動化流水線：列表 Demo
這是我們的持續整合列表頁面，選擇 IOT 新業務快速試錯，將掃描和冒煙測試都展示給開發測試同學，這樣對程式碼 Push 後的一個驗證有個全域性認識，然後他們便可以更好的區域性節點優化，比如冒煙測試要獲取什麼樣的報告。
- 自動化流水線：示例 Demo
這是一條流水線的詳情頁面，點選每個節點可以看到執行的狀態和產物資訊，依賴資訊等。每個節點也可以選擇跳過執行，或選擇從失敗節點重新執行，滿足業務接入流水線不同階段的使用場景。
3. 釋出：健康度
接下來再介紹一些我們內部灰度釋出的一些質量指標設計。這是我們在整合過後經歷內灰、外灰、釋出的介面，每個階段我們會聚合各種質量和反饋資訊，來幫助我們去推進每個階段。
- 釋出質量分數
這是釋出質量的一個概要資訊，及灰度情況。質量分的曲線能很好的配合我們工作的節奏。雖然剛開始質量分非常難以設計，不容易全面並準確衡量，但質量分一定要有，然後不停地迭代。剛開始可以參考 Sonar 的 Quality Gates 和它的質量維度來設計。
- 釋出：質量維度
這是我們質量維度的設計，供大家參考一下。
3. 總結
最後簡單總結，以上內容首先介紹了支付寶客戶端研發的現狀，通過 DevOps “三步工作法” 第一步正向建模工作流，梳理了需求、開發、測試、整合、釋出這 5 個階段及每個階段的重要活動，形成價值流動的脈絡圖，並參考敏捷開發實踐來組織我們的產品資訊架構。然後重點講述了我們的構建和持續整合流水線的設計與實現，通過流水線編排、釋出階段質量分的設計來實踐 “三步工作法”的逆向反饋機制。 三步工作法。第三步持續學習和改進可以基於前 2 步的來達成。
以上介紹的支付寶移動研發 DevOps 落地實踐，目前已經通過移動開發平臺 mPaaS 對外輸出一部分能力。
通過 mPaaS，我們針對移動端產品的研發管理，能夠從產品需求準備，研發，構建，驗證到整合等多個專案階段，充分節約管理成本，提升研發效率。
隨著軟體研發的模式由傳統的瀑布式開發逐步向敏捷開發和 DevOps 演進，變得愈來愈自動化和智慧化，研發、測試、釋出統一完成線上化和流程化將全面提升研發協同效率，並給企業帶來更多的業務價值、
由於篇幅限制，很多技術要點我們無法一一展開，歡迎大家通過技術文件或點選“原文連結”進一步瞭解 mPaaS ：https://tech.antfin.com/docs/2/49549
| 活動推薦：MTSC 2019 測試開發大會
MTSC2019 第五屆中國移動網際網路測試開發會將於 6 月 28-29 日在北京國際會議中心舉行，50+ 來自 Google，BAT，TMD 等一線網際網路企業的測試大咖分享精彩議題，涵蓋移動自動化測試、服務端測試、質量保障 QA、高新測試技術（AI+、大資料測試、IoT 測試）等專題。
螞蟻金服多位技術專家將在大會上分享精彩議題，解密螞蟻金服內部移動測試 2.0+ 演進之路、程式碼實時染色系統如何完成程式碼覆蓋率檢測等，期待與你交流。
往期閱讀
《螞蟻金服 mPaaS 服務端核心元件：億級併發下的移動端到端網路接入架構解析》
《mPaaS 核心元件：支付寶如何為移動端產品構建輿情分析體系？》
原文連結
本文為雲棲社群原創內容，未經