傳統(tǒng)的研發(fā)模式已經(jīng)無法適應(yīng)企業(yè)在數(shù)字化轉(zhuǎn)型中快速迭代以及研發(fā)協(xié)同的要求，建設(shè)符合業(yè)務(wù)場景特性和有效支撐高并發(fā)、持續(xù)迭代集成需求的研發(fā)效能實踐迫在眉睫。
本文將圍繞支付寶如何隨著移動市場的高速發(fā)展，逐步沉淀優(yōu)化出適用業(yè)務(wù)發(fā)展需求的研發(fā)效能實踐。

大家好，我是來自支付寶終端工程技術(shù)團隊的十境。本文將帶領(lǐng)大家了解支付寶移動端如何隨著移動市場的告訴發(fā)展，逐步沉淀優(yōu)化出適用業(yè)務(wù)發(fā)展需求的研發(fā)效能實踐。

0. 背景

• 如何解決百萬級代碼的極速構(gòu)建？
• 如何讓上百開發(fā)者在同一個 App 上高效研發(fā)協(xié)同？
• 如何保障代碼頻繁變更下的交付質(zhì)量？

顯然，傳統(tǒng)的研發(fā)模式已經(jīng)無法適應(yīng)企業(yè)在數(shù)字化轉(zhuǎn)型中快速迭代以及研發(fā)協(xié)同的要求，建設(shè)符合業(yè)務(wù)場景特性和有效支撐高并發(fā)、持續(xù)迭代集成需求的研發(fā)效能實踐迫在眉睫。

1. 研發(fā)協(xié)作平臺現(xiàn)狀

關(guān)于支付寶在移動端研發(fā)平臺構(gòu)建的歷程，首先我們先展開看看目前平臺的現(xiàn)狀，并講述如何參考 DevOps “三步工作法” 來正向建模我們的交付價值流，以及這些活動中比較核心的分支模型，構(gòu)建，持續(xù)集成等。

研發(fā)協(xié)作平臺大概從 2014 年開始建設(shè)，如今支持的 iOS 和 Android 客戶端代碼量都已經(jīng)超過 300w 行，拆分的 Bundle 數(shù)量也都在 300 個以上。我們每周的構(gòu)建次數(shù)在 1.4W，安裝包平均每天會灰度 2~3 次，開發(fā)測試同學達到近千人的規(guī)模。

我們支撐了螞蟻集團支付寶、網(wǎng)商銀行、財富、口碑等產(chǎn)品的交付，支持的技術(shù)棧從最開始的 Android 和 iOS，演進到廠商 SDK、小程序、IoT 及桌面應(yīng)用等。在這些能力輸出的下層是我們沉淀的一套研發(fā)協(xié)作流程，從需求到開發(fā)、測試、交付、及發(fā)布后的反饋閉環(huán)。

支付寶業(yè)務(wù)的飛速發(fā)展，從工具到超級 App，代碼量猛增到 300W+。技術(shù)架構(gòu)上，采用了模塊化動態(tài)加載的技術(shù)，這就給我們提了一個問題，如何將 300+ 個 Bundle，在不同的團隊里開發(fā)，集成，變成一個高質(zhì)量的 App 推送到用戶手機上。

2. DevOps 三步工作法

DevOps 三步工作法，第一步，我們正向價值流建模，把研發(fā)劃分為?5 個階段（需求階段、開發(fā)階段、測試階段、集成階段以及發(fā)布階段），定義每個階段的準入準出標準。比如需求分析的結(jié)果需要拆分到 User Story 級別，通過大家需求評審，達成一致。接著，每個階段我們提煉出最重要的活動，比如開發(fā)階段，開發(fā)同學每天最多的就是寫代碼，代碼 Review，以及代碼 MR/Push 后觸發(fā)的自動化流水線，如編譯、掃描、自動化測試等。這些階段和每個階段的活動以及人員之間的協(xié)作，就構(gòu)成了我們交付大圖的脈絡(luò)，即我們常說的價值流。

通過正向價值流的建模，結(jié)合團隊的開發(fā)實踐，便可以得到研發(fā)協(xié)作平臺產(chǎn)品的一個信息架構(gòu)圖。

如上圖所示，隨時間演進，我們沉淀出了一套產(chǎn)品信息圖：從最開始僅僅是安裝包構(gòu)建的一個在線工具，到產(chǎn)物管理，版本管理，架構(gòu)拆分后的模塊信息、模塊構(gòu)建管理，根據(jù)構(gòu)建的產(chǎn)物及場景的不同，抽象出了構(gòu)建配置、渠道配置、持續(xù)集成的配置，當然還有其它元數(shù)據(jù)如證書信息的配置。

我們參考了敏捷、Scrum 實踐，抽象出迭代的概念來組織每個模塊涉及的資源如代碼倉庫、需求、缺陷、任務(wù)、持續(xù)集成流水線還有最重要的團隊和人員。發(fā)布定義了我們交付的產(chǎn)物，同時也是各團隊工作集成到一起的大容器。

這是我們研發(fā)協(xié)作平臺的門戶首頁，開發(fā)者能直觀地看到自己關(guān)注項目的日常發(fā)布、迭代信息，以及每天需要解決的待辦等，每個類目和我們上一頁提煉的信息架構(gòu)相對應(yīng)。

• 拆解「依賴配置」

前面提到我們通過架構(gòu)拆分，團隊模塊化協(xié)作的方式來應(yīng)對激增的業(yè)務(wù)需求。那么之所以有這張截圖，是想讓大家對我們的依賴配置有個直觀的感受，每個模塊的產(chǎn)物可以理解為一個 Zip 包，在某一個安裝包發(fā)布中管理這樣由 300 多個 Bundle 構(gòu)成的一個依賴列表。我們的需求集成某種意義上就是這個依賴列表中中模塊版本的升級。模塊拆分也讓我們的小批量快速交付成為得以踐行、擁有 2 周發(fā)布一個大版本的能力。

• 分支模型

需求管理我們可以借助 Jira、Redmine 等工具，或?qū)觾?nèi)部的項目管理平臺。這里我直接從開發(fā)階段的活動開始。

首先說下 MR，這是我們的分支模型：“基于分支開發(fā)，基于主干發(fā)布”。開發(fā)階段基于 Master 創(chuàng)建迭代分支，基于迭代分支創(chuàng)建 Feature 分支通過 MR 方式在合并到迭代分支前，做一次 Code Review 卡點。集成階段便可以直接基于 Master 分支創(chuàng)建 Bugfix 分支然后在 MR 回 Master 分支。發(fā)布階段基于客戶端版本創(chuàng)建 Tag。

1. 構(gòu)建的定義與技術(shù)架構(gòu)

接下來說說構(gòu)建。我把構(gòu)建定義為代碼和配置經(jīng)過構(gòu)建工具和腳本在環(huán)境中執(zhí)行而產(chǎn)生產(chǎn)物的過程。因此我們要關(guān)注這 4 個要素“代碼、構(gòu)建腳本、執(zhí)行環(huán)境、產(chǎn)物管理”。代碼和構(gòu)建腳本由開發(fā)者提供，我們要幫忙管理的是環(huán)境和產(chǎn)物。比如 IoT 提個需求過來要支持他們的構(gòu)建，其實就是給他們準備一個 Docker 鏡像，定義好輸入輸出，把他們產(chǎn)物發(fā)布到 Maven 倉庫或云存儲中。

• 構(gòu)建：技術(shù)架構(gòu)

理解了構(gòu)建的要素，技術(shù)架構(gòu)也就很明確了，上面是我們支持的構(gòu)建業(yè)務(wù)類型，調(diào)度是執(zhí)行的核心能力，Docker 和 MacOS 是我們涉及的環(huán)境，借助 Jenkins 來連接這些執(zhí)行機器。環(huán)境管理這塊主要是 Docker，Windows 對 Docker 的支持也很好，我們的 IDE 構(gòu)建就用的 Windows Docker。我們有 30 多臺 Mac Pro，為了更好的管理，采用 Ansible 來做一些預置和軟件升級的工作。

• 構(gòu)建：Demo

這是我們的一次 Android 安裝包構(gòu)建，時間是 3 分鐘，通過 Jenkins 的界面可以很直觀的看到經(jīng)歷了那些步驟及耗費的時間，如果有錯誤也能很快定位到。

2. 自動化流水線架構(gòu)設(shè)計

從構(gòu)建的單項能力建設(shè)，慢慢擴展到了靜態(tài)掃描、自動化測試、包大小檢查，安全掃描等驗證的需求。我們首先會想到持續(xù)集成流水線，我們調(diào)研了 Jenkins、Gitlab、Drone、CircleCI、TravisCI 等主流的 CI 工具，最終還是決定自研一套 CI 平臺來連接公司內(nèi)部的各個團隊的驗證服務(wù)。從這個架構(gòu)圖可以看出 CI 的內(nèi)核是 Pipeline 流水線的定義與解析，驗證執(zhí)行，以及連接各服務(wù)的接入規(guī)約。上層是支持的業(yè)務(wù)類型，以及觸發(fā)流水線的機制設(shè)定。

流水線也讓我們不停的思考如何去更好的可視化，以及 DevOps 實踐“三步工作法”中的逆向反饋設(shè)定。比如流水線編排時如何快速驗證，分層分級驗證，做到有效反饋。根據(jù)反饋再快速修復。

• 自動化流水線：列表 Demo

這是我們的持續(xù)集成列表頁面，選擇 IOT 新業(yè)務(wù)快速試錯，將掃描和冒煙測試都展示給開發(fā)測試同學，這樣對代碼 Push 后的一個驗證有個全局認識，然后他們便可以更好的局部節(jié)點優(yōu)化，比如冒煙測試要獲取什么樣的報告。

• 自動化流水線：示例 Demo

這是一條流水線的詳情頁面，點擊每個節(jié)點可以看到執(zhí)行的狀態(tài)和產(chǎn)物信息，依賴信息等。每個節(jié)點也可以選擇跳過執(zhí)行，或選擇從失敗節(jié)點重新運行，滿足業(yè)務(wù)接入流水線不同階段的使用場景。

3. 發(fā)布：健康度

接下來再介紹一些我們內(nèi)部灰度發(fā)布的一些質(zhì)量指標設(shè)計。這是我們在集成過后經(jīng)歷內(nèi)灰、外灰、發(fā)布的界面，每個階段我們會聚合各種質(zhì)量和反饋信息，來幫助我們?nèi)ネ七M每個階段。

• 發(fā)布質(zhì)量分數(shù)

這是發(fā)布質(zhì)量的一個概要信息，及灰度情況。質(zhì)量分的曲線能很好的配合我們工作的節(jié)奏。雖然剛開始質(zhì)量分非常難以設(shè)計，不容易全面并準確衡量，但質(zhì)量分一定要有，然后不停地迭代。剛開始可以參考 Sonar 的 Quality Gates 和它的質(zhì)量維度來設(shè)計。

• 發(fā)布：質(zhì)量維度

這是我們質(zhì)量維度的設(shè)計，供大家參考一下。

3. 總結(jié)

最后簡單總結(jié)，以上內(nèi)容首先介紹了支付寶客戶端研發(fā)的現(xiàn)狀，通過 DevOps “三步工作法” 第一步正向建模工作流，梳理了需求、開發(fā)、測試、集成、發(fā)布這 5 個階段及每個階段的重要活動，形成價值流動的脈絡(luò)圖，并參考敏捷開發(fā)實踐來組織我們的產(chǎn)品信息架構(gòu)。然后重點講述了我們的構(gòu)建和持續(xù)集成流水線的設(shè)計與實現(xiàn)，通過流水線編排、發(fā)布階段質(zhì)量分的設(shè)計來實踐 “三步工作法”的逆向反饋機制。 三步工作法。第三步持續(xù)學習和改進可以基于前 2 步的來達成。

以上介紹的支付寶移動研發(fā) DevOps 落地實踐，目前已經(jīng)通過移動開發(fā)平臺 mPaaS 對外輸出一部分能力。

通過 mPaaS，我們針對移動端產(chǎn)品的研發(fā)管理，能夠從產(chǎn)品需求準備，研發(fā)，構(gòu)建，驗證到集成等多個項目階段，充分節(jié)約管理成本，提升研發(fā)效率。

隨著軟件研發(fā)的模式由傳統(tǒng)的瀑布式開發(fā)逐步向敏捷開發(fā)和 DevOps 演進，變得愈來愈自動化和智能化，研發(fā)、測試、發(fā)布統(tǒng)一完成線上化和流程化將全面提升研發(fā)協(xié)同效率，并給企業(yè)帶來更多的業(yè)務(wù)價值。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的移动研发 DevOps 落地实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。