簡介：mPaaS 研發流程和線上運維介紹

在日常運維過程中發現，我們大部分使用者對螞蟻的研發流程比較感興趣，特別是在上百個開發者同時在一個app的環境內進行高效開發，技術選型、研發流程還有線上運維是怎麼做的，成為大家關注的重點。以下分享我的一些理解。

Ⅰ 技術選型

目前研發模式分為 Native 模式和動態化模式兩種，其中Native技術棧主要覆蓋基礎中介軟體，還有核心高保鏈路或者變更很少的一些基礎頁面，比如收銀臺，登入頁面，付款碼等。

其他場景業務一般會通過動態化的方式，解耦客戶端版本釋出。其中，線上H5一般適用於活動營銷活動，離線包場景一般用於有固定入口的常駐業務，如果有跨端多投場景，一般會選擇小程式，通過小程式的跨端釋出實現多端投放。

Ⅱ 研發流程

1.需求階段：主要是需求評審，大家意見達成一致。
2.開發階段：程式碼開發，程式碼合併以及打包等
3.測試階段：測試案例的編寫，功能測試，相容性測試等
4.整合階段：程式碼改動申請進對應的整合基線,進行整合驗證
5.釋出階段: 通過內灰，外灰，渠道包全量，站內全量實現釋出上線

Ⅲ 分支管理

原則：基於分支開發，基於主幹釋出

（一）變更操作流程

1.建立變更
2.選擇倉庫，基於 Master 建立分支
3.在分支上打工程包，打安裝包，自測（可以基於變更分支建立 feature 分支，並行開發）
4.合併到 Master 打包、提測
5.申請整合、釋出

（二）獨立釋出

主要用做區別於日常變更的獨立釋出迭代，比如單獨針對某個廠商做的預裝包適配迭代，就適用於獨立釋出。

（三）多App管理(雙Master)

使用場景：聚寶、香港支付寶、口碑、支付寶共用同一個程式碼倉庫，同一程式碼庫需要多app並行，需要有自己獨立的master分支，在合併的時候，在不同的app端進行多主幹的合併。

Ⅳ 線上運維

（一）多維度灰度釋出能力

MDS提供多維度的釋出模式，釋出前需要經過白名單灰度，內部灰度，外部灰度，百分比灰度等多層次灰度，不斷擴大灰度範圍，直到Crash率，ANR率等穩定性指標達標後才進行全量的釋出。

（二）多角度線上監控

MAS提供了多角度的實時監控指標監控，包括Crash率，ANR率等核心指標，同時這些核心的指標上報都是通過實時通道完成的上報，方便問題的快速發現。

（三）輿情監控

除了以上一些核心指標的監控，同時提供了輿情的監控平臺，開發者可以設定自己關注的關鍵字，在灰度期間去檢視相關產品的線上使用者輿情，真實的反饋使用者問題。

（四）線上問題定位

通過上述的多渠道發現問題後，首先可以通過客戶端上報的行為日誌進行分析，同時也可以通過MAS提供的日誌拉取功能，拉取使用者的詳細日誌進行進一步的診斷分析。

（五）自動容災降級

在積累了多年的客戶端問題處理經驗後，客戶端SDK內部也沉澱了一套自恢復的容災降級策略。比如對於多次啟動後重復閃退的使用者，客戶端會嘗試在啟動後清除app私有目錄下的一些檔案，解決由於髒資料導致的極端重複閃退。

（六）線上問題修復

針對不同的問題提供了不同的能力實現動態修復，比如對Native模組實現動態修復的hotpatch機制。

• 辛苦開發的 App 被山寨？mPaaS 幫你為 APK 上把加固鎖
• 搞定客戶端證書錯誤，看這篇就夠了
• mPaaS-RPC 攔截器各種場景下的使用指南

原文連結：https://developer.aliyun.com/article/776784?

版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。