本文作者上坡，來自淘系前端團隊，DEF工程平台前端負責人。
來源： Alibaba F2E公衆号
背景
DEF 研發平台從 18 年 7 月由原有淘系的釋出流程引擎平台 更新建設之後，服役到目前已經是第三個年頭了。目前以各種形式服務着淘系及集團大多數前端研發、部署的流程。随着平台的維護和發展，也遇到了一些業務上的困境和挑戰。
平台發展
從體系内部視角來看，在覆寫不同業務場景的同時， DEF 體系也逐漸變成了一個"巨石(monolithic)"應用和産品。導緻如今日常應用的産品研發、維護與穩定性保障的成本也逐漸攀升，經常在單一的需求場景中，存在着較高的複雜度和研發成本，成為了平台發展的掣肘因素。
環境的變化
從體系外部視角來看，當下的環境因素更加的艱巨。随着技術形态、業務鍊路不斷變化與發展，如今目前端同學進入到一項業務進行開發的時候，可能要經曆兩大步驟
- 熟悉業務的上線流程，例如需要通過在搭建體系中進行建立，然後在 DEF 體系中進行應用接入、研發、上線，随後再到業務的系統中做版本的管理與釋出。
- 除此之外，可能還需要了解研發項目的架構，而在當下的技術架構、模式的發展趨勢下，需要熟悉前端開發、函數開發以及在過程中需要使用到的預覽調試、模拟調試、接口測試等各個功能。
由上面舉例的情況來看，在愈發複雜的研發鍊路中，使用者對高效的，體驗更好的訴求愈發的明顯，例如期望在一個平台中完成大部分的操作，而不是在各個平台中進行操作，因為任何一個平台流程出現問題，都會因為各自為戰、平台邏輯不一緻等典型問題造成較高的協同與答疑成本。
例如 faas 函數這樣的研發場景，使用者期望能提供在業務研發過程中完善的函數配置、灰階放量、資料監控等符合技術、業務的能力的流暢功能鍊路，以及提供支撐前後端一體化這樣需要與工程、架構配套的完整解決方案能力。
随着基礎的工程流程、工程能力的成熟，從團隊視角出發，面向 品質 與 效率 提出了進一步的要求，如何在保障生産的過程規範，産物的品質有保證，釋出風險較低的同時，也能借助效率衡量模型、效率度量等方式找到效率瓶頸，不斷挖掘、提升現有研發效率。從團隊視角下對工程體系提出了更高的要求，需要在更多的核心基礎命題上發揮作用。
存在的困境
從更宏觀的視角來看，我們把當下大的使用者角色分為三類，一線研發同學、DEF 平台、研發鍊路提供平台方，按照上訴存在的問題進行推導，各個角色都互相存在着一些沖突
- DEF 方: 面向大而全的工程體系，隻能支撐較為通用的需求場景，垂直類需求改造成本較高且無法滿足最佳實作效果
- 平台方: 以支撐具體的技術選型、業務研發的鍊路建設方，依賴已有的 DEF 開放能力建設鍊路的成本較高
- 一線研發同學: 很多情況下隻能使用串通的"可用"鍊路，無法使用完全比對具體技術形态和業務邏輯的研發鍊路，體驗、效率有限
小結
最近的一年半左右時間，我們發現此類的問題和沖突不斷凸現，促使平台需要思考如何讓問題進行止血并通過體系關系層面的方式進行解決，實作在當下階段的工程體系的變化與發展。
解法思路
從宏觀視角下，我們期望從目前大的前端團隊發展、技術發展的背景下，找到既能解決當下的問題，也能為未來前端再一個"三個年頭"做好發展準備。
基礎設施完善
随着基礎低代碼、工程研發等能力的逐漸發展，平台建設成本、門檻的不斷降低。另一方面，通過平台進行鍊路的串聯與內建的方式，為搭建出擁有最好的操作體驗、研發效率、品質保證的研發鍊路提供了舞台。
我們可以看到，在這樣基礎設施環境不斷完善的環境下，出現了小二工作台、千機變這樣的平台建設與發展趨勢，通過建設比對業務的技術鍊路平台，實作技術研發以及業務視角下研發、服務鍊路體驗與效率的最大化保障。
角色的變化
順着平台化建設的思路從 DEF 體系切入來思考，我們可以歸納到，目前 DEF 體系其實也存在幾個層面的能力，以參考雲計算的分層概念進行拆分
- SAAS: DEF 體系目前最主要的服務的形式，以研發平台為主要産品陣地面向淘系及集團提供前端研發流程服務
- PAAS: 以現有 DEF 開放平台為網關及開放門戶的服務能力，主要通過以接口的形式為各個平台與服務提供前端工程服務能力
- IAAS: 主要以自建容器叢集為代表的任務排程、流程引擎系統，支撐上層研發平台及雲建構、門神、腳手架等服務
在如今通過垂直化平台、定制化建設來追求體驗、效率最大化的訴求不斷上漲的趨勢下，我們判斷在當下階段，如圖上的黃色部分需要将 PAAS 層的開放能力進一步得到加強和能力釋放。進一步做厚、做寬 PAAS 層，提供足夠穩定的、完善的工程能力，使得 SAAS 角色在下一階段由更多的上層平台體系進行承接。
調整生産關系和服務使用者，從服務一線使用者，調整為服務平台鍊路建設方，釋放掉定制化、平台搭建的生産力。一起最終為一線使用者提供更好的、效率更高的研發鍊路、平台。
垂直平台建設
以往 serverless 體系在現有 def 平台搭建的過程中，随着鍊路的能力逐漸完備，對于深度定制能力的研發成本變得越來越高。随即我們探索性地将 serverless 整個體系以單獨平台的方式進行建設，在統一的服務端底座基礎上，通過微前端的方式進行組裝搭建，保證了平台的平穩建設與增長。實作平台、DEF、使用者多方協同使函數研發鍊路的體驗與效率明顯提升。
于是工程體系在團隊與技術的發展背景下，結合現有的開放能力與垂直平台建設中的優缺點，進行頂層抽象，建設了一套通過支撐平台建設來實作業務研發提效的工程開放技術方案。
微平台開放體系方案
通過不斷補充的工程基礎能力，通過微前端等技術手段、方式，進行垂直平台的建設，同時為上層業務體系平台提供多形态、多程度的配套開放能力，提供豐富的搭建定制能力及高效搭建方案，實作高效搭建符合業務場景的工程研發鍊路，實作業務研發的最佳體驗。
整個體系建立在以
應用
、
疊代
變更
釋出
為核心的前端工程基礎概念模型上，我們對整個體系進行多個層次的拆分。
規範層
在微平台分而治之的思路下，通過基于 DEF 體系的開放能力，實作各個垂直"煙囪"的快速發展，能較快地實作短期的業務訴求，但是在面向長期發展的視角上，如果不加限制或者相關的措施保障，無疑很快就會陷入混亂的局面，無法保證服務的長期穩定。
應用接入規範
釋出流程規範
在這樣的背景下，
規範層
作為在 DEF 基礎能力之上，開放體系中 最底層 也是 最重要 的一層發揮着保障平台長期維護、使用者體驗一緻的角色。通過将前端工程研發流程中的核心環節進行标準化，通過由點連線的方式，形成的基礎保障。
例如針對核心的釋出流程，基于
流程引擎
系統的建設，以流水線的次元，按照節點規範來進行釋出邏輯、釋出結果展示的編寫，通過流水線編排來實作釋出流程的定制。在統一的流程節點規範的保障下，實作釋出流程的快速、穩定的搭建。
平台能力層
在限制開放規範的同時，面對上層業務發展過程中還需要的、以及進一步定制支援的工程能力，我們通過在平台能力上逐漸增強來解決問題。
租戶能力
在基礎能力方面，通過補齊需求管理、效能度量、租戶隔離與管理等能力，實作對當下前端環境研發鍊路中進一步需要的能力進行補齊。同時例如通過
多類型組合
的能力，實作針對複雜場景下應用釋出管道的釋出能力複用搭配的問題。
在定制層面能力上，以流程引擎搭建為代表，通過将研發流程進行打散、封裝、重組的方式，釋放定制成本，大幅提升使用者針對釋出流程的定制能力以及定制效率。
BAAS 能力
在基于規範的能力建設完成之後，需要将底層能力進一步的封裝以及表達，在 BAAS 層中，通過解決原有 def-open 開放平台存在的問題，實作對接口版本、限流控制、降級熔斷等能力的基本穩定性保障。基于 POP 的網關技術體系進行工程能力适配，基于調用用戶端 SDK 等工具能力實作穩定性、性能與業務訴求的比對。
基于新的網關能力，将現有 DEF 的基礎開放接口進行治理補齊，實作基礎能力的進一步規範化。
UI 能力層
在研發鍊路及研發平台搭建的過程中，如果使用者直接拿着 API 來進行能力的組裝來實作一個應用接入流程，即使是在工程體系對流程熟悉的同學，也需要投入一兩天的成本，對于非工程體系的同學，往往難度更大，對于業務邏輯的表達的存在着較高的成本。
在這樣的背景下，通過建設元件物料的方式，以 UI 的形式将工程能力進行規範化、标準化的組裝，同時提供定制化參數的能力，從效率出發降低工程能力的使用門檻以及平台搭建成本。
- 降低成本: 通過 UI 能力的輸出提供，釋放掉平台方對于基礎統一的工程能力的內建成本，将 UI 與工程的服務接口進行結合，實作工程能力的開箱即用
- 能力定制: 而面向使用者更進一步關心的定制能力，提供相關配置參數、回調鈎子等能力，完成使用者研發鍊路的快捷定制。
同時在核心的頁面中，以元件當做 UI 層的"原料"，進一步實作布局規範，以及布局規範之上的布局容器能力，實作類似 SPI 的擴充機制，進一步通過 UI 的機制來保障基礎體驗的一緻性。
開發者體系層
以上的幾層相當于工程體系從開放命題出發，提供出來不同層次、解決不同 點、線 層次問題的工具和能力。我們期望在上層進行工具和能力的進一步組合搭配并補齊實踐所需要的支撐能力，來形成工程能力的能力 面 。
以開發者門戶作為方案的陳列，提供不同層的搭建、定制方案，為平台搭建提供面向不同技術、業務場景的工程定制方式，實作定制、搭建效率相較以往有本質的提升。
業務場景層
目前工程體系的微平台開放體系，一方面針對現有例如 PHA、小程式、tnpm 等基礎的工程鍊路能力及平台的搭建提供支援，同時也面向例如在 商家研發體系 中支援商家資産這樣的業務場景及業務平台體系提供能力的輸出 商家微應用體系 的研發，在 行業千機變體系 中，支撐行業鍊路的研發等等。
針對不同的場景，通過開發者體系層提供的不同形态、形式的搭建與定制方案，實作工程能力的高效內建與适配。為業務鍊路中的一線業務同學，提供最複合場景的研發工作體驗。
面臨的問題
在快速向前優化、更新的同時，我們也發現了許多的問題，例如進行平台分而治之後，從頂層視角下各個平台之間也出現了一些問題。
平台間串聯流轉
随着平台的數量的逐漸穩定，各個平台之間的關聯卻在一定程度上出現了問題，特别是對于不同的研發鍊路，由各個平台劃分成了一個個孤島。導緻使用者在不同研發鍊路之間切換的成本。
一方面會在平台之間通過統一導航、搜尋來增加平台間的資訊互通區域，另一方面，我們也正在嘗試在前文 UI 部分提到的布局容器能力基礎之上再進一步抽象，實作 UI 部分和 API 部分的擴充 SPI 能力，通過更強的規範控制能力，消除平台切換的割裂感，讓使用者在不同平台之間的切換感覺像是在一個站點的形态，提升全局平台的使用體驗。
總結思考
前端工程化的命題核心需要解決的是在團隊或者企業範圍内，如何在一定的限制和規範下，實作效率與品質的最大化。随着業務場景與技術能力的不斷發展以及組織的更新，一方面對于效率品質的要求必定會有更高的提升訴求，同時在問題層面也必定會往更深的領域去探索。
工程體系作為整個生态體系的支撐角色，也嘗試在面向快速發展、高度定制場景下提出解法的同時，更進一步地在在提高服務的傳遞标準與品質，效能度量、代碼品質、安全生産等方面專項投入。
在微平台開放體系這個命題下，我們期望能實作 1 小時能接入開放能力、 1 天能完成平台形态的搭建、1 周完成研發鍊路平台的上線，進而實作場景鍊路的高效搭建，快速服務。使一線研發同學能快速體會到最佳的研發體驗。