轉自：
前言
隨着移動互聯網的迅速普及，手機淘寶業務在迅速的成長，目前已經發展成爲擁有40多個bundle（業務模塊）的超大APP產品，在這後面有着數百名的研發人員的努力工作。業務的成長和人員的倍增給技術架構、團隊合作、產品的交付都帶來了巨大的挑戰。本文將會講述手機淘寶研發團隊在兩年的時間爲了達到高質量持續交付的目標而做出的種種努力。希望藉此機會向大家分享手淘的經驗與教訓，與大家共同探討高質量持續交付之道。
第一階段：單工程單構建產物、初級流程、初級質量保障
回到兩年多以前，手淘還是一個年輕的產品，業務不多、研發人數不多、代碼數量也不多、測試的手段也很單一。這個時期的特點就是所有代碼都在一個工程裏面，測試、發佈都是圍繞這一個工程的代碼分支所編譯出來的包來進行的。
工程架構
這個時候的手淘基本上就是一個大工程，依賴以源碼依賴爲主，所有的開發人員共享這一個工程，在同一個工程上開發。
存在的問題
- 代碼混在一起，不便於管理。一個模塊的代碼有問題就會影響整個項目的開發人員。
- 不能支持業務的快速增長。
研發流程
工程的架構決定了研發交付的流程，所以當時的流程也比較簡單，開發人員在本地開發完成以後直接提交代碼，然後編譯服務器進行打包，出包以後測試人員進行測試，如此反覆，最根據代碼庫的最後一次提交進行發佈。如下圖所示：
存在的問題
- 提測和集成階段混在一起，提測代碼質量較差，開發人員不斷的提交修改bug從而導致不斷的集成包。
- 任何一個編譯不過的問題會造成整個團隊在等待。
- 回滾只能做到代碼級別的回滾。
- 發佈前回歸如發現問題只能等待開發人員修改bug，然後重新出包，再進行一輪迴歸，如此反覆工作量很大。
- 如遇到阻塞問題，比如登錄有問題，那麼所有的人員都要等待登錄的開發人員修改完bug才能繼續工作，造成了大量的等待時間。
- 發佈過程只有正式發佈這一個步驟，很容易造成故障遺漏到線上。
質量保證手段
這個時期的手淘測試主要以手工測試爲主，附加一些monkey測試和少量的自動化腳本。
存在的問題
- 純手工的測試造成了測試人員大量的在做重複工作的現象。
- 測試經驗沒有積累。
- 非功能性的問題缺乏測試手段。
- 出集成包的節奏不可控，導致測試人員頻繁換包測試，造成大量的重複工作。
- 對於不同的環境需要打出多種不同配置的測試包（如：測試包、預發包、線上包等），測試人員需要安裝多個包進行反覆的迴歸。
第二階段：多工程單一構建產物、平臺建立、初級持續集成、發佈流程建立
隨着移動互聯網的迅猛發展，手機淘寶的業務隨之倍增，研發人員也倍增。這個時候大小業務模塊已經超過20個，研發人員超過了百人。這個時候原有的工程架構已經完全不能滿足業務的需要了，質量保障也面臨着很大的挑戰，也就是在這個時期我們建立了一系列的平臺：打包平臺、發佈平臺、測試平臺、驗收平臺從而使用自動化的方式提升了些效率。並且建立了灰度發佈的流程，提升了最終發佈的質量。不過這些努力也沒有阻止質量和交付問題的大規模爆發……
工程架構
工程架構是整個研發的基礎，所有的事情還是要從工程架構講起。爲了能夠接入越來越多的業務，手機淘寶的架構從之前的單一工程的方式演進爲模塊化開發的方式，每一個模塊被稱作bundle。同時引入了倉庫的概念，每個模塊將源碼打包之後deploy進入倉庫，然後由builder工程進行依賴管理並編譯打包。
存在的問題
這次改造解決了之前多業務並行開發的問題，最終打包的時候也不會直接依賴各個bundle的代碼庫，完成了部分的解耦。但是還是存在很多的問題：
- 在同一個版本中所有的研發人員還是用的同一套依賴配置，任何模塊的改動還是會影響其它模塊，尤其是核心業務和框架層SDK的提交有問題的話會影響整個團隊的進度。
- 倉庫的版本管理混亂，開發和集成共用同一套倉庫，開發可以隨意部署，造成集成包無法控制。
- 由於各個bundle是將源碼部署到倉庫的，所以構建還是以源碼爲基礎的，在代碼越來越多的情況下，造成了整包編譯速度緩慢。尤其是在等待很長時間以後編譯失敗，這種感覺是讓人抓狂的。這個問題已經極大地影響到了研發的效率。
- 各個bundle的代碼最終還是要編譯到一個產物當中，各個bundle還是會相互影響，編譯失敗後定位問題成爲了一大難題。
這裏講一下當時幾個典型場景：
- 開發人員只是添加了一個方法，然後等待了10分鐘進行編譯，結果編譯失敗，然後排查一下午問題，結果是框架SDK更新導致的。
- 一大早幾十個測試人員在等待迴歸驗證發佈包，結果發佈包不是編譯失敗就是核心功能不可用最後到了凌晨2點鐘，發佈包終於出來了。
這樣的場景太美，讓人不敢去回憶。
研發流程
由於架構改造，提交集成的角色從開發人員變成了業務模塊的研發團隊，提交集成的方式從提交代碼變成了deploy到倉庫，但是由於工程架構的問題本質上沒有完成各個bundle的解耦，所以整個團隊還是在一條線上進行開發。不過這各階段加入灰度發佈的概念，灰度制度的建立使很多問題提前暴露，從而提高了正式發佈版本的質量。
另外這個階段建立起了代碼審覈、打包平臺、發佈平臺、測試平臺、輿情監控平臺等，自動化了很多事情，在一定程度上提升了工作效率，大致使用流程如下：
存在的問題
- 集成的雖有雛形但依然不明顯，提測和集成的界限依然模糊，很多bundle還是開發完以後直接deploy到主項目中然後打出集成包進行測試。
- 集成的標準雖然提出，但不能很好的運作，導致集成質量很差。
- 核心功能阻塞的問題越來越突出，長時間出不了可用的包成了一個大問題。
- 回滾操作依然困難。
- 項目的節奏依然混亂，導致項目延期和研發人員效率下降。
質量保證手段
這個時期的手淘測試團隊建立了內存、性能、流量電量等專項測試機制，編寫了一些半自動化的測試工具，建立了自動化適配平臺，並組建了外包團隊以提高測試覆蓋率。這時候測試人員工作流程如下圖：
存在的問題
- 測試人員在不斷的更新測試包和等待出包上面浪費了大量的時間。
- 自動測試和專項測試只能在灰度階段版本質量基本穩定的時候才能介入，這不但壓縮了這些測試的時間，而且由於是在項目後期發現的問題所以會使問題修復成本增加。
- 非功能測試只有專項測試人員來做，此類測試的覆蓋率還不理想。
- 測試經驗的積累手段主要是自動化測試平臺，但是這對於手淘研發團隊來說還是遠遠不夠的。
- 外包團隊的組建解決了人力緊張的問題，但是外包人員的工作效果難以評估。
-
對於不同的環境需要打出多種不同配置的測試包（如：測試包、預發包、線上包等），測試人員需要安裝多個包進行反覆的迴歸測試。
![]()
當前階段：多工程多構建產物、流程逐漸完善、多種質量保障手段建立
基於前兩個階段的經驗和教訓，手機淘寶研發團隊在工程架構、研發流程、質量保障等多方面不斷的進行完善，從而建立起來現在的體系。
工程架構
現在手機淘寶的工程架構進行了進一步的改造，形成了一套插件化的體系，而分bundle編譯的引入大大縮短了構建時間，從而使構建速度不再成爲瓶頸。另外分bundle編譯可以提早發現編譯問題，從而不會導致整包編譯時編譯失敗。另外引入了依賴配置項的概念，目前項目完整包的構建完全取決於依賴配置，在單bundle開發、提測、項目集成、發佈等各個階段的依賴配置完全獨立，各個bundle的開發測試人員可以在完全獨立的環境中進行開發測試，不會受到干擾。
研發流程
有了工程架構的有力支持，研發流程慢慢進入了正軌。首先明確了bundle開發、提測、集成、灰度、正式發佈等各個生命週期的邊界，真正做到各個階段的相互獨立。其次在各個生命週期中加入了規範性的流程，並由平臺保證了流程的真正實施。最後質量保證手段和效率也有了很大提升。基於以上幾點手淘的整個研發做到了類似於火車發車的發佈過程：
- 各個bundle在有着自己的需求、開發、測試計劃，相互獨立。
- 手機淘寶主項目制定發佈計劃，確定集成窗口和發佈時間點。
- 在集成窗口時間bundle可以自主提交集成。
- 集成提交需要走流程，包括填寫checklist、代碼檢查、bug統計、提前編譯預集成包進行測試等。這就避免了明顯的集成問題遺漏到集成環境中。
- 集成期間的集成包每天出一個或者兩個，避免了測試人員不斷拿包迴歸的情況。
- 集成窗口對於時間要求嚴格，趕不上計劃或者質量不達標的bundle不予集成。這就是火車不等人的原則。
- 以上機制保證了手機淘寶每天都有一個候選包，可以隨時進行灰度發佈，並且灰度發佈單獨拉取一個依賴配置分支，不影響集成窗口。
- bundle的獨立，依賴配置的獨立保證了手機淘寶可以並行多個發佈計劃，各個bundle可以按照需求自主決定搭乘哪個發佈計劃進行發佈。
-
目前手淘項目節奏爲兩個星期發佈一個版本。如果需要還可以更快的進行發版。最短只需要1個小時就可以發一個新版。
![]()
目前的平臺建設工作也進入了快車道，所有的項目生命週期都有相應的平臺工具支持，如下圖：
質量保證手段
有了高效穩定的流程，剩下的事情就是如何保證產品在快節奏的持續交付下的保持很高的質量。質量保障上面手機淘寶研發團隊做了幾方面事情：
1. 流程方面
1）創建了提測單、集成單、發佈單等流程。建立了標準，並依託平臺自動檢查，提高了交付的質量。
2）建立持續集成體系，不但能提早發現更多的問題，而且提升了測試人員拿到的包的質量。
3）建立線上線下監控分析體系。
2. 包穩定性方面：
1）bundle階段根據項目進度自己控制提測包的頻率，集成階段每日驗證DailyBuild即可，所以解決了之前測試同學不斷安裝新版本的包的問題。
2）研發階段的包內部支持環境切換，這實現了只構建一次，環境根據配置切換的夢想。測試時手機上只需要安裝一次包即可完成多種環境下的測試。
3. 自動化測試與測試工具方面
1）引入多種靜態掃描引擎，並定製多種規則：適配規則、Crash規則、框架約定規則、安全規則等，並且不斷地將測試階段、線上問題等總結抽象成新的掃描規則補充進入掃描引擎。
2）在測試階段包種插入相應的測試SDK，並且這種SDK不會侵入應用代碼，所以只需要在發佈的時候去掉測試SDK即可。測試SDK可以在測試人員（包括外包適配測試人員）正常使用過程中自動檢測並上報問題，這樣就可以在同一的平臺上看到研發過程中的質量情況並進行修復。
3）自動化平臺方面也在根據手淘測試經驗不斷的進化，在整個研發過程中自動化測試一直在執行，不僅可以提高產品穩定性，也可以發現性能、電量等非功能問題。
4）mock工具、驗證平臺等輔助測試工具也提升了測試人員的效率。
4. 線上線下監控分析
1）線下質量數據、線上業務問題、輿情反饋等信息統一彙集到平臺上進行統一的分析告警，不僅能快速的發現問題，而且能通過數據分析能夠幫助快速定位和解決問題。
2）根據平臺中的數據，可以用經驗推動流程的優化、補充測試用例、添加掃描規則、增加自動化場景、催生新的測試工具等，這樣可以使經驗形成閉環，使質量保障工作更加高效。
以上就是手機淘寶研發團隊在建立高質量持續交付體系過程中的經驗分享，雖然現在在架構、流程，質量保障方面有了一些積累，但是在移動互聯網這個領域還有諸如穩定性、電量、流量、性能、適配、用戶體驗、線上運維、故障告警等難題等待我們去解決。前方的道路依然坎坷，我們會更加努力，並不斷前行。
作者簡介
楊強（花名：元戰）阿里巴巴技術專家，2012年加入阿里巴巴無線事業部，目前負責手機淘寶專項測試組，主要負責無線研發支撐平臺，無線技術運維平臺，無線專項測試工具以及無線SDK測試等方面的工作。曾經在趨勢科技、華爲從事測試工作。
