總第580篇 |?2023年第032篇

本文整理自美團(tuán)技術(shù)沙龍第76期《大前端研發(fā)協(xié)同效能提升與實(shí)踐》。前端團(tuán)隊(duì)在產(chǎn)研多角色協(xié)同形式上存在不同階段，而大前端多技術(shù)棧在各階段都有其獨(dú)特的實(shí)踐，同時(shí)又有類似的演進(jìn)路線。本文從到店終端團(tuán)隊(duì)移動(dòng)端和前端技術(shù)棧持續(xù)交付演進(jìn)歷程展開，分享了大前端團(tuán)隊(duì)研發(fā)流程在“標(biāo)準(zhǔn)化”、“線上化”、“自動(dòng)化”以及“數(shù)字化”的演進(jìn)經(jīng)驗(yàn)，并探討了大前端多端DevOps建設(shè)思路和未來規(guī)劃。

• 1 背景

  • 產(chǎn)研階段不同應(yīng)對(duì)的問題不同

  • 不同業(yè)務(wù)形態(tài)和基礎(chǔ)環(huán)境面對(duì)的問題不同

  • 演進(jìn)策略概覽

• 2 標(biāo)準(zhǔn)化

  • 標(biāo)準(zhǔn)化背景

  • 標(biāo)準(zhǔn)化生產(chǎn)過程

  • 基礎(chǔ)設(shè)施支撐規(guī)范落地

  • 研發(fā)規(guī)范落地

• 3 產(chǎn)研協(xié)同

  • 協(xié)同成本增加

  • 終端場(chǎng)景能力增加

  • 如何基于終端特點(diǎn)解決這些問題？

  • 用簡(jiǎn)單無門檻的操作解決全流程痛點(diǎn)

  • 終端掃碼配置方案挑戰(zhàn)點(diǎn)

  • 工具化解決流程管理難點(diǎn)

• 4 持續(xù)交付體系

  • 早期：發(fā)布流程線上化

  • 中期：動(dòng)態(tài)化交付復(fù)雜度增加

  • 大前端背景下的新問題

• 5 Q&A

1 背景

在我們?nèi)粘９ぷ髦校獙?shí)現(xiàn)需求的快速和高質(zhì)量交付，關(guān)鍵在于提升效率和質(zhì)量。然而，在實(shí)踐中很難找到一個(gè)通用策略，能同時(shí)針對(duì)效率和質(zhì)量進(jìn)行優(yōu)化。這是因?yàn)樵诓煌膱?chǎng)景下，對(duì)效率和質(zhì)量會(huì)產(chǎn)生不同的解讀。例如，在需求研發(fā)階段，研發(fā)團(tuán)隊(duì)可能更注重提升工程效率和代碼質(zhì)量；而測(cè)試團(tuán)隊(duì)可能會(huì)更關(guān)注平臺(tái)的穩(wěn)定性和需求的質(zhì)量；產(chǎn)品團(tuán)隊(duì)則可能聚焦于縮短交付周期和提高資源的有效使用。

在深入探討具體的研發(fā)場(chǎng)景時(shí)，我們遇到了若干挑戰(zhàn)。首先，一個(gè)完整的交付流程涵蓋了從需求開發(fā)到產(chǎn)品上線的各個(gè)階段，涉及產(chǎn)品、研發(fā)、測(cè)試等關(guān)鍵角色，每個(gè)人的職責(zé)各有側(cè)重，且整個(gè)過程依賴于持續(xù)的溝通與協(xié)作。在這個(gè)環(huán)節(jié)中，我們常會(huì)遇到這樣的問題：盡管每個(gè)人都忙碌，但整體效率卻并沒有明顯的提升；即便對(duì)單一環(huán)節(jié)進(jìn)行了優(yōu)化，但優(yōu)化效果并沒有直接讓整個(gè)需求的時(shí)間縮短，有時(shí)甚至?xí)?dǎo)致資源等待時(shí)間變長(zhǎng)。

對(duì)于第一個(gè)問題，這通常不是個(gè)人能力的問題，而是因?yàn)槲覀冊(cè)诋a(chǎn)研協(xié)同流程或資源管理工具上還有改進(jìn)的空間。而第二個(gè)問題，可以舉個(gè)例子這樣理解：假設(shè)一個(gè)研發(fā)任務(wù)預(yù)計(jì)需要3天完成，一個(gè)高效的研發(fā)人員可能在1天內(nèi)就完成了開發(fā)工作。然而，在實(shí)際的工作流程中，這樣的個(gè)人優(yōu)化并不會(huì)直接把5天的需求變?yōu)?天。因?yàn)殚_發(fā)后還需要進(jìn)行多個(gè)步驟，如前/后端聯(lián)調(diào)、需求驗(yàn)收、測(cè)試用例編寫等，因此個(gè)人的單點(diǎn)優(yōu)化很難對(duì)整個(gè)項(xiàng)目產(chǎn)生顯著的影響。

因此，面向全流程優(yōu)化的關(guān)鍵在于采取一個(gè)全面的視角，關(guān)注整個(gè)團(tuán)隊(duì)和協(xié)作流程的改進(jìn)。只有當(dāng)我們從整體出發(fā)，全面優(yōu)化各個(gè)團(tuán)隊(duì)的工作流程和協(xié)同機(jī)制，我們才能真正實(shí)現(xiàn)縮短交付周期、提高效率和質(zhì)量的目標(biāo)。

| 產(chǎn)研階段不同應(yīng)對(duì)的問題不同

在進(jìn)行分階段優(yōu)化時(shí)，各個(gè)企業(yè)在需求、研發(fā)和運(yùn)維這些關(guān)鍵階段通常都已經(jīng)擁有一些成熟的解決方案或產(chǎn)品。例如，在需求階段，企業(yè)通常會(huì)利用需求管理和排期管理工具；而在研發(fā)階段，則廣泛采用各種成熟的CI/CD工具（這個(gè)階段進(jìn)一步細(xì)分為多個(gè)子階段，每個(gè)子階段都有其特定的目標(biāo)和潛在的提升點(diǎn)）。為了有效地進(jìn)行優(yōu)化，首先需要建立一個(gè)清晰的流程規(guī)范，明確各個(gè)階段的具體任務(wù)和目標(biāo)。隨后，將這些明確的規(guī)范轉(zhuǎn)化為線上化的操作，通過人力資源的有效配置，以自動(dòng)化的方式實(shí)現(xiàn)效率和質(zhì)量的雙重提升。

| 不同業(yè)務(wù)形態(tài)和基礎(chǔ)環(huán)境面對(duì)的問題不同

總結(jié)起來，優(yōu)化方向主要有兩個(gè)：首先是全面提升產(chǎn)研協(xié)同的效率，其次是通過建立標(biāo)準(zhǔn)化、線上化，進(jìn)而實(shí)現(xiàn)自動(dòng)化的過程進(jìn)行優(yōu)化。然而，根據(jù)不同公司和業(yè)務(wù)形態(tài)的具體情況，這兩方面的具體感受和需求也會(huì)有所不同。

以美團(tuán)的業(yè)務(wù)技術(shù)形態(tài)為例，早期時(shí)，技術(shù)棧主要是Native和Web獨(dú)立運(yùn)營(yíng)，各個(gè)團(tuán)隊(duì)“各自為政”，效率和質(zhì)量的提升很大程度上取決于團(tuán)隊(duì)的規(guī)范執(zhí)行情況和個(gè)人的編碼習(xí)慣。因此，這一階段最主要的痛點(diǎn)在于缺乏統(tǒng)一的標(biāo)準(zhǔn)和最佳實(shí)踐。

進(jìn)入中期，開始逐漸采用動(dòng)態(tài)化技術(shù)，一些需求也開始具備跨iOS和Android的能力。發(fā)版模式從原先的Native“火車發(fā)版”轉(zhuǎn)變?yōu)閯?dòng)態(tài)發(fā)版，產(chǎn)研交付的頻次大幅增加，從兩周一版變成了一周甚至一天一版。這一變化極大地考驗(yàn)了團(tuán)隊(duì)的協(xié)同能力和快速發(fā)版的能力。因此，這個(gè)階段的挑戰(zhàn)在于如何通過工具化的方式有效整合資源，以及如何適應(yīng)快速變化和發(fā)展的節(jié)奏。

目前階段，美團(tuán)的業(yè)務(wù)已全面擁抱動(dòng)態(tài)化，并在多個(gè)場(chǎng)景下實(shí)現(xiàn)了一碼多端的能力。從之前的iOS、Android到現(xiàn)在的多端對(duì)齊，研發(fā)的差異性和管理成本、質(zhì)量風(fēng)險(xiǎn)都有所增加。因此，當(dāng)前階段的核心問題是如何通過一套統(tǒng)一且通用的自動(dòng)化方案，來實(shí)現(xiàn)整體效率的提升和質(zhì)量的保障。

| 演進(jìn)策略概覽

帶著這些挑戰(zhàn)，我們來看下技術(shù)演進(jìn)的概覽。在初始階段，我們通過標(biāo)準(zhǔn)化解決缺乏統(tǒng)一標(biāo)準(zhǔn)和最佳實(shí)踐的問題的策略。進(jìn)入中期，我們重點(diǎn)實(shí)施了工具化和線上化策略，以應(yīng)對(duì)產(chǎn)研協(xié)同過程中出現(xiàn)的挑戰(zhàn)。當(dāng)前階段，我們正專注于利用綜合的大前端DevOps方法，旨在統(tǒng)一跨技術(shù)棧的流程并顯著提升效率。

2 標(biāo)準(zhǔn)化

什么是標(biāo)準(zhǔn)化？為什么要做標(biāo)準(zhǔn)化？為什么大家都是共同實(shí)踐出來的經(jīng)驗(yàn)，A說的就是標(biāo)準(zhǔn)，B說的就不標(biāo)準(zhǔn)？帶著這些問題我們這里先展開標(biāo)準(zhǔn)化的建設(shè)過程。

| 標(biāo)準(zhǔn)化背景

如圖中所示，前端標(biāo)準(zhǔn)化實(shí)施之前，從業(yè)務(wù)規(guī)范到技術(shù)選型，差異顯著，且難以判斷各種方案的優(yōu)劣，每個(gè)團(tuán)隊(duì)均根據(jù)自身的經(jīng)驗(yàn)實(shí)施各異的實(shí)踐。

在此背景下，我們面臨了所謂的“三高”問題：

• 操作成本高：缺乏統(tǒng)一流程標(biāo)準(zhǔn)，相同的工作流在不同團(tuán)隊(duì)中執(zhí)行方式各異。例如，在處理故障時(shí)，快速實(shí)現(xiàn)跨團(tuán)隊(duì)的止損方式和優(yōu)先級(jí)判定共識(shí)極為困難。

• 學(xué)習(xí)成本高：由于工程結(jié)構(gòu)、技術(shù)選型和周邊能力的差異，新成員或跨團(tuán)隊(duì)協(xié)作時(shí)的學(xué)習(xí)成本高，適配難度大。

• 維護(hù)成本高：工具的重復(fù)建設(shè)，同一環(huán)節(jié)可能存在多套保障工具，質(zhì)量參差不齊，且問題碎片化嚴(yán)重，導(dǎo)致維護(hù)成本激增。

面對(duì)這些挑戰(zhàn)，我們亟需制定一套全面的標(biāo)準(zhǔn)化落地流程。

| 標(biāo)準(zhǔn)化生產(chǎn)過程

首先，從制定標(biāo)準(zhǔn)的生產(chǎn)過程入手，建立規(guī)范的生產(chǎn)標(biāo)準(zhǔn)和討論流程，明確誰(shuí)將負(fù)責(zé)制定和決策標(biāo)準(zhǔn)。接著，通過實(shí)施分層次的規(guī)范，從基礎(chǔ)設(shè)施和基本規(guī)范到業(yè)務(wù)層規(guī)范，逐步實(shí)施。最終，當(dāng)規(guī)范在業(yè)務(wù)側(cè)得以實(shí)施后，應(yīng)通過監(jiān)控工具和運(yùn)營(yíng)大盤指標(biāo)來確保這些標(biāo)準(zhǔn)得到有效執(zhí)行。

| 基礎(chǔ)設(shè)施支撐規(guī)范落地

基礎(chǔ)設(shè)施、研發(fā)規(guī)范和研發(fā)流程三方面的標(biāo)準(zhǔn)化統(tǒng)一。

| 研發(fā)規(guī)范落地

業(yè)務(wù)規(guī)范和技術(shù)選型的統(tǒng)一。

3 產(chǎn)研協(xié)同

| 協(xié)同成本增加

在動(dòng)態(tài)化改造的背景下，我們從之前各技術(shù)棧獨(dú)立運(yùn)維轉(zhuǎn)向了合并至一個(gè)統(tǒng)一的開發(fā)和發(fā)布流程。這一轉(zhuǎn)變帶來了人員和團(tuán)隊(duì)角色的顯著變化。隨著多端技術(shù)的整合，原先專注于單一平臺(tái)的研發(fā)和測(cè)試人員現(xiàn)在需要同時(shí)關(guān)注多個(gè)平臺(tái)，人和團(tuán)隊(duì)的職責(zé)都被放大，同時(shí)復(fù)雜度大幅增加了。

| 終端場(chǎng)景能力增加

隨著終端的不斷建設(shè)，能力逐漸豐富，場(chǎng)景也越來越復(fù)雜。這些終端能力在不同App、iOS、Android上的實(shí)現(xiàn)也都各異。高門檻及一系列復(fù)雜操作讓終端研發(fā)和測(cè)試頭痛不已。

舉幾個(gè)研發(fā)中常遇到的情況：1. 前端問后端的接口怎么出問題了，是不是你們又變更了部署？后端又反問前端，你切環(huán)境了嗎，泳道是不是正確？2. 測(cè)試問研發(fā)這個(gè)Bug怎么沒有修？研發(fā)開始反確認(rèn)，容器鎖包鎖了沒有，環(huán)境對(duì)不對(duì)，AB策略切了沒有，灰度鏈路是否正確？3. 團(tuán)隊(duì)來了新同學(xué)，這些問題差異又就會(huì)被無限放大，在某APP/某端上，到底怎么切灰度鏈路，怎么設(shè)置環(huán)境，怎么鎖包這一系列的問題。

這些問題十分阻礙整個(gè)需求的研發(fā)，但卻頻繁的在日常研發(fā)中遇到。

| 如何基于終端特點(diǎn)解決這些問題？

好的功能往往需要用最簡(jiǎn)單的方式呈現(xiàn)，比如移動(dòng)支付僅是通過“掃一掃”的方式（幾乎沒有操作成本，而且零學(xué)習(xí)成本）解決復(fù)雜場(chǎng)景，“掃一掃”的背后可能會(huì)解決像入網(wǎng)支付、支付安全性等一系列復(fù)雜問題，但呈現(xiàn)給用戶是簡(jiǎn)單的“掃一掃”操作。

因?yàn)榻K端本身和服務(wù)端、Web不一樣，它有一些原生的能力，那我們是否也可以把這種復(fù)雜的方式，用最簡(jiǎn)單的方式呈現(xiàn)？

| 用簡(jiǎn)單無門檻的操作解決全流程痛點(diǎn)

| 終端掃碼配置方案挑戰(zhàn)點(diǎn)

在方案設(shè)計(jì)過程中，我們面臨了幾項(xiàng)技術(shù)挑戰(zhàn)。首先，推動(dòng)基礎(chǔ)設(shè)施的統(tǒng)一是一項(xiàng)艱巨任務(wù)。鑒于公司內(nèi)有眾多基礎(chǔ)設(shè)施團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)負(fù)責(zé)獨(dú)立的應(yīng)用、平臺(tái)或功能，要統(tǒng)一這些分散的基建到一個(gè)共同標(biāo)準(zhǔn)，并推動(dòng)大規(guī)模的改造，既困難且成本高昂。其次，即使推動(dòng)了基礎(chǔ)設(shè)施能力的標(biāo)準(zhǔn)化，由于終端技術(shù)不斷進(jìn)化且新功能持續(xù)增加，如果依賴單一團(tuán)隊(duì)來維護(hù)所有擴(kuò)展，不僅成本高昂，還容易導(dǎo)致團(tuán)隊(duì)過度勞累。

針對(duì)這些技術(shù)挑戰(zhàn)，我們采用了結(jié)合原生特性的方法。例如，引入了動(dòng)態(tài)化能力來解決跨端一致性問題，使用原生技術(shù)解除了雙向依賴，并通過按需加載機(jī)制來避免對(duì)業(yè)務(wù)邏輯的影響。最終，實(shí)現(xiàn)了兩大插件化能力：一是框架插件化，允許無依賴地集成至各個(gè)應(yīng)用中，提供運(yùn)行時(shí)檢查和掛載能力。二是功能插件化，允許業(yè)務(wù)團(tuán)隊(duì)在自己的業(yè)務(wù)組件和倉(cāng)庫(kù)中，按照標(biāo)準(zhǔn)接口實(shí)現(xiàn)和快速低成本地新增功能插件。

| 工具化解決流程管理難點(diǎn)

最終，我們落地了這個(gè)低成本、高易用性的方案，即一碼全流程方案，有效解決了過去依賴文檔或大量口頭溝通才能實(shí)現(xiàn)的產(chǎn)研協(xié)同問題。現(xiàn)在，通過一個(gè)二維碼就可以串聯(lián)整個(gè)終端研發(fā)流程，無需反復(fù)確認(rèn)操作步驟，也不用關(guān)心具體哪個(gè)端、哪個(gè)App需要怎樣操作，所有復(fù)雜的操作都隱含在“掃一掃”的背后。

同時(shí)，由于配置的自動(dòng)化和可控性，方案還順利整合了美團(tuán)的自動(dòng)化測(cè)試工具體系，促進(jìn)了自動(dòng)化的精準(zhǔn)控制。結(jié)合正在建設(shè)的DevOps平臺(tái)，我們實(shí)現(xiàn)了從產(chǎn)研信息的自動(dòng)化采集到二維碼的自動(dòng)生成；此外，還可以通過二維碼反解出當(dāng)時(shí)各個(gè)驗(yàn)收環(huán)境的具體配置，實(shí)現(xiàn)了可追溯性和便于管理。

4 持續(xù)交付體系

在流程和規(guī)范之上是團(tuán)隊(duì)基礎(chǔ)設(shè)施，有句老話是“基礎(chǔ)設(shè)施承載團(tuán)隊(duì)的流程規(guī)范”，所以不同階段、不同規(guī)范需要依托不同基礎(chǔ)設(shè)施來落地。持續(xù)交付基礎(chǔ)設(shè)施作為我們需求交付過程中的核心環(huán)節(jié)或者硬卡控平臺(tái)（硬卡控是我們?cè)诎l(fā)布過程中，如果某一個(gè)環(huán)節(jié)不符合規(guī)范，那就作為卡控形式攔截線上風(fēng)險(xiǎn)），持續(xù)交付平臺(tái)也成為整個(gè)流程和規(guī)范落地過程中的核心抓手。接下來，會(huì)主要分享持續(xù)交付基礎(chǔ)設(shè)施從線上化到數(shù)字化的演進(jìn)過程。

| 早期：發(fā)布流程線上化

前文提到，在早期階段，團(tuán)隊(duì)完成了對(duì)前端發(fā)布流程的標(biāo)準(zhǔn)化，但團(tuán)隊(duì)前端項(xiàng)目數(shù)量不斷擴(kuò)張，多樣性的工程化與規(guī)范定制訴求導(dǎo)致了我們腳手架的碎片化程度高、重復(fù)工程化建設(shè)、上線質(zhì)量不可控、約束流程不健全等問題。所以我們?cè)谶@個(gè)階段做了線上化、可定制的交付流程解決這個(gè)問題，也進(jìn)一步成為了團(tuán)隊(duì)前端的持續(xù)交付平臺(tái)。

如下圖可以看到，除了底層的基礎(chǔ)依賴，核心支撐團(tuán)隊(duì)規(guī)范的是一個(gè)可編排流水線，在它基礎(chǔ)上提供了不同場(chǎng)景下的卡控能力，比如源碼拉取、審批、代碼檢查、解禁、發(fā)布、周知等，承載了團(tuán)隊(duì)標(biāo)準(zhǔn)化所定義的一些基礎(chǔ)規(guī)范。此外，加上項(xiàng)目管理和發(fā)布報(bào)告，組成了團(tuán)隊(duì)早期持續(xù)交付的基礎(chǔ)能力。同時(shí)可以對(duì)團(tuán)隊(duì)不同場(chǎng)景提供能力定制，比如有不同類型項(xiàng)目的發(fā)布配置、在前端有不同發(fā)布類型自定義、團(tuán)隊(duì)流程的自定義。在這些能力之上，支撐了早期團(tuán)隊(duì)不同類型的交付場(chǎng)景，比如Web、動(dòng)態(tài)化、小程序、NPM等。

用團(tuán)隊(duì)實(shí)際場(chǎng)景來舉例，從團(tuán)隊(duì)標(biāo)準(zhǔn)流水線來看，我們將團(tuán)隊(duì)的標(biāo)準(zhǔn)化規(guī)范內(nèi)置到默認(rèn)流水線中，例如在默認(rèn)流水線里提供了Lint規(guī)范檢查、單測(cè)檢查、工程依賴收集、標(biāo)準(zhǔn)化檢查等。

在這個(gè)基礎(chǔ)上，團(tuán)隊(duì)可以定義擴(kuò)展自己的流程規(guī)范，比如在線上發(fā)布的過程提供域名安全檢查/是否包含不合規(guī)域名、ES高級(jí)語(yǔ)法檢查以及上線后的數(shù)據(jù)監(jiān)控，既滿足了標(biāo)準(zhǔn)規(guī)范的卡控，又滿足了團(tuán)隊(duì)能力定制擴(kuò)展的訴求。

除了存量項(xiàng)目通過標(biāo)準(zhǔn)規(guī)范進(jìn)行流程卡控，對(duì)于增量項(xiàng)目我們也期望同樣保持標(biāo)準(zhǔn)不劣化，所以在持續(xù)交付的解決方案里，我們也內(nèi)置了一鍵初始化基礎(chǔ)能力，做到項(xiàng)目創(chuàng)建即標(biāo)準(zhǔn)，除了10分鐘完成項(xiàng)目從創(chuàng)建到發(fā)布外，其本身也默認(rèn)符合團(tuán)隊(duì)的標(biāo)準(zhǔn)化規(guī)范。

為了把這套能力更好的提供給業(yè)務(wù)團(tuán)隊(duì)，平臺(tái)在基礎(chǔ)能力之上提供了不同場(chǎng)景差異性的解決方案，為不同場(chǎng)景、不同階段的團(tuán)隊(duì)對(duì)于規(guī)范的訴求差異性提供不同的基礎(chǔ)能力。

• 探索期團(tuán)隊(duì)的訴求是想快速驗(yàn)證業(yè)務(wù)可行性，團(tuán)隊(duì)內(nèi)的規(guī)范定義相對(duì)比較少，我們會(huì)提供開箱即用的最佳實(shí)踐給團(tuán)隊(duì)，使用默認(rèn)的這套規(guī)范快速交付。

• 成長(zhǎng)期的團(tuán)隊(duì)逐漸有了對(duì)于業(yè)務(wù)場(chǎng)景的定義或特定場(chǎng)景下的規(guī)范，我們會(huì)提供可定制的持續(xù)交付能力，例如“期望在特定階段完成自己業(yè)務(wù)項(xiàng)的檢查”或者“要求團(tuán)隊(duì)所有發(fā)布需 TL 審批”等這種定制性的規(guī)范，可以低成本擴(kuò)展在持續(xù)交付過程中。

• 成熟的團(tuán)隊(duì)一般有自己完整的標(biāo)準(zhǔn)化規(guī)范，我們就需要將持續(xù)交付基礎(chǔ)能力拆解為相對(duì)細(xì)粒度的API，給成熟團(tuán)隊(duì)拼裝自己完整的定制化交付流程。

第一個(gè)階段，我們將標(biāo)準(zhǔn)化結(jié)合持續(xù)交付平臺(tái)完成發(fā)布流程的線上化落地，通過靈活的定制化能力支撐不同業(yè)務(wù)場(chǎng)景，累計(jì)支撐了美團(tuán)上千個(gè)前端團(tuán)隊(duì)的項(xiàng)目發(fā)布流程升級(jí)。

| 中期：動(dòng)態(tài)化交付復(fù)雜度增加

動(dòng)態(tài)化場(chǎng)景的引入是一把雙刃劍，其本身會(huì)提升業(yè)務(wù)交付價(jià)值效率，但也也增加了研發(fā)流程復(fù)雜度。無論在開發(fā)、測(cè)試還是發(fā)布階段，我們從原來的單一關(guān)注App以及App測(cè)試和發(fā)布過程，變成了需要同時(shí)關(guān)注App和多個(gè)動(dòng)態(tài)化Bundle的交付全流程，增加了研發(fā)交付的復(fù)雜度。比如原來開發(fā)只需關(guān)注某個(gè)App單倉(cāng)庫(kù)單分支流程，但如果在動(dòng)態(tài)化場(chǎng)景，除了要關(guān)注App，也需要關(guān)注 Bundle可能分散在不同的倉(cāng)庫(kù)，研發(fā)的流程可能就是多倉(cāng)庫(kù)多分支、對(duì)應(yīng)不同Bundle的測(cè)試線上灰度流程和以及線上指標(biāo)。

面對(duì)這種復(fù)雜度增加的情況，如何支撐團(tuán)隊(duì)定義的產(chǎn)研流程/流程規(guī)范的落地？我們的解決方案是動(dòng)態(tài)化DevOps，即將全流程通過線上托管的形式降低研發(fā)同學(xué)在交付過程中的復(fù)雜度。

如圖是在動(dòng)態(tài)化DevOps所提供的解決方案，除了兩側(cè)DevOps的常規(guī)能力即項(xiàng)目管理&配置和線上技術(shù)運(yùn)營(yíng)基礎(chǔ)能力外，平臺(tái)對(duì)團(tuán)隊(duì)流程規(guī)范內(nèi)置支持，例如“產(chǎn)研協(xié)同流程”、“多人協(xié)作場(chǎng)景下的規(guī)范”、“研發(fā)流程規(guī)范”、“交付流程規(guī)范”等，平臺(tái)的核心能力是工作流，通過平臺(tái)定義的工作流將交付過程中的開發(fā)集成、構(gòu)建測(cè)試和部署發(fā)布全流程托管起來，輔助研發(fā)提效。

還是以團(tuán)隊(duì)實(shí)際場(chǎng)景舉例，平臺(tái)工作流覆蓋了研發(fā)和發(fā)布過程，同時(shí)定義了研發(fā)和發(fā)布的具體階段。研發(fā)可以按流程或規(guī)范分為開發(fā)、集成、構(gòu)建/部署、測(cè)試這4個(gè)階段，在不同階段，平臺(tái)以工作流形式將標(biāo)準(zhǔn)動(dòng)作或流程規(guī)范內(nèi)置在工作流節(jié)點(diǎn)中，比如可以在平臺(tái)上創(chuàng)建符合規(guī)范的分支，開發(fā)完成后，自動(dòng)進(jìn)行測(cè)試包構(gòu)建、部署以及自動(dòng)化測(cè)試和PM、QA的驗(yàn)收。研發(fā)過程中，除了將標(biāo)準(zhǔn)流程內(nèi)置，也將產(chǎn)研協(xié)同的流程內(nèi)置到這套工作流里，輔助規(guī)范落地的同時(shí)支撐產(chǎn)研協(xié)同效率。

同樣，在發(fā)布階段，我們將發(fā)布流程進(jìn)行標(biāo)準(zhǔn)化定義并線上化，讓工作流自動(dòng)執(zhí)行，輔助交付流程符合標(biāo)準(zhǔn)/研發(fā)協(xié)作規(guī)范。

總之，動(dòng)態(tài)化DevOps完成了動(dòng)態(tài)化場(chǎng)景全流程線上化，通過平臺(tái)能力降低了交付的復(fù)雜度，同時(shí)我們將協(xié)同流程和研發(fā)規(guī)范進(jìn)行平臺(tái)內(nèi)置，守住了質(zhì)量底線。

| 大前端背景下的新問題

隨著我們業(yè)務(wù)的演進(jìn)，越來越多業(yè)務(wù)交付到多種前端場(chǎng)景，比如某些業(yè)務(wù)既涉及到Web/H5交付也需要?jiǎng)討B(tài)化交付，甚至C端業(yè)務(wù)可能既有H5又有小程序同時(shí)又有動(dòng)態(tài)化，業(yè)務(wù)形態(tài)決定了需要交付的場(chǎng)景，以交付流程來審視，它是多個(gè)維度的復(fù)雜問題。

除了持續(xù)交付領(lǐng)域流程，即從需求到發(fā)布再到度量，還有大前端不同交付端的維度，比如一個(gè)項(xiàng)目既要交付H5，又要有小程序、動(dòng)態(tài)化，同時(shí)需要Native的配合。還有第三個(gè)維度就是不同團(tuán)隊(duì)對(duì)交付的技術(shù)棧以及不同階段的定義規(guī)范不一樣。

雖然之前解決了部分場(chǎng)景下比如解決了H5/小程序的發(fā)布流程、線上化的問題，還解決了動(dòng)態(tài)化場(chǎng)景下的定制和線上化訴求，但是大前端、多團(tuán)隊(duì)視角下還是存在流程/規(guī)范落地的瓶頸。

那這些瓶頸都有哪些？我們總結(jié)了一下，主要包括以下三點(diǎn)：

1. 研發(fā)周期涉及平臺(tái)多，老人靠經(jīng)驗(yàn)、新人靠詢問。

2. 各技術(shù)棧研發(fā)流程平臺(tái)的差異性，導(dǎo)致團(tuán)隊(duì)學(xué)習(xí)成本和能力重復(fù)建設(shè)問題。

3. 各團(tuán)隊(duì)基于標(biāo)準(zhǔn)規(guī)范擴(kuò)展業(yè)務(wù)規(guī)范，規(guī)范落地分散，落地效果參差不齊。

那么在這種背景下，我們的解決方案是大前端DevOps，提供給美團(tuán)內(nèi)部前端團(tuán)隊(duì)的研發(fā)工作臺(tái)，分為四個(gè)能力：

• 第一，它涵蓋了產(chǎn)研全流程，即從開始到需求、關(guān)聯(lián)設(shè)計(jì)稿、自動(dòng)創(chuàng)建分支，到最后上線、發(fā)布、周知等全流程所涉及到的能力；

• 第二，它支持團(tuán)隊(duì)定制，即允許在標(biāo)準(zhǔn)流程基礎(chǔ)之上，各個(gè)團(tuán)隊(duì)有自己的場(chǎng)景定制；

• 第三，我們需要在這個(gè)流程中整合公司內(nèi)部的基建，輔助在這個(gè)過程中因?yàn)槠脚_(tái)多或者各技術(shù)棧場(chǎng)景不一樣導(dǎo)致學(xué)習(xí)成本高問題；

• 第四，它一定要支持團(tuán)隊(duì)不同的大前端技術(shù)場(chǎng)景。

下圖是我們對(duì)大前端DevOps平臺(tái)的架構(gòu)分層。

在底層，我們對(duì)于公司的前端基礎(chǔ)設(shè)施進(jìn)行了深度整合，并對(duì)大前端標(biāo)準(zhǔn)研發(fā)流程內(nèi)置。

核心能力層通過工作流的編排以及定制化節(jié)點(diǎn)市場(chǎng)提供前端不同團(tuán)隊(duì)的場(chǎng)景定制，通過團(tuán)隊(duì)自研的工作流引擎支撐多樣化的工作流執(zhí)行。

工作流本身也是研發(fā)同學(xué)在日常工作中大絕大多數(shù)的工作場(chǎng)景，工作流可以內(nèi)置團(tuán)隊(duì)研發(fā)規(guī)范，比如分支規(guī)范、卡控規(guī)范和部署規(guī)范，這些規(guī)范節(jié)點(diǎn)組成了工作流最小原子，不同技術(shù)棧、不同團(tuán)隊(duì)共享一個(gè)規(guī)范配置池，這樣就解決了對(duì)于不同團(tuán)隊(duì)、技術(shù)棧對(duì)于同質(zhì)化能力的重復(fù)建設(shè)問題。除此之外，工作流本身基于產(chǎn)研全流程，我們?cè)谌鞒搪顸c(diǎn)提供精確的研發(fā)過程數(shù)字化能力，輸出團(tuán)隊(duì)研發(fā)度量數(shù)據(jù)。

如圖流程所示，通過標(biāo)準(zhǔn)工作流承載了的團(tuán)隊(duì)規(guī)范和產(chǎn)研流程，比如在流程里提供了標(biāo)準(zhǔn)分支創(chuàng)建、Lint檢查、產(chǎn)研協(xié)作動(dòng)作、安全檢查、灰度規(guī)范以及上線后的標(biāo)準(zhǔn)動(dòng)作。

同時(shí)我們會(huì)在工作流內(nèi)置研發(fā)前需求方案的一鍵創(chuàng)建、智能評(píng)估能力，研發(fā)中灰度異常指標(biāo)自動(dòng)采集、自動(dòng)監(jiān)控告警，研發(fā)后需求數(shù)據(jù)整理歸檔的一整套輔助能力，做到團(tuán)隊(duì)新人“開箱即用”。

在標(biāo)準(zhǔn)流程中可以增加團(tuán)隊(duì)的自定義規(guī)范，在節(jié)點(diǎn)市場(chǎng)選擇的基礎(chǔ)能力，無縫整合公司基礎(chǔ)能力，例如可以在特定階段創(chuàng)建分支、在某個(gè)階段查看代碼信息、在上線階段觸發(fā)某個(gè)端的側(cè)/正式包構(gòu)建，通過節(jié)點(diǎn)能力，整合基礎(chǔ)設(shè)施，一站式閉環(huán)研發(fā)同學(xué)工作，避免這些研發(fā)過程來回跳轉(zhuǎn)造成的效率損耗。

將不同場(chǎng)景、不同階段的流程，定義成團(tuán)隊(duì)標(biāo)準(zhǔn)工作流模板，支撐不同場(chǎng)景下的標(biāo)準(zhǔn)交付動(dòng)作，當(dāng)然也可以針對(duì)一些新場(chǎng)景或者不同階段定義自己的研發(fā)工作流。

大前端DevOps做到全流程線上化，所以可以在需求過程中關(guān)聯(lián)需求信息、倉(cāng)庫(kù)信息，在不同階段提供準(zhǔn)確的研發(fā)數(shù)據(jù)，進(jìn)行全周期數(shù)據(jù)統(tǒng)計(jì)，在全流程數(shù)字化基礎(chǔ)之上，實(shí)現(xiàn)團(tuán)隊(duì)的效能度量，效能度量從宏觀角度看到研發(fā)過程中所存在的共性問題，再反過來推動(dòng)研發(fā)流程修正可能存在的問題，形成一個(gè)正向循環(huán)過程。

在這個(gè)階段，通過大前端DevOps支撐了團(tuán)隊(duì)所有前端場(chǎng)景的研發(fā)交付，承載團(tuán)隊(duì)規(guī)范、產(chǎn)研協(xié)作流程，是研發(fā)開箱即用的一站式工作臺(tái)。

團(tuán)隊(duì)的流程規(guī)范的演進(jìn)從原來的不規(guī)范到研發(fā)規(guī)范標(biāo)準(zhǔn)化，再到產(chǎn)研協(xié)同過程的升級(jí)（即從產(chǎn)研協(xié)同配置化），再到產(chǎn)研流程自動(dòng)化，為了支撐規(guī)范的落地，在持續(xù)交付基礎(chǔ)設(shè)施上，需要完成交付線上化和全流程線上化，最終在線上化基礎(chǔ)上，支撐全場(chǎng)景線上化、自動(dòng)化和數(shù)字化能力。未來整合人工智能相關(guān)能力，完成流程規(guī)范上信息觸達(dá)智能化、規(guī)范執(zhí)行智能化，在這個(gè)過程中，團(tuán)隊(duì)流程規(guī)范和基礎(chǔ)設(shè)施相輔相成、互相落地。

5 Q&A

Q1：多人、多分支的代碼管理是否有好的經(jīng)驗(yàn)可以分享？

A：分支管理有兩個(gè)維度，一是質(zhì)量相關(guān)，二是高頻操作和效率相關(guān)。根據(jù)維度不同，有不同的推進(jìn)策略。

首先質(zhì)量相關(guān)方面，由于是多人協(xié)同，首先要解決的問題是大家在流程上很難達(dá)成一致，比如開發(fā)完成后，自己拉出一個(gè)分支，直接在Master分支上穩(wěn)定分支上合，其他同學(xué)不知道TA正在Release分支上發(fā)布，這樣的沖突很難通過線下方式主動(dòng)發(fā)現(xiàn)，所以這種質(zhì)量相關(guān)的東西，我們基本上會(huì)通過流程達(dá)成統(tǒng)一和增加卡控這兩個(gè)方面做成，比如所有分支通過自動(dòng)創(chuàng)建，人工不用關(guān)心應(yīng)該從哪里檢查出什么問題，它會(huì)直接告訴我們結(jié)果，即應(yīng)該在哪里進(jìn)行操作，一方面通過自動(dòng)化方式解決流程不統(tǒng)一，一方面通過代碼檢查強(qiáng)卡控漏代碼等場(chǎng)景。

其次效率相關(guān)方面，通過高頻操作，分析哪些操作頻繁，并可以提供像自動(dòng)TPR或者智能推薦分析在哪個(gè)分支進(jìn)行什么操作，智能推薦GIT命令、快捷命令等這方式。

Q2：團(tuán)隊(duì)代碼審查有什么最佳實(shí)踐嗎？怎么平衡開發(fā)和審查任務(wù)之間的平衡？

A：這是我們持續(xù)交付過程中的標(biāo)準(zhǔn)環(huán)節(jié)，首先是定義規(guī)范，比如在這個(gè)環(huán)節(jié)有團(tuán)隊(duì)的共識(shí)規(guī)范，根據(jù)單個(gè)PR大小、Approve的數(shù)量以及每個(gè)同學(xué)所提建議的數(shù)量定義規(guī)范，這個(gè)規(guī)范和不同團(tuán)隊(duì)/項(xiàng)目有關(guān)系，通過不同場(chǎng)景定義規(guī)范，再落到交付卡控過程中，比如我們會(huì)檢查它是否達(dá)到閾值，如果沒有達(dá)到，就不允許合并，或者檢查不通過，沒有辦法進(jìn)行下一步，以這種方式實(shí)現(xiàn)了代碼審查規(guī)范的落地。

6 本文作者

彬彬，自強(qiáng)，均來自部門美團(tuán)到店事業(yè)群/平臺(tái)技術(shù)部。

----------? END? ----------

推薦閱讀

|?美團(tuán)前端研發(fā)框架Rome實(shí)踐和演進(jìn)趨勢(shì)

|?AIOps在美團(tuán)的探索與實(shí)踐——事件管理篇

|?美團(tuán)外賣iOS多端復(fù)用的推動(dòng)、支撐與思考文章來源地址http://www.zghlxwxcb.cn/news/detail-765932.html