vivo 互聯(lián)網(wǎng)研發(fā)效能關(guān)鍵技術(shù)與實(shí)踐
一、互聯(lián)網(wǎng)研發(fā)挑戰(zhàn)與方案
隨著互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展，業(yè)務(wù)規(guī)模和用戶體量在不斷擴(kuò)張，在如此大的規(guī)模和體量下，對(duì)研發(fā)交付效率及質(zhì)量也提出了新的要求和挑戰(zhàn)。
（圖中數(shù)據(jù)統(tǒng)計(jì)截止時(shí)間為2024.07）
vivo互聯(lián)網(wǎng)業(yè)務(wù)廣泛，體量巨大。伴隨而來(lái)的是互聯(lián)網(wǎng)項(xiàng)目快速增長(zhǎng)，最近5年增長(zhǎng)超過(guò)了5倍。與此同時(shí)，項(xiàng)目的服務(wù)數(shù)量也出現(xiàn)大規(guī)模增長(zhǎng)，最近6年從原先少于2500，到快速增長(zhǎng)超過(guò)8000，服務(wù)數(shù)量增長(zhǎng)超過(guò)3.7倍；服務(wù)器數(shù)量也同時(shí)期增長(zhǎng)了2.8倍，研發(fā)交付和穩(wěn)定性保障的復(fù)雜度成幾何式增長(zhǎng)。可以看到隨著項(xiàng)目、服務(wù)、機(jī)器的大規(guī)模增長(zhǎng)，研發(fā)團(tuán)隊(duì)規(guī)模也發(fā)生了較大的變化，前后增長(zhǎng)超過(guò)2.7倍。隨之而來(lái)研發(fā)協(xié)作難度逐步增加，甚至出現(xiàn)效能下滑的傾向。
（圖中數(shù)據(jù)統(tǒng)計(jì)截止時(shí)間為2024.07）
隨著研發(fā)復(fù)雜度增加，互聯(lián)網(wǎng)研發(fā)流程也變得規(guī)范，與此同時(shí)，支撐的工具和平臺(tái)能力也非常豐富。但是這也帶來(lái)了交付復(fù)雜度的上升，項(xiàng)目成員往往需要在多個(gè)平臺(tái)來(lái)回切換，非常麻煩！正如圖所示，從需求洞察到需求運(yùn)營(yíng)至少需要經(jīng)歷10個(gè)階段、10多個(gè)角色的高效協(xié)作才能完成，顯然相比以前復(fù)雜了許多，也逐步顯示了需求交付效率下降的情況。
項(xiàng)目流程和平臺(tái)復(fù)雜度增加的同時(shí)，在技術(shù)層面，研發(fā)基礎(chǔ)設(shè)施也是幾經(jīng)變遷，線上線下環(huán)境的機(jī)器復(fù)雜度持續(xù)增長(zhǎng)，變更與維護(hù)難度逐年上升，對(duì)變更質(zhì)量的要求越來(lái)越高。
從上圖可以看出，在2017年以前，研發(fā)整體線上交付的機(jī)器以物理機(jī)為主，所有的線上運(yùn)維都是交由專門(mén)的業(yè)務(wù)運(yùn)維及DBA角色來(lái)執(zhí)行，開(kāi)發(fā)人員主要參與編碼和測(cè)試工作。
但隨著研發(fā)規(guī)模增長(zhǎng)，快速交付、低成本的資源也逐步開(kāi)始引入像OpenStack這樣虛擬化技術(shù)，此時(shí)用戶的操作也逐步從原有運(yùn)維逐步轉(zhuǎn)向類似CICD這樣自助化運(yùn)維交付平臺(tái)。
并且隨著內(nèi)外銷業(yè)務(wù)的發(fā)展，越來(lái)越多彈性、快速、低成本的云主機(jī)也逐步引入，平臺(tái)從簡(jiǎn)單流程逐步發(fā)展成體系化、場(chǎng)景化平臺(tái)，用戶的使用成本也逐步攀升。
回顧上面業(yè)務(wù)規(guī)模、研發(fā)體量和流程平臺(tái)的現(xiàn)狀，以及基礎(chǔ)設(shè)施的變遷，vivo互聯(lián)網(wǎng)業(yè)務(wù)面臨相當(dāng)大研發(fā)效能提升的挑戰(zhàn)。
總結(jié)來(lái)看：
- 研發(fā)規(guī)模攀升，研發(fā)交付復(fù)雜度持續(xù)上升。
- 研發(fā)交付橫跨多個(gè)階段，在多個(gè)平臺(tái)間操作，成本非常高。
- 隨著基礎(chǔ)設(shè)施的變遷發(fā)展，平臺(tái)需要不斷兼容不同資源、不同云廠商、不同用戶場(chǎng)景的訴求，為平臺(tái)建設(shè)和項(xiàng)目實(shí)踐帶來(lái)了非常大的挑戰(zhàn)。
回溯過(guò)去與當(dāng)前的困境，結(jié)合公司文化行為準(zhǔn)則，vivo研發(fā)效能團(tuán)隊(duì)堅(jiān)持以用戶導(dǎo)向深入業(yè)務(wù)側(cè)，從頂層進(jìn)行設(shè)計(jì)與規(guī)劃，提出“1-2-3”建設(shè)框架：通過(guò)1個(gè)雙環(huán)模型、2個(gè)標(biāo)準(zhǔn)化、3條研發(fā)管線助力研發(fā)效能持續(xù)提升。
第1層結(jié)合“價(jià)值探索”與“價(jià)值交付” 的持續(xù)交付雙環(huán)模型。左環(huán)確定方向與目標(biāo)，強(qiáng)調(diào)采用“提問(wèn)”-“錨定”-“共創(chuàng)”-“精煉”的方式來(lái)循環(huán)驗(yàn)證；右環(huán)則偏重過(guò)程交付，快速實(shí)現(xiàn)左環(huán)目標(biāo)，并保持業(yè)務(wù)結(jié)果與價(jià)值達(dá)成。
第2層定義了兩個(gè)標(biāo)準(zhǔn)化：需求標(biāo)準(zhǔn)化、研發(fā)標(biāo)準(zhǔn)化。需求標(biāo)準(zhǔn)化更加強(qiáng)調(diào)需求從提出到需求實(shí)驗(yàn)全鏈路閉環(huán)管理，最終實(shí)現(xiàn)需求端到端交付；研發(fā)標(biāo)準(zhǔn)化更多強(qiáng)調(diào)從分支拉出到交付上線的標(biāo)準(zhǔn)化、自動(dòng)化過(guò)程。
第3層為了重點(diǎn)支撐業(yè)務(wù)、數(shù)據(jù)、以及模型和算法需求的研發(fā)交付，規(guī)劃了3條對(duì)應(yīng)的研發(fā)管線，將原有煙囪式能力串聯(lián)成體系化工具鏈，致力于打造絲滑流暢的開(kāi)發(fā)者體驗(yàn)。
二、互聯(lián)網(wǎng)研發(fā)效能關(guān)鍵場(chǎng)景技術(shù)
根據(jù)上述研發(fā)效能現(xiàn)狀來(lái)看，我們規(guī)劃了研發(fā)效能的需求標(biāo)準(zhǔn)化、研發(fā)標(biāo)準(zhǔn)化。根據(jù)2個(gè)標(biāo)準(zhǔn)化，我們梳理了3個(gè)關(guān)鍵場(chǎng)景：需求自動(dòng)化、標(biāo)準(zhǔn)流水線、測(cè)試自動(dòng)化。
需求標(biāo)準(zhǔn)化：需求自動(dòng)化作為標(biāo)準(zhǔn)化實(shí)現(xiàn)的關(guān)鍵，它作為需求整個(gè)標(biāo)準(zhǔn)化驅(qū)動(dòng)引擎，推動(dòng)需求狀態(tài)自動(dòng)流轉(zhuǎn)。從而實(shí)現(xiàn)分支創(chuàng)建和合并、測(cè)試環(huán)境交付、測(cè)試自動(dòng)化驗(yàn)證等場(chǎng)景串聯(lián)，達(dá)到全鏈路需求標(biāo)準(zhǔn)化交付目的。例如：需求拆分任務(wù)時(shí)按照分支策略自動(dòng)拉分支，需求轉(zhuǎn)測(cè)時(shí)能夠自動(dòng)合并分支，以及觸發(fā)流水線執(zhí)行測(cè)試環(huán)境發(fā)版，及時(shí)更新測(cè)試環(huán)境版本。
標(biāo)準(zhǔn)流水線：主要流水線內(nèi)卡片類型有明確的規(guī)范，為了減少流水線配置，推進(jìn)流水線“一人配置、多人共享”，實(shí)現(xiàn)流水線并行執(zhí)行，不受運(yùn)行時(shí)流水線的限制，使得滿足所有目標(biāo)項(xiàng)目符合持續(xù)集成的要求。
測(cè)試自動(dòng)化：作為研發(fā)效能質(zhì)量提升的重要措施，在需求狀態(tài)發(fā)生流轉(zhuǎn)時(shí)，則自動(dòng)觸發(fā)流水線實(shí)現(xiàn)測(cè)試環(huán)境更新，以及觸發(fā)測(cè)試用例的執(zhí)行，主要包含流程管控自動(dòng)化，以及測(cè)試實(shí)施自動(dòng)化兩個(gè)方面。
上面需求自動(dòng)化是為了解決需求端到端過(guò)程中自動(dòng)化串聯(lián)，那原先需求自動(dòng)化是解決什么問(wèn)題呢？我們接下來(lái)看下目前互聯(lián)網(wǎng)需求流程端到端流程，不同階段的場(chǎng)景之間自動(dòng)化率較低，大部分靠手工操作。并且根據(jù)該頁(yè)下半部分來(lái)看，支持研發(fā)效能實(shí)施操作的平臺(tái)較多，圖上所示的基本只是在平臺(tái)層面有單一支持，并沒(méi)有實(shí)現(xiàn)串聯(lián)，用戶多平臺(tái)操作成本較高。
根據(jù)圖上流程顯示多平臺(tái)操作成本高，自動(dòng)化聯(lián)動(dòng)率較低，面對(duì)這樣的用戶痛點(diǎn)問(wèn)題，我們需要根據(jù)上述流程示意圖，3個(gè)大的階段7個(gè)關(guān)鍵狀態(tài)和3個(gè)核心平臺(tái)之間動(dòng)態(tài)自動(dòng)化聯(lián)動(dòng)。
首先，在需求階段，需求從納入迭代時(shí)就根據(jù)分支策略自動(dòng)化拉取分支，完成需求設(shè)計(jì)進(jìn)入開(kāi)發(fā)階段，當(dāng)需求狀態(tài)從待開(kāi)發(fā)狀態(tài)變成已完成開(kāi)發(fā)時(shí)，則自動(dòng)化觸發(fā)測(cè)試環(huán)境流水線運(yùn)行。
其次，觸發(fā)流水線運(yùn)行后則首先將分支進(jìn)行合并，并且將合并后的分支執(zhí)行代碼靜態(tài)檢查和代碼評(píng)審，通過(guò)之后借助全鏈路能力快速拉取多版本測(cè)試環(huán)境，與此同時(shí)也同步觸發(fā)測(cè)試平臺(tái)的測(cè)試用例執(zhí)行，涵蓋功能、性能等接口測(cè)試用例。
再次，完成測(cè)試環(huán)境搭建以及測(cè)試用例的執(zhí)行，生成對(duì)應(yīng)的測(cè)試報(bào)告。此時(shí)流水線將結(jié)合測(cè)試結(jié)果動(dòng)態(tài)生成上線工單，也同步反饋更新需求狀態(tài)到待上線狀態(tài)。
最后，待上線工單完成相關(guān)審批，此時(shí)將按照預(yù)設(shè)策略執(zhí)行線上部署，完成線上交付，則自動(dòng)反饋需求狀態(tài)更新已上線狀態(tài)。到目前為止，我們能夠看到整體的狀態(tài)流轉(zhuǎn)絕大部分以上都自動(dòng)化完成。
上述我們談到需求自動(dòng)化的流轉(zhuǎn)流程，那要實(shí)現(xiàn)這樣的自動(dòng)化流程，我們要如何做到呢？如圖所示我們能夠看到完成整個(gè)自動(dòng)化流轉(zhuǎn)需要4個(gè)部分：事件觸發(fā)機(jī)、規(guī)則匹配引擎、規(guī)則執(zhí)行器、日志記錄器。
首先，在觸發(fā)執(zhí)行之前，我們需要先配置觸發(fā)執(zhí)行規(guī)則，例如：“當(dāng)xx發(fā)生時(shí)，則執(zhí)行xx事件”等，并且將規(guī)則的執(zhí)行主體、觸發(fā)時(shí)機(jī)、執(zhí)行動(dòng)作關(guān)聯(lián)。此時(shí)，一旦規(guī)則的觸發(fā)時(shí)機(jī)達(dá)到條件時(shí)，則產(chǎn)生觸發(fā)事件，加入事件隊(duì)列，采用先進(jìn)先出模式執(zhí)行。
其次，當(dāng)事件隊(duì)列出列某個(gè)觸發(fā)事件之后，則將事件傳播到規(guī)則匹配引擎，此時(shí)通過(guò)匹配規(guī)則進(jìn)行模版匹配，一旦匹配通過(guò)，則將規(guī)則對(duì)應(yīng)的執(zhí)行主體任務(wù)取出，并且觸發(fā)action動(dòng)作，例如：傳遞xx參數(shù)并調(diào)用指定流水線運(yùn)行等，最后將執(zhí)行狀態(tài)返回，記錄到日志。
剛剛我們看到的是需求自動(dòng)化的上下游觸發(fā)，要是能夠讓進(jìn)一步提升研發(fā)交付效能，我們此時(shí)就需要關(guān)注通過(guò)流水線實(shí)現(xiàn)標(biāo)準(zhǔn)化交付。從圖上我們能夠看到要想實(shí)現(xiàn)交付成熟度從1.0提升到2.0，需要提升持續(xù)交付的規(guī)范化，我們知道單純依靠流程規(guī)范來(lái)實(shí)現(xiàn)流水線按照指定的規(guī)范配置和執(zhí)行，只能通過(guò)平臺(tái)標(biāo)準(zhǔn)化流水線配置與運(yùn)行，才能以實(shí)現(xiàn)交付流程的標(biāo)準(zhǔn)化和一致性。
為了實(shí)現(xiàn)標(biāo)準(zhǔn)化流水線，需要3個(gè)部分。
首先，需要定制標(biāo)準(zhǔn)流程，約束所有業(yè)務(wù)研發(fā)團(tuán)隊(duì)統(tǒng)一標(biāo)準(zhǔn)化流程操作；
其次，要考慮多場(chǎng)景觸發(fā)，則需要保證流水線可并行運(yùn)行；
最后，要通過(guò)標(biāo)準(zhǔn)檢查來(lái)保證流水線能夠按照設(shè)定好的規(guī)則配置，從而實(shí)現(xiàn)標(biāo)準(zhǔn)化交付。
上述我們也提到要實(shí)現(xiàn)標(biāo)準(zhǔn)流水線，需要支持流水線在多場(chǎng)景下并行執(zhí)行，提升流水線的使用和運(yùn)行效率。談到并行執(zhí)行，我們類比類與實(shí)例的關(guān)系，目標(biāo)是一套流水線配置，可以并行根據(jù)參數(shù)動(dòng)態(tài)運(yùn)行不同實(shí)例。
那我們來(lái)一起看看并行流水線如何實(shí)現(xiàn)的，考慮到流水線在運(yùn)行過(guò)程中根據(jù)具體配置，固化按照預(yù)設(shè)分支、環(huán)境運(yùn)行。為此，要想實(shí)現(xiàn)并行執(zhí)行。
關(guān)鍵如下：
- 去除排隊(duì)限制，讓統(tǒng)一條流水線可以支持運(yùn)行多個(gè)實(shí)例；
- 執(zhí)行過(guò)程中隔離資源（機(jī)器、環(huán)境、任務(wù)等），避免環(huán)境污染；
- 動(dòng)態(tài)生成不同執(zhí)行任務(wù)，并自動(dòng)觸發(fā)運(yùn)行；
- 保證任務(wù)運(yùn)行過(guò)程中資源隔離，避免運(yùn)行環(huán)境污染；
- 之后要注意運(yùn)行結(jié)束后隔離資源回收是否全面。
上述談到要實(shí)現(xiàn)流水線標(biāo)準(zhǔn)化，靠人工檢查效率低下，此處基于標(biāo)準(zhǔn)規(guī)則和檢查機(jī)制來(lái)保證。為此，我們來(lái)了解下我們是如何實(shí)現(xiàn)標(biāo)準(zhǔn)化規(guī)則檢查的，此處核心是將所有配置位運(yùn)算可解析的格式，通過(guò)&和^操作來(lái)實(shí)現(xiàn)。
正如上圖所示，我們將規(guī)則檢查分為兩個(gè)關(guān)鍵步驟：
- 通過(guò)&識(shí)別是否一致，主要通過(guò)二進(jìn)制位檢查來(lái)識(shí)別是否有通過(guò)檢查；
- 如果不一致，則通過(guò)^和&再次識(shí)別具體不一致的位置，從實(shí)現(xiàn)快速校驗(yàn)和識(shí)別，將得到的結(jié)果到數(shù)據(jù)庫(kù)中比對(duì)出不一致的流水線及歸屬服務(wù)。
我們從需求自動(dòng)化到流水線標(biāo)準(zhǔn)化，主要關(guān)注效率維度提升，接下來(lái)我們看下在質(zhì)量維度的提升。在測(cè)試域我們關(guān)注的測(cè)試活動(dòng)實(shí)施，主要分為兩塊：流程管控自動(dòng)化、測(cè)試實(shí)施自動(dòng)化。
流程管控自動(dòng)化，通過(guò)打通了研發(fā)域、交付域、測(cè)試域，完成測(cè)試任務(wù)的自動(dòng)流轉(zhuǎn)，從而實(shí)現(xiàn)覆蓋了80%項(xiàng)目的測(cè)試活動(dòng)。
對(duì)于測(cè)試實(shí)施自動(dòng)化而言，測(cè)試實(shí)施分為客戶端和服務(wù)端兩個(gè)維度。
- 對(duì)于服務(wù)端測(cè)試：接口和性能自動(dòng)化、變更風(fēng)險(xiǎn)可視化是確保服務(wù)端高質(zhì)量測(cè)試交付的關(guān)鍵，兩者的自動(dòng)化覆蓋度超過(guò)70%的核心項(xiàng)目。
- 對(duì)于客戶端測(cè)試：通過(guò)統(tǒng)一的插件化方案實(shí)現(xiàn)各類自動(dòng)化能力（穩(wěn)定性、功能、埋點(diǎn)等），并支持實(shí)時(shí)監(jiān)控手工測(cè)試過(guò)程中相關(guān)數(shù)據(jù)，從而保障客戶端測(cè)試的整體效果。目前覆蓋超過(guò)90%的APK應(yīng)用。
我們提到接口測(cè)試自動(dòng)化，那我們來(lái)一起看下如何實(shí)現(xiàn)？接口自動(dòng)化實(shí)現(xiàn)總體分為4個(gè)大的步驟，分別是：接口管理、用例轉(zhuǎn)化、用例執(zhí)行、輸出報(bào)告，其中接口管理考慮場(chǎng)景，又分為接口自動(dòng)化掃描和流量錄制。
接口錄制階段：接口掃描采用agent組件在java工程測(cè)試環(huán)境啟動(dòng)過(guò)程中動(dòng)態(tài)采集工程所有的java訪問(wèn)接口，并且實(shí)時(shí)將接口數(shù)據(jù)上報(bào)到接口服務(wù)平臺(tái)。
接口管理階段：除了支持工程掃描，也可以借助自研流量錄制平臺(tái)進(jìn)行錄制，并且將線上錄制好的接口鏈接及參數(shù)登記到接口服務(wù)平臺(tái)。
用例執(zhí)行階段：通過(guò)將接口參數(shù)進(jìn)行解析，動(dòng)態(tài)生成接口測(cè)試用例，并針對(duì)生成的接口測(cè)試用例進(jìn)行驗(yàn)證是否有效。
報(bào)告輸出階段：通過(guò)接口測(cè)試用例動(dòng)態(tài)生成，我們后續(xù)可以將單個(gè)測(cè)試用例進(jìn)行批量組合成套件，可以根據(jù)代碼變更動(dòng)態(tài)識(shí)別出需要自動(dòng)化測(cè)試的接口用例，通過(guò)手工、流水線、定時(shí)進(jìn)行觸發(fā)，并且將測(cè)試的接口生成測(cè)試報(bào)告通知給用戶，便于用戶實(shí)時(shí)關(guān)注測(cè)試結(jié)果。
我們了解了接口的自動(dòng)化，通過(guò)自動(dòng)化我們可以有效提升測(cè)試的質(zhì)量。但是我們都知道，接口的穩(wěn)定性除了功能的完整性測(cè)試之外，也需要考慮在目標(biāo)用戶體量下的穩(wěn)定性和可靠性，我們接下來(lái)一起看下關(guān)于接口自動(dòng)化壓測(cè)的實(shí)現(xiàn)，談到接口性能壓測(cè)，那必然離不開(kāi)接口、性能測(cè)試用例，以及壓測(cè)需要的環(huán)境。我們從整體來(lái)看，壓測(cè)過(guò)程分為兩個(gè)部分：線上環(huán)境接口錄制、壓測(cè)環(huán)境流量回放。
- 線上環(huán)境接口錄制主要是采用我們公司自研的流量錄制回放平臺(tái)月光寶盒（MoonBox），通過(guò)moonbox-sdk將線上流量采集并推送到平臺(tái)，之后將錄制的流量接口數(shù)據(jù)存放在ES數(shù)據(jù)庫(kù)中，待壓測(cè)平臺(tái)IPT需要的時(shí)候拉取。
- 用戶在IPT壓測(cè)平臺(tái)開(kāi)啟壓測(cè)時(shí)，平臺(tái)根據(jù)用戶指定的配置動(dòng)態(tài)形成壓測(cè)策略推送到壓測(cè)服務(wù)，并通過(guò)壓測(cè)服務(wù)轉(zhuǎn)化為一組組壓測(cè)任務(wù)下發(fā)到壓測(cè)集群，考慮到壓測(cè)任務(wù)體量不同，壓測(cè)集群借助容器可以動(dòng)態(tài)伸縮，實(shí)現(xiàn)目標(biāo)體量的完全模擬。通過(guò)壓測(cè)集群批量、動(dòng)態(tài)非線性實(shí)時(shí)壓測(cè)，與此同時(shí)IPT壓測(cè)平臺(tái)會(huì)動(dòng)態(tài)從監(jiān)控平臺(tái)獲取壓測(cè)環(huán)境監(jiān)測(cè)數(shù)據(jù)，并且將性能壓測(cè)結(jié)果進(jìn)行整合，最終形成目標(biāo)壓測(cè)報(bào)告發(fā)送給用戶。
三、研發(fā)效能項(xiàng)目實(shí)踐與效果
我們介紹了在效能平臺(tái)建設(shè)過(guò)程中面臨的挑戰(zhàn)和關(guān)鍵技術(shù)。當(dāng)然所有能力的建設(shè)都會(huì)回歸到助力業(yè)務(wù)效能提升上面去，在實(shí)際的業(yè)務(wù)中我們是如何實(shí)踐這些能力提升研發(fā)效能。
在“應(yīng)用商店”項(xiàng)目中，我們?cè)凇靶枨蠼桓稑?biāo)準(zhǔn)化”和“研發(fā)過(guò)程標(biāo)準(zhǔn)化”的框架下，重點(diǎn)實(shí)踐了需求分層管理和自動(dòng)化驅(qū)動(dòng)，標(biāo)準(zhǔn)流水線和自動(dòng)化測(cè)試，有效地解決了在需求管理和研發(fā)流程中的效率問(wèn)題。
vivo應(yīng)用商店是vivo官方團(tuán)隊(duì)傾力打造的應(yīng)用下載及管理平臺(tái)，為vivo手機(jī)用戶提供海量的應(yīng)用和游戲，是一款工具產(chǎn)品，也是一款商業(yè)化產(chǎn)品，既協(xié)助開(kāi)發(fā)者獲客的同時(shí)促進(jìn)合規(guī)，也要在幫助用戶獲取應(yīng)用時(shí)做好風(fēng)險(xiǎn)管控。對(duì)于上線的需求有著嚴(yán)格的評(píng)估流程，會(huì)經(jīng)過(guò)需求、開(kāi)發(fā)、測(cè)試、上線、實(shí)驗(yàn)等各個(gè)階段的各類評(píng)審與評(píng)估。通過(guò)對(duì)應(yīng)用商店研發(fā)效能成熟度的評(píng)估，發(fā)現(xiàn)在需求管理、質(zhì)量保證和持續(xù)集成方面還有很大提升的空間，為此我們的實(shí)踐重點(diǎn)也是從這里展開(kāi)。
首先，通過(guò)需求的分層管理，將需求拆分成可以在線上進(jìn)行獨(dú)立商業(yè)驗(yàn)證的特性。在評(píng)審和設(shè)計(jì)環(huán)節(jié)，我們的過(guò)程涵蓋了產(chǎn)品、需求、策劃以及埋點(diǎn)，通過(guò)持續(xù)的評(píng)審來(lái)保證正在做正確的事情。
其次，在開(kāi)發(fā)層面，將業(yè)務(wù)特性分端拆分成不同的用戶故事，并進(jìn)行開(kāi)發(fā)和測(cè)試的閉環(huán)。整個(gè)需求流程的推進(jìn)，更多的依賴工具來(lái)驅(qū)動(dòng)，避免人工導(dǎo)致的錯(cuò)誤和流程執(zhí)行的不到位。
比如說(shuō)：
1）在需求的開(kāi)始，項(xiàng)目管理工具會(huì)自動(dòng)創(chuàng)建需求群，在策劃評(píng)審?fù)ㄟ^(guò)后，流程引擎會(huì)通知數(shù)據(jù)產(chǎn)品和設(shè)計(jì)進(jìn)行埋點(diǎn)和UI設(shè)計(jì)，在所有開(kāi)發(fā)準(zhǔn)備工作完成后，自動(dòng)進(jìn)行分端拆分用戶故事，并通知項(xiàng)目管理人員組織進(jìn)行排期。
2）在開(kāi)發(fā)完成后，項(xiàng)目管理工具會(huì)協(xié)助開(kāi)發(fā)創(chuàng)建驗(yàn)收單和測(cè)試單，并將必要的信息填充在工單中，開(kāi)發(fā)人員所需要做的就是填寫(xiě)少量的信息，并提交執(zhí)行。
最后，所有的項(xiàng)目活動(dòng)，通過(guò)項(xiàng)目管理工具流程引擎來(lái)驅(qū)動(dòng)，讓開(kāi)發(fā)專注于開(kāi)發(fā)，測(cè)試專注于測(cè)試，流程的事情交給系統(tǒng)，力求一次性把事情做對(duì)。讓項(xiàng)目團(tuán)隊(duì)持續(xù)、高效、高質(zhì)量的進(jìn)行價(jià)值交付，可以看到應(yīng)用商店2024年上半年我們將需求研發(fā)平均交付時(shí)長(zhǎng)優(yōu)化至17天。
除了上面的需求流程自動(dòng)化，我們?cè)谘邪l(fā)過(guò)程也進(jìn)行了很多優(yōu)化探索。我們?cè)谡麄€(gè)研發(fā)階段打通各個(gè)系統(tǒng)之間的交互，詳細(xì)如下：
需求階段：我們?cè)陧?xiàng)目管理工具VAPD上對(duì)需求進(jìn)行排期，確定好版本號(hào)后，通過(guò)“分支管理” 功能配合自定義的分支規(guī)范，一鍵創(chuàng)建并拉取各個(gè)服務(wù)的代碼分支。并將各個(gè)服務(wù)的分支與流水線、工單、代碼評(píng)審平臺(tái)、發(fā)布等系統(tǒng)關(guān)聯(lián)，后續(xù)所有代碼分支相關(guān)的活動(dòng)都可以自動(dòng)化的處理。
開(kāi)發(fā)階段：我們?cè)O(shè)計(jì)了六條不同規(guī)格的流水線，涵蓋了我們研發(fā)的各個(gè)階段，比如“開(kāi)發(fā)流水線”，會(huì)監(jiān)聽(tīng)所有人的代碼提交。在代碼發(fā)生變動(dòng)時(shí)會(huì)自動(dòng)執(zhí)行我們的預(yù)先定義好的各項(xiàng)任務(wù)，包括各類安全檢查，靜態(tài)代碼分析及代碼規(guī)范檢查等等，將發(fā)現(xiàn)的問(wèn)題實(shí)時(shí)通過(guò)V消息反饋給開(kāi)發(fā)團(tuán)隊(duì)，將盡可能多的檢查工作都放在開(kāi)發(fā)階段，盡早暴露編碼過(guò)程中引入的各種風(fēng)險(xiǎn)和問(wèn)題，實(shí)現(xiàn)驗(yàn)證左移。
測(cè)試階段：當(dāng)我們的開(kāi)發(fā)結(jié)束，并通過(guò) 測(cè)試平臺(tái)測(cè)試合格，制品晉級(jí)成功后，我們開(kāi)發(fā)的產(chǎn)品就可以進(jìn)行發(fā)布上線了，當(dāng)然這個(gè)過(guò)程仍然伴隨著各種自動(dòng)化工具的配合，我們的流水線會(huì)推進(jìn)整個(gè)發(fā)布過(guò)程，自動(dòng)化點(diǎn)檢平臺(tái)會(huì)對(duì)所有的功能進(jìn)行回歸、點(diǎn)檢、驗(yàn)證、灰度，確保發(fā)布功能的完善。
上線階段：最后配合埋點(diǎn)、告警、監(jiān)控、云診斷等手段，將我們的發(fā)布過(guò)程可視化。
縱觀整個(gè)過(guò)程來(lái)看，參與的角色和平臺(tái)非常的多，平臺(tái)很多都是獨(dú)立或者自動(dòng)化能力不可達(dá)，需要人工傳遞或者手動(dòng)編輯，我們將各平臺(tái)能力打通，真正實(shí)現(xiàn)狀態(tài)和數(shù)據(jù)的自動(dòng)流轉(zhuǎn)。下方也列出了我們統(tǒng)計(jì)到的一系列提效數(shù)據(jù)，從分支管理到工單自助，從需求建群到任務(wù)催辦等等，最終我們?cè)?023年實(shí)現(xiàn)開(kāi)發(fā)人力節(jié)省超過(guò)270人天
我們介紹了更多的我們?cè)陂_(kāi)發(fā)編碼階段所實(shí)踐的內(nèi)容，接下來(lái)看看在測(cè)試階段，我們做了哪些提升。
首先，測(cè)試過(guò)程中最重要的一環(huán)是我們要測(cè)試什么內(nèi)容？如何圈定測(cè)試的范圍？傳統(tǒng)的方式是我們的測(cè)試人員根據(jù)需求，配合開(kāi)發(fā)人員的意見(jiàn)來(lái)分析可能的業(yè)務(wù)影響范圍、編寫(xiě)測(cè)試用例，整個(gè)過(guò)程其實(shí)相對(duì)主觀，靠的是我們常說(shuō)的經(jīng)驗(yàn)主義，依賴于測(cè)試、開(kāi)發(fā)人員的經(jīng)驗(yàn)，對(duì)業(yè)務(wù)的理解深度，以及對(duì)上下游關(guān)聯(lián)關(guān)系的掌握程度。
其次，這個(gè)能力是因人而異的，過(guò)程也是偏主觀的，容易造成判斷錯(cuò)誤或者遺漏。所以我們要做的第一個(gè)提升就是通過(guò)工具來(lái)更客觀的分析業(yè)務(wù)的影響范圍，依據(jù)的就是代碼的差異性分析和上下游調(diào)用鏈圖譜，即通過(guò)編碼前后代碼的變化來(lái)確定哪些服務(wù)、接口受到了影響，同時(shí)結(jié)合調(diào)用鏈圖譜檢索可能被這些服務(wù)或接口影響到的上下游。這樣在一定程度是彌補(bǔ)了不同測(cè)試水平人員在主觀經(jīng)驗(yàn)上的差距，以及各個(gè)業(yè)務(wù)上下文帶來(lái)的影響。
再次，通過(guò)不同規(guī)格的流水線驅(qū)動(dòng)，執(zhí)行綁定的各類不同任務(wù)實(shí)現(xiàn)持續(xù)測(cè)試以及驗(yàn)證左移，這些任務(wù)包括了各類自動(dòng)化的檢查與驗(yàn)證，功能的、性能的以及人工介入的。
最后，通過(guò)我們的測(cè)試準(zhǔn)出門(mén)禁，確保制品的輸出質(zhì)量，并將測(cè)試過(guò)程中產(chǎn)生的數(shù)據(jù)資產(chǎn)沉淀到后續(xù)的準(zhǔn)出報(bào)告中。最終，在這些流水線和自動(dòng)化工具的支撐下，我們整個(gè)研發(fā)階段的測(cè)試活動(dòng)滲透率提升了 156%，測(cè)試執(zhí)行效率提升了 35%，版本發(fā)布的成功率也提升到了 97.27%。
四、研發(fā)效能未來(lái)規(guī)劃
從上述的近幾年在研發(fā)效能關(guān)鍵場(chǎng)景和項(xiàng)目上落地情況有了一定了解，那未來(lái)計(jì)劃如何繼續(xù)推進(jìn)研發(fā)效能呢？接下來(lái)我們就一起聊聊研發(fā)效能未來(lái)的規(guī)劃。
談到研發(fā)效能每個(gè)公司都面臨不一樣的情況，vivo互聯(lián)網(wǎng)研發(fā)效能也經(jīng)歷前前后后4個(gè)大的階段，從早期的開(kāi)源工具化時(shí)代到場(chǎng)景化業(yè)務(wù)賦能時(shí)代。
工具化時(shí)代：早2018年及以前，vivo互聯(lián)網(wǎng)還是主要以解決當(dāng)時(shí)研發(fā)管理過(guò)程中遇到的問(wèn)題和痛點(diǎn)展開(kāi)，不斷提升研發(fā)過(guò)程白屏化、自動(dòng)化，盡可能借助開(kāi)源和商業(yè)化工具JIRA、SVN、Gitlab、Jenkins、SaltStack等來(lái)提升研發(fā)運(yùn)維效率。
平臺(tái)化時(shí)代：隨著平臺(tái)種類規(guī)模增加，用戶需要基于自己的訴求去“找”平臺(tái)和工具，然而平臺(tái)也面臨著“找不到”用戶的兩難境遇。
體系化時(shí)代：我們也考慮建立體系化平臺(tái)，消除用戶與平臺(tái)的“隔離”，讓用戶能夠在平臺(tái)解決自己的訴求。
場(chǎng)景化時(shí)代：與大多數(shù)公司的發(fā)展一致，平臺(tái)經(jīng)歷多年的發(fā)展以后，隨著用戶體量、業(yè)務(wù)復(fù)雜度增加，平臺(tái)個(gè)性化、定制化訴求逐步導(dǎo)致平臺(tái)維護(hù)和使用成本進(jìn)一步增加，讓平臺(tái)研發(fā)團(tuán)隊(duì)維護(hù)成本非常高，也讓用戶的訴求受到了影響。為此，如何從用戶場(chǎng)景出發(fā)規(guī)劃和實(shí)現(xiàn)成為關(guān)鍵。
談到這里vivo互聯(lián)網(wǎng)研發(fā)效能的未來(lái)到底是什么？vivo互聯(lián)網(wǎng)研發(fā)效能團(tuán)隊(duì)結(jié)合自身經(jīng)歷來(lái)看，還是要回歸本源。結(jié)合行業(yè)的先進(jìn)理論體系，進(jìn)一步走進(jìn)業(yè)務(wù)研發(fā)團(tuán)隊(duì)，找到真正的痛點(diǎn)與訴求，幫助業(yè)務(wù)團(tuán)隊(duì)“做正確的事，把事情做正確”。
我們前面聊到對(duì)研發(fā)效能新的認(rèn)知和理解，未來(lái)我們將進(jìn)一步走進(jìn)業(yè)務(wù)來(lái)提效。我們?yōu)榇艘捕x三個(gè)北極星指標(biāo)來(lái)牽引我們的目標(biāo)達(dá)成，分別為：代碼前置變更時(shí)間1小時(shí)內(nèi)，需求研發(fā)交付時(shí)長(zhǎng)在2周內(nèi)，需求實(shí)現(xiàn)到結(jié)果閉環(huán)3周內(nèi)。
根據(jù)研發(fā)效能新的理解和目標(biāo)，我們也多次回滾本源，思考我們的最佳路徑，總結(jié)來(lái)看就5個(gè)階段，分別為：
第1階段實(shí)現(xiàn)工具全面自動(dòng)化，消除絕大部分黑屏和手工操作。
第2階段工具實(shí)現(xiàn)串聯(lián)，能夠結(jié)合項(xiàng)目研發(fā)流程初步具備自動(dòng)化流轉(zhuǎn)。
第3階段實(shí)現(xiàn)研發(fā)效能信息全面拉通，平臺(tái)之間的研效信息能夠在多個(gè)平臺(tái)間自由的共享，實(shí)現(xiàn)多維度、多角度度量識(shí)別效能低洼，并且結(jié)合研發(fā)流程不斷提升項(xiàng)目的研發(fā)效能。
第4階段之后，平臺(tái)能夠基于平臺(tái)度量的能力逐步識(shí)別項(xiàng)目?jī)?nèi)個(gè)性化研發(fā)場(chǎng)景的短板，并且結(jié)合研發(fā)效能實(shí)踐專家，深入項(xiàng)目?jī)?nèi)部，真正結(jié)合場(chǎng)景自助化、自動(dòng)化進(jìn)一步項(xiàng)目研發(fā)效能。
第5階段就不僅僅關(guān)注項(xiàng)目本身的研效，而是需要回歸需求本身去關(guān)注整體價(jià)值達(dá)成效果。
我們期望通過(guò)目標(biāo)來(lái)牽引業(yè)務(wù)，將OKR、項(xiàng)目、需求等不同層級(jí)的要素進(jìn)行連接。通過(guò)可視化看到任務(wù)分解、進(jìn)展、數(shù)據(jù)效果，以及資源投入和風(fēng)險(xiǎn)，真正意義上做到“一層支撐一層”，層層看得清、管得明。從而實(shí)現(xiàn)始終在做正確的事情。除了上面的需求流程自動(dòng)化，我們?cè)谘邪l(fā)過(guò)程也進(jìn)行了很多優(yōu)化探索。
