作者|張偉（上坡）
編輯|橙子君
出品|阿裡巴巴新零售淘系技術部
在加入淘寶後，經曆了大大小小的開發和部署方式的更疊，同時也有幸在整個的變革潮流中參與過其中的一些能力的建設。今天從一個親曆者的角度，通過自身經曆與向同僚考究，從“13年石器時代”、“14年白銀時代”、“15年黃金時代”以及“未來時代”四個階段和大家聊一聊大廠是怎樣開發和部署前端代碼的。
在阿裡的淘系前端團隊，開發與部署的模式随着技術的發展，仍然正在處于不斷變化的過程中。一方面體系内外紛繁複雜的能力子產品不斷地向前發展，另一方面 LSP、DAP 等底層技術基礎也逐漸成熟。在當下我們正在通過內建研發環境 IDE 的方式，将上一個階段孵化沉澱的研發生态進行再一次的整合升華，将原有的鍊路再次重組，從當下使用者的痛點中找到突破口，發掘當下各個研發場景中的最佳能力組合，搭建通用底層平台，更新變革現有模式。
作為從 14 年實習到 15 年正式進入公司的前端開發，在前身為淘寶前端團隊的 淘系前端團隊 經曆了大大小小的開發和部署方式的更疊，同時也有幸在整個的變革潮流中參與過其中的一些能力的建設。今天從一個親曆者的角度，通過自身經曆與向同僚考究，以分階段的方式來進行回憶和描述。
回答将整個故事分成四個階段，首先是 13 年左右以代碼釋出存儲、部署改造成 Gitlab 技術體系為主旋律的 "石器時代"；14 年左右伴随着 NodeJS 技術成熟，用前端 JS 語言建設工程化工具的 "白銀時代"；從 15 年開始，在借助 NodeJS 技術完成工程化工具嘗試之後，更系統化建設線上線下前端工程化體系的 "黃金時代"；以及在當下我們正在通過用戶端、容器、算法等多元化技術打造未來研發模式的"未來時代"。
石器時代
在 13 年前，前端的研發模式其實與後端研發的方式沒有太大的差異，大部分是基于 SVN 進行 SCM 代碼管理。在完成每天的代碼研發工作後，通過指令行或者 小烏龜 等工具将代碼上傳到 SVN 伺服器中完成一天的開發流程。在部署階段，通過手動拷貝或者 FTP 上傳的方式，将測試代碼進行上傳到測試伺服器上，在完成測試之後，人工檢查下代碼版本及内容，然後進一步上傳到生産環境，完整整個研發部署流程。
在那個時期，代碼管理工具除了 SVN 之外，也出現了基于 GIT 協定實作的代碼管理工具 Gitlab。面對 SHA-1 算法帶來的版本檢測便利性、本地分布式的代碼版本控制的靈活性等優勢，我們逐漸将部門内的 SVN 研發工作流程遷移到了 Gitlab 上。同時這個變化也算是淘系前端研發變革的起源。
在經曆代碼版本管理工具切換帶來的便利同時，我們思考當時較為操作繁瑣、需要人工保證的部署流程是否也能進一步的在新的體系上得到改善。在新版釋出系統的背景下，我們在新的 Gitlab 系統所提供的各種能力中，發現可以将 webhook 機制進行一定的上層封裝，借助規則化的操作，來觸發與釋出系統的關連，自動完成釋出上線流程。我們基于 publish/版本資訊 這樣固定規則的 Git Tag 來觸發 webhook 事件通知，觸發釋出系統的調用上線流程，進而完成了第一個實際意義的前端研發全自動化釋出流程。
這個階段就像 "石器時代" 般原始，不過在完成了研發基礎設施這塊如釜底抽薪般的改造之後，為後續的發展提供了堅實基礎。同時随着前端技術發展的契機，我們也基于這套底層體系進入了新的階段。
白銀時代
在 14 年左右的時候，已經誕生 5 年多的 NodeJS 技術也逐漸變得成熟起來，當時團隊基于 NodeJS，産出了一套名為 DEF 的研發本地端 CLI 終端工具，工具的核心是一套 Node 子產品的安裝、調用管理機制。工具開發者通過将研發功能子產品封裝成 DEF 體系下的 插件 形式，通過不同 插件 子產品的調用組合，來實作對前端項目的編譯、調試、上線等操作。
在當時 KISSY 架構研發體系下，我們借助 NodeJS 的能力，通過正則比對、 UglifyJS 解析 AST 等方式進行腳本編譯處理，通過 JS 技術開始建構起前端領域的工程化工具，逐漸替代掉了以 java 體系中借助 Ant 平台實作的工具。
在當時我們除了借助使用 yeoman 等工具來完成初始化流程，也随着業務編譯建構邏輯的不斷抽象産出 建構器 這樣的基礎概念。
當時在傳統的項目組織中，建構編譯的配置邏輯與項目的代碼檔案是放置到同一個代碼目錄中。從團隊視角下，這塊建構編譯邏輯零散自由，談不上有統一的更新管理邏輯。如果團隊内某一類的研發場景建構編譯工具本身有任何的更新變化，在團隊範圍内工具的更新覆寫将需要消耗非常大的成本；與此同時，在使用者的角度，在相同類型的不同項目中，也存在着大量重複安裝的建構依賴，每一個項目在建構前也都需要安裝一遍建構依賴，在空間和時間上都有一定占比的浪費。
通過 建構器 概念将編譯建構依賴進行收斂、抽象，将項目的編譯依賴維護在一個 npm 包中。這樣編譯邏輯就從多對多變成了一對多，在大幅降低建構邏輯的空間占用的同時，也能較好的複用已經安裝的建構依賴，簡化建構環節，提升建構效率。進一步也為後續的線上建構體系埋下了伏筆。
在這個階段，NodeJS 技術也逐漸變成了我們除日常頁面開發之外的又一個基本技能。伴随着 NodeJS 工具的誕生與規模應用，前端開發與部署從 "石器時代" 進入到 "白銀時代"。随着大家對 NodeJS 體系的基本運用變得愈發成熟，我們在基礎體系的使用之上，進一步開始進行更深入的思考發散和抽象設計，開始建設更成熟的前端工程體系。
黃金時代
在團隊完成基于 NodeJS 技術的工程工具以及 Web 服務架構等基礎設施建設之後，在随後的幾年時間内，越來越多的更為成熟的線上線下的工程化體系發展起來。在那個階段設計、建設的服務、工具後續也逐漸形成了如今淘系前端研發、部署流程中的基礎設施。
▐ 研發套件
随着本地 DEF 工具的發展，越來越多工具插件雨後春筍般地湧現出來。一方面使用者有着非常多的工具選擇，基本上本地研發過程中的功能都能在插件生态中找到；但是另一方面，在實際使用者視角下，在某一個項目開發的時候，使用者需要對這個項目使用到的插件以及插件用法要有一定的熟悉程度、知道最佳的組合使用方法。随着項目逐漸變多，對于工具組合的記憶成本變得高起來，同時也需要注意到不同項目之間插件組合的切換。
在百花齊放之後，面對延伸出來的問題，在原有的本地 DEF 工具之上，我們提出了 研發套件 的概念。通過對本地研發過程中進行總結收斂，抽象出 init 初始化、dev 編譯預覽、build 建構、test 測試、publish 釋出 這五個本地工具的功能節點。将原有的插件能力根據項目研發類型進行分類後，總結沉澱出每一類研發類型的标準本地工具 --研發套件。
借助套件概念的封裝，使用者在不同項目之間研發的時候直接通過 統一的指令 ，就能完成項目研發對應工具服務的啟動使用。同時在新的本地套件體系，也能針對每一位使用者有着更細粒度、靈活的版本指定方式。配備更完善的日志監控體系，在使用工具的使用者遇到問題時能實時感覺、解決，最大程度保證一線同學本地研發工具的使用體驗。
▐ 研發部署平台
在借助 Gitlab 的 webhook 能力釋出前端資源的流程成熟之後，一方面在釋出流程上研發使用者期望有更優化的釋出體驗，另一方面團隊對于前端研發流程更體系化、結構化的流程治理、資料統計也有了更高的要求。
在這樣的背景下，我們通過打通原有鍊路上釋出能力，将釋出鍊路中各個環節進行更友好的串聯，産出了前端體系下的研發部署平台。在體驗上，使用者可以借助一個簡單的指令行指令直接開始釋出任務的啟動，簡化了釋出時 git 釋出 tag 的操作流程。在整個釋出流程中，通過長連接配接的方式将各個環節的運作資訊、日志進行傳回展示，提供了全新操作的一條釋出鍊路。使用者第一次開始對釋出流程有着更全面的掌控，從開始進行代碼的送出檢測到最後資源 cdn 上線都有着完善的資訊披露，極大的提高了釋出體驗。
基于内部 NodeJS 實作的研發部署平台，在完成了基礎鍊路的打通之後，在更體系化的角度上也逐漸地開始作為工程研發上線流程的基礎，對原有的上線釋出鍊路的進行重塑。将原有流程中的環節進行抽象，逐漸分散到 建構、檢測、釋出 三個主要步驟。在随着業務研發類型從 PC 到無線的切換過程中，基于三個基礎步驟，在執行上層也逐漸孵化出前端領域下 釋出類型 的概念。例如在當時存在着 Web 應用類型、前端資源類型、Weex 應用 等類型，底層系統針對每個細分的 釋出類型，在整體的釋出流程的細節對接上采取不同的釋出部署方案，本地研發結合套件工具，形成線上、線下鍊路關聯統一的研發組合方式，更精細化地為每一種研發模式都提供最佳的研發部署體驗。
使用者從此之後就不再需要通過 Gitlab 的 webhook 觸發釋出流程，"一鍵上線" 代表着前端工程體系又進入新的一個階段。
▐ 雲建構
在上一個階段中，我們通過将編譯邏輯經過中心化封裝的方式，借助 npm 的形式，形成了在研發編譯建構環節的規範描述。但是在部署上線環節，建構器并未與線上部署流程進行串聯，而不同的本地系統環境，同樣也會導緻建構結果的不穩定。
在當時伴随着 docker 技術的發展，我們思考通過 docker 快速啟停統一環境的能力來實作一個建構器運作的環境，通過 docker啟動的 container 容器來模拟執行本地的編譯建構流程。同時利用統一的容器環境，結合前文介紹的遷移之後的 Gitlab 提供的 commit等版本辨別資訊，能在最大程度上保證建構内容的穩定統一。
經過了一段時間的摸索，通過在體系内經曆了例如 建立前端 docker 容器叢集、串聯打通容器與應用的網路通道、建設建構任務排程政策邏輯、借助 redis 打通 docker 容器運作日志等技術環節的驗證探索之後，我們基于容器技術搭建起來了在前端持續內建領域的 雲建構 系統。
在通過淘系的 NodeJS 應用架構 midwayjs 完成線上建構能力搭建的同時，在業務側我們也在逐漸建立更友好、完善的線上建構業務邏輯。借助線上上釋出流程時調用 雲建構 服務，在整個建構任務的執行流程中，串聯起來了 建構器、倉庫、使用者 三者的業務關系。在這個關系網下，我們建立了完善的任務執行情況的排程管理，能完整記錄建構器任務執行的具體情況。
在建構器視角下，可以看到建構器針對不同倉庫的執行情況，有着完整的運作日志與建構時間、建構錯誤記錄，友善使用者針對建構器進行錯誤排查以及性能優化。而針對建構器的疊代更新，建構器開發者可以針對使用者進行灰階範圍劃分設定，在版本更疊時通過完整的灰階流程保證上線的穩定覆寫。在建構器釋出過程中如有問題，立即取消灰階進行處理。通過這樣的模式，最大化地降低釋出版本的風險。在針對橫向覆寫較大的場景下，完整的灰階釋出機制起着舉足輕重的作用。
使用者在研發過程中需要将本地建構代碼推送到倉庫的這個環節也從此變成了曆史，在源碼完成開發之後，直接送出源碼到倉庫中，執行釋出任務的同時，雲建構系統會自動建構出穩定、統一的建構産出結果。
▐ 門神
在完成在完成項目的編譯、壓縮過程之後，看似已經走到部署環節的前端資源，在面對不斷複雜起來的業務場景下，實際仍然存在着許多隐蔽的問題，而以往通過人工檢查的方式已經逐漸無法保障上線資源的可靠性。在這樣的背景下，也需要一個流程化、規範化的方式進行系統幹預、檢測，做好釋出資源的最後一道防線。
與 雲建構 類似，基于 NodeJS 搭建線上資源檢查運作環境，通過将檢查邏輯也進一步抽象化，同樣以 npm 的形式進行承載抽象出 檢查器 的概念。在使用者資源完成所有的前置處理後，再進入到門神系統并行檢查任務的執行，在完成例如 資源位址、敏感詞、代碼注釋 等等檢查之後，通過不同分級的檢查結果，回報使用者相應的處理方式。作為上線前資源的最後一道關卡。系統取名 門神 寓意保障每一次的釋出資源的上線基本品質和安全。
通過門神自動化的方式，使用者不再需要在上線前"火眼金睛"檢驗各種無法通過正常編譯工具發現的問題，輕松上線。
▐ 能力開放
一方面随着體系内前端工程領域不斷的發展，不斷有更多的研發解決方案随着業務場景的不斷發展湧現出來，另一方面随着體系内 研發部署平台、雲建構、門神 逐漸成為集團前端研發場景的事實規範和基礎設施。在這個背景下，底層能力得到了進一步抽象開放的契機，上層的業務體系可以根據自身的業務情況，通過借助成熟的底層工程中台能力搭建屬于自身業務體系的前端研發流程。
例如從阿裡體系視角下，不同的投放用戶端，不同的資源組織形式，借助通用抽象化的底層工程能力，最終讓每一個業務場景的開發者都能擁有在項目業務場景下的最佳研發體驗。
▐ 貝搭建平台
如何設計阿裡經濟體都在用的搭建服務—天馬
除了正常的項目研發，在電商體系下，特别是在營銷場景下存在着需要快速生産頁面的需求。在這樣的業務場景背景下，孵化出來了通過子產品生成頁面的搭建平台。通過将頁面進行重新劃分，分割成 頁面骨架和 頁面子產品 的方式，通過前端同學開發這些頁面元素，完成開發後進行組合搭配，同時打通業務資料流，實作快速搭建頁面的能力。
前端研發同學在完成本地子產品開發後，将子產品資源進行釋出到線上，在搭建系統中進行頁面組裝和上下文注入預覽後，完成頁面級别釋出。在底層同樣借助 NodeJS 實作的源站系統來承載 CDN 内容的分發回源，提供億萬使用者的通路預覽。這套體系經過幾代的發展更疊，已經成為當下前端研發的最核心場景之一。
大緻從 15 年開始的幾年時間裡，伴随着技術的發展，淘系前端的研發體系從最初的本地工具、研發部署平台作為排頭兵，逐漸發展成線上線下的體系化專業解決方案。在保證前端角色的研發基礎體驗不斷突破更新的同時，企業化規模化的前端工程建設将日常零散的研發形式不斷推向更體系化的、高效率的、可擴充的 研發模式，同時也為後續更上層的研發部署模式的突破和更新打下堅實的基礎。
未來時代
在逐漸成熟的工程體系之上，在最近的幾年時間内，我們也在思考面對 研發提效 這件事情上，是否還能有更突破的、面向未來的解法。随着許多内部産品不斷地改造和疊代，也不斷浮現出了星星之火可以燎原的方向和模式。
▐ D2C
imgcook 項目最初起源于可視化搭建，到目前外部看到的研發模式也是經曆了不斷的改進、變化。在整個的研發模式變化中，從外部的視角大緻經曆幾個階段 ：
第一階段: 當時的使用者的使用方式是通過頁面元素的拖拽進行頁面搭建，産出源代碼之後進行釋出上線。
第二階段: 通過建立圖像掃描引擎進行像素掃描布局，同時接入 sketch 等視覺設計工具，自動的将設計稿進行轉換，這個階段前端使用者的研發方式式就開始變化成了将視覺稿進行上傳到平台處理進行代碼轉換；
第三階段: 在當下的第三個階段，平台正通過深度學習等人工智能技術來提效圖像代碼轉換的能力，與此同時在平台端完善基礎研發鍊路的打通。内部的研發模式也正逐漸切換到了在設計、代碼的工作台中進行操作，實作一站式研發、上線的操作體驗。
目前 D2C 能力逐漸在智能化還原元件、表單、子產品、頁面的研發場景中逐漸得到驗證并收獲一定的成果。
▐ IDE
在最近的一年時間，我們也逐漸投入到了新的 IDE 方向建設中，期望通過 IDE 的平台能力來孵化新的更高效的研發模式。
▐ 外部趨勢
從外部視角來看，可以看到有兩個趨勢浮出水面。一個是 IDE 領域相關的創業公司逐漸浮現出來，出現了許多相關的創業明星公司，例如有 Eclipse 體系下的 theia ，通過相容 VSCode 接口實作的 coder，以及研發編輯領域的行業新秀 codesandbox；另一個是雲廠商的加入，AWS 收購 Cloud9、騰訊收購 Coding、Azure 提供 Codespace 服務。
在編輯器、Docker 等技術的不斷發展成熟之下，各個 IDE 相關服務廠商都希望能借助內建研發環境的能力來找到研發效率、體驗提升的機會，進而抓住使用者的痛點，擴張産品市場。
▐ 内部體系
前端研發模式随着不斷的分化、發展，湧現出越來越多的工具、服務。當下工具、服務的形式也不單單隻是前文提到的指令行終端工具，或者說終端工具也逐漸成為了富互動的工具、服務的啟動入口。同時一種業務研發模式往往也需要串聯到不同體系、不同團隊提供的研發工具、服務。舉一個例子，例如當下支付寶小程式的研發，除了基礎的編譯服務、預覽服務之外，需要用到模拟器、調試器、真機調試等等服務。
支付寶小程式其實是内部很多場景的一個縮影，支付寶小程式當下的解法其實是借助 Electron 平台打造了一款本地的 IDE 研發工具。在這樣的背景之下，體系内去年也開始了 IDE 底層體系 的搭建。期望能通過一套 IDE 底層實作線上、線下的基礎 IDE 解決方案。
借助 IDE 底層插件機制，淘系也孵化出自己的 IDE 內建研發工具，例如前文提到的 D2C 、支付寶小程式、serverless 等場景都在緊鑼密鼓的進行内部拓展和使用改進。我們通過 IDE 及 IDE 的插件體系，一方面借助 VSCode 的生态完善基本研發體驗，另一方面通過插件在 VSCode 能力範圍之上擴充的插件 UI 能力來串聯起單個項目鍊路上所涉及到的所有的工具、服務。
與以往的流程的不同的是，除了将線上的釋出部署流程進行串聯整合，研發同學在當下所有的在研發過程的操作包括 研發編碼、調試預覽、部署流程 都在統一的研發 IDE 中有機的銜接起來，直接通過研發面闆完成所有操作。這是我們為未來埋下的一顆種子，正在慢慢發芽。
整篇答案其實從一個在體系内的員工角度向大家介紹了關于淘系前端研發部署相關的一些曆程，當下的研發模式我們也在日赴夜繼的探索突破，最後介紹下團隊做的事情。
One More Thing
我們是 淘系前端團隊-工程中台團隊 ，作為淘系前端及阿裡集團前端的前端研發的基礎設施，目前在做前端工程相關的體系建設，主要有幾塊事情
- 下一代前端研發模式: 通過自建阿裡 IDE 核心底層 KAITIAN，借助底層兩端一緻、可視化插件體系等基礎能力深度整合內建現有研發服務資産，搭建當下及未來研發模式，新的領域等你來架構
- 前端工程基礎服務：基于 NodeJS、Docker 等能力建設前端研發持續內建流程，百萬級别任務量等你來優化、挑戰
-
大規模 CDN 源站: 基于 NodeJS 實作集團核心 CDN 回源核心服務，大促基礎設施，億級流量等你來"開飛機換引擎"
如果對做的事情有興趣或者對内容有想法的同學可以微信 tagzw1128或者郵箱 [email protected] 歡迎交流。
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~