手機淘寶高質(zhì)量持續(xù)交付探索之路_第1頁
手機淘寶高質(zhì)量持續(xù)交付探索之路_第2頁
手機淘寶高質(zhì)量持續(xù)交付探索之路_第3頁
手機淘寶高質(zhì)量持續(xù)交付探索之路_第4頁
手機淘寶高質(zhì)量持續(xù)交付探索之路_第5頁
已閱讀5頁,還剩6頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、國內(nèi)最具權(quán)威的市場調(diào)研門戶網(wǎng)站之一手機淘寶高質(zhì)量持續(xù)交付探索之路前言隨著移動互聯(lián)網(wǎng)的迅速普及,手機淘寶業(yè)務(wù)在迅速的成長,目前已經(jīng)發(fā)展成為擁有40多個bundle(業(yè)務(wù)模塊)的超大APP產(chǎn)品,在這后面有著數(shù)百名的研發(fā)人員的努力工作。業(yè)務(wù)的成長和人員的倍增給技術(shù)架構(gòu)、團隊合作、產(chǎn)品的交付都帶來了巨大的挑戰(zhàn)。本文將會講述手機淘寶研發(fā)團隊在兩年的時間為了達到高質(zhì)量持續(xù)交付的目標(biāo)而做出的種種努力。希望借此機會向大家分享手淘的經(jīng)驗與教訓(xùn),與大家共同探討高質(zhì)量持續(xù)交付之道。第一階段:單工程單構(gòu)建產(chǎn)物、初級流程、初級質(zhì)量保障回到兩年多以前,手淘還是一個年輕的產(chǎn)品,業(yè)務(wù)不多、研發(fā)人數(shù)不多、代碼數(shù)量也不多、測試的

2、手段也很單一。這個時期的特點就是所有代碼都在一個工程里面,測試、發(fā)布都是圍繞這一個工程的代碼分支所編譯出來的包來進行的。工程架構(gòu)這個時候的手淘基本上就是一個大工程,依賴以源碼依賴為主,所有的開發(fā)人員共享這一個工程,在同一個工程上開發(fā)。存在的問題1、代碼混在一起,不便于管理。一個模塊的代碼有問題就會影響整個項目的開發(fā)人員。2、不能支持業(yè)務(wù)的快速增長。研發(fā)流程工程的架構(gòu)決定了研發(fā)交付的流程,所以當(dāng)時的流程也比較簡單,開發(fā)人員在本地開發(fā)完成以后直接提交代碼,然后編譯服務(wù)器進行打包,出包以后測試人員進行測試,如此反復(fù),最根據(jù)代碼庫的最后一次提交進行發(fā)布。如下圖所示:存在的問題1、提測和集成階段混在一起

3、,提測代碼質(zhì)量較差,開發(fā)人員不斷的提交修改bug從而導(dǎo)致不斷的集成包。2、任何一個編譯不過的問題會造成整個團隊在等待。3、回滾只能做到代碼級別的回滾。4、發(fā)布前回歸如發(fā)現(xiàn)問題只能等待開發(fā)人員修改bug,然后重新出包,再進行一輪回歸,如此反復(fù)工作量很大。5、如遇到阻塞問題,比如登錄有問題,那么所有的人員都要等待登錄的開發(fā)人員修改完bug才能繼續(xù)工作,造成了大量的等待時間。6、發(fā)布過程只有正式發(fā)布這一個步驟,很容易造成故障遺漏到線上。質(zhì)量保證手段這個時期的手淘測試主要以手工測試為主,附加一些monkey測試和少量的自動化腳本。存在的問題1、純手工的測試造成了測試人員大量的在做重復(fù)工作的現(xiàn)象。2、測

4、試經(jīng)驗沒有積累。3、非功能性的問題缺乏測試手段。4、出集成包的節(jié)奏不可控,導(dǎo)致測試人員頻繁換包測試,造成大量的重復(fù)工作。5、對于不同的環(huán)境需要打出多種不同配置的測試包(如:測試包、預(yù)發(fā)包、線上包等),測試人員需要安裝多個包進行反復(fù)的回歸。第二階段:多工程單一構(gòu)建產(chǎn)物、平臺建立、初級持續(xù)集成、發(fā)布流程建立隨著移動互聯(lián)網(wǎng)的迅猛發(fā)展,手機淘寶的業(yè)務(wù)隨之倍增,研發(fā)人員也倍增。這個時候大小業(yè)務(wù)模塊已經(jīng)超過20個,研發(fā)人員超過了百人。這個時候原有的工程架構(gòu)已經(jīng)完全不能滿足業(yè)務(wù)的需要了,質(zhì)量保障也面臨著很大的挑戰(zhàn),也就是在這個時期我們建立了一系列的平臺:打包平臺、發(fā)布平臺、測試平臺、驗收平臺從而使用自動化的

5、方式提升了些效率。并且建立了灰度發(fā)布的流程,提升了最終發(fā)布的質(zhì)量。不過這些努力也沒有阻止質(zhì)量和交付問題的大規(guī)模爆發(fā)工程架構(gòu)工程架構(gòu)是整個研發(fā)的基礎(chǔ),所有的事情還是要從工程架構(gòu)講起。為了能夠接入越來越多的業(yè)務(wù),手機淘寶的架構(gòu)從之前的單一工程的方式演進為模塊化開發(fā)的方式,每一個模塊被稱作bundle。同時引入了倉庫的概念,每個模塊將源碼打包之后deploy進入倉庫,然后由builder工程進行依賴管理并編譯打包。存在的問題這次改造解決了之前多業(yè)務(wù)并行開發(fā)的問題,最終打包的時候也不會直接依賴各個bundle的代碼庫,完成了部分的解耦。但是還是存在很多的問題:在同一個版本中所有的研發(fā)人員還是用的同一套

6、依賴配置,任何模塊的改動還是會影響其它模塊,尤其是核心業(yè)務(wù)和框架層SDK的提交有問題的話會影響整個團隊的進度。倉庫的版本管理混亂,開發(fā)和集成共用同一套倉庫,開發(fā)可以隨意部署,造成集成包無法控制。由于各個bundle是將源碼部署到倉庫的,所以構(gòu)建還是以源碼為基礎(chǔ)的,在代碼越來越多的情況下,造成了整包編譯速度緩慢。尤其是在等待很長時間以后編譯失敗,這種感覺是讓人抓狂的。這個問題已經(jīng)極大地影響到了研發(fā)的效率。各個bundle的代碼最終還是要編譯到一個產(chǎn)物當(dāng)中,各個bundle還是會相互影響,編譯失敗后定位問題成為了一大難題。這里講一下當(dāng)時幾個典型場景:開發(fā)人員只是添加了一個方法,然后等待了10分鐘進

7、行編譯,結(jié)果編譯失敗,然后排查一下午問題,結(jié)果是框架SDK更新導(dǎo)致的。一大早幾十個測試人員在等待回歸驗證發(fā)布包,結(jié)果發(fā)布包不是編譯失敗就是核心功能不可用最后到了凌晨2點鐘,發(fā)布包終于出來了。這樣的場景太美,讓人不敢去回憶。研發(fā)流程由于架構(gòu)改造,提交集成的角色從開發(fā)人員變成了業(yè)務(wù)模塊的研發(fā)團隊,提交集成的方式從提交代碼變成了deploy到倉庫,但是由于工程架構(gòu)的問題本質(zhì)上沒有完成各個bundle的解耦,所以整個團隊還是在一條線上進行開發(fā)。不過這各階段加入灰度發(fā)布的概念,灰度制度的建立使很多問題提前暴露,從而提高了正式發(fā)布版本的質(zhì)量。另外這個階段建立起了代碼審核、打包平臺、發(fā)布平臺、測試平臺、輿情

8、監(jiān)控平臺等,自動化了很多事情,在一定程度上提升了工作效率,大致使用流程如下:存在的問題集成的雖有雛形但依然不明顯,提測和集成的界限依然模糊,很多bundle還是開發(fā)完以后直接deploy到主項目中然后打出集成包進行測試。集成的標(biāo)準雖然提出,但不能很好的運作,導(dǎo)致集成質(zhì)量很差。核心功能阻塞的問題越來越突出,長時間出不了可用的包成了一個大問題。回滾操作依然困難。項目的節(jié)奏依然混亂,導(dǎo)致項目延期和研發(fā)人員效率下降。質(zhì)量保證手段這個時期的手淘測試團隊建立了內(nèi)存、性能、流量電量等專項測試機制,編寫了一些半自動化的測試工具,建立了自動化適配平臺,并組建了外包團隊以提高測試覆蓋率。這時候測試人員工作流程如下

9、圖:存在的問題測試人員在不斷的更新測試包和等待出包上面浪費了大量的時間。自動測試和專項測試只能在灰度階段版本質(zhì)量基本穩(wěn)定的時候才能介入,這不但壓縮了這些測試的時間,而且由于是在項目后期發(fā)現(xiàn)的問題所以會使問題修復(fù)成本增加。非功能測試只有專項測試人員來做,此類測試的覆蓋率還不理想。測試經(jīng)驗的積累手段主要是自動化測試平臺,但是這對于手淘研發(fā)團隊來說還是遠遠不夠的。外包團隊的組建解決了人力緊張的問題,但是外包人員的工作效果難以評估。對于不同的環(huán)境需要打出多種不同配置的測試包(如:測試包、預(yù)發(fā)包、線上包等),測試人員需要安裝多個包進行反復(fù)的回歸測試。當(dāng)前階段:多工程多構(gòu)建產(chǎn)物、流程逐漸完善、多種質(zhì)量保障

10、手段建立基于前兩個階段的經(jīng)驗和教訓(xùn),手機淘寶研發(fā)團隊在工程架構(gòu)、研發(fā)流程、質(zhì)量保障等多方面不斷的進行完善,從而建立起來現(xiàn)在的體系。工程架構(gòu)現(xiàn)在手機淘寶的工程架構(gòu)進行了進一步的改造,形成了一套插件化的體系,而分bundle編譯的引入大大縮短了構(gòu)建時間,從而使構(gòu)建速度不再成為瓶頸。另外分bundle編譯可以提早發(fā)現(xiàn)編譯問題,從而不會導(dǎo)致整包編譯時編譯失敗。另外引入了依賴配置項的概念,目前項目完整包的構(gòu)建完全取決于依賴配置,在單bundle開發(fā)、提測、項目集成、發(fā)布等各個階段的依賴配置完全獨立,各個bundle的開發(fā)測試人員可以在完全獨立的環(huán)境中進行開發(fā)測試,不會受到干擾。研發(fā)流程有了工程架構(gòu)的有力

11、支持,研發(fā)流程慢慢進入了正軌。首先明確了bundle開發(fā)、提測、集成、灰度、正式發(fā)布等各個生命周期的邊界,真正做到各個階段的相互獨立。其次在各個生命周期中加入了規(guī)范性的流程,并由平臺保證了流程的真正實施。最后質(zhì)量保證手段和效率也有了很大提升?;谝陨蠋c手淘的整個研發(fā)做到了類似于火車發(fā)車的發(fā)布過程:各個bundle在有著自己的需求、開發(fā)、測試計劃,相互獨立。手機淘寶主項目制定發(fā)布計劃,確定集成窗口和發(fā)布時間點。在集成窗口時間bundle可以自主提交集成。集成提交需要走流程,包括填寫checklist、代碼檢查、bug統(tǒng)計、提前編譯預(yù)集成包進行測試等。這就避免了明顯的集成問題遺漏到集成環(huán)境中。集

12、成期間的集成包每天出一個或者兩個,避免了測試人員不斷拿包回歸的情況。集成窗口對于時間要求嚴格,趕不上計劃或者質(zhì)量不達標(biāo)的bundle不予集成。這就是火車不等人的原則。以上機制保證了手機淘寶每天都有一個候選包,可以隨時進行灰度發(fā)布,并且灰度發(fā)布單獨拉取一個依賴配置分支,不影響集成窗口。bundle的獨立,依賴配置的獨立保證了手機淘寶可以并行多個發(fā)布計劃,各個bundle可以按照需求自主決定搭乘哪個發(fā)布計劃進行發(fā)布。目前手淘項目節(jié)奏為兩個星期發(fā)布一個版本。如果需要還可以更快的進行發(fā)版。最短只需要1個小時就可以發(fā)一個新版。目前的平臺建設(shè)工作也進入了快車道,所有的項目生命周期都有相應(yīng)的平臺工具支持,如

13、下圖:質(zhì)量保證手段有了高效穩(wěn)定的流程,剩下的事情就是如何保證產(chǎn)品在快節(jié)奏的持續(xù)交付下的保持很高的質(zhì)量。質(zhì)量保障上面手機淘寶研發(fā)團隊做了幾方面事情:1. 流程方面1)創(chuàng)建了提測單、集成單、發(fā)布單等流程。建立了標(biāo)準,并依托平臺自動檢查,提高了交付的質(zhì)量。2)建立持續(xù)集成體系,不但能提早發(fā)現(xiàn)更多的問題,而且提升了測試人員拿到的包的質(zhì)量。3)建立線上線下監(jiān)控分析體系。2. 包穩(wěn)定性方面:1)bundle階段根據(jù)項目進度自己控制提測包的頻率,集成階段每日驗證DailyBuild即可,所以解決了之前測試同學(xué)不斷安裝新版本的包的問題。2)研發(fā)階段的包內(nèi)部支持環(huán)境切換,這實現(xiàn)了只構(gòu)建一次,環(huán)境根據(jù)配置切換的夢

14、想。測試時手機上只需要安裝一次包即可完成多種環(huán)境下的測試。3. 自動化測試與測試工具方面1)引入多種靜態(tài)掃描引擎,并定制多種規(guī)則:適配規(guī)則、Crash規(guī)則、框架約定規(guī)則、安全規(guī)則等,并且不斷地將測試階段、線上問題等總結(jié)抽象成新的掃描規(guī)則補充進入掃描引擎。2)在測試階段包種插入相應(yīng)的測試SDK,并且這種SDK不會侵入應(yīng)用代碼,所以只需要在發(fā)布的時候去掉測試SDK即可。測試SDK可以在測試人員(包括外包適配測試人員)正常使用過程中自動檢測并上報問題,這樣就可以在同一的平臺上看到研發(fā)過程中的質(zhì)量情況并進行修復(fù)。3)自動化平臺方面也在根據(jù)手淘測試經(jīng)驗不斷的進化,在整個研發(fā)過程中自動化測試一直在執(zhí)行,不

15、僅可以提高產(chǎn)品穩(wěn)定性,也可以發(fā)現(xiàn)性能、電量等非功能問題。4)mock工具、驗證平臺等輔助測試工具也提升了測試人員的效率。4. 線上線下監(jiān)控分析1)線下質(zhì)量數(shù)據(jù)、線上業(yè)務(wù)問題、輿情反饋等信息統(tǒng)一匯集到平臺上進行統(tǒng)一的分析告警,不僅能快速的發(fā)現(xiàn)問題,而且能通過數(shù)據(jù)分析能夠幫助快速定位和解決問題。2)根據(jù)平臺中的數(shù)據(jù),可以用經(jīng)驗推動流程的優(yōu)化、補充測試用例、添加掃描規(guī)則、增加自動化場景、催生新的測試工具等,這樣可以使經(jīng)驗形成閉環(huán),使質(zhì)量保障工作更加高效。以上就是手機淘寶研發(fā)團隊在建立高質(zhì)量持續(xù)交付體系過程中的經(jīng)驗分享,雖然現(xiàn)在在架構(gòu)、流程,質(zhì)量保障方面有了一些積累,但是在移動互聯(lián)網(wǎng)這個領(lǐng)域還有諸如穩(wěn)定性、電量、流量、性能、適配、用戶體驗、線上運維、故障告警等難題等待我們?nèi)ソ鉀Q。前方的道路依然坎坷,我們會更加努力,并不斷前行。本文作者 楊強摘自:產(chǎn)品中國of the enemys attack. Troops, and troops were scattered, Qian Kangmin, Commander, Deputy Commander Ding Bingcheng and others heroic martyrdom. Turk foreign

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論