作者：胡駿
一、背景現狀
軟體開發從傳統的瀑布流方式到敏捷開發，將軟體交付過程中開發和測試形成快速的迭代交付，但在軟體交付客戶之前或者使用過程中，還包括整合、部署、運維等環節需要進一步最佳化交付效率。因此Devops的產生將敏捷的相關理念擴充套件到運維側，從而將產品、設計、開發、測試、運維團隊更緊密的結合在一起。而從交付給客戶產品視角看，前端研發通常又是在整個產品設計開發鏈條的最終節點，意味著前端團隊受到上游變更的影響是最大的，並且從經營理念效率出發，提升前端交付效率是至關重要的。那麼如何提升交付效率呢，主要面臨以下問題：
交付效率：
1.敏態需求增加，即迭代性工作增加： 軟體開發從傳統的瀑布流方式到敏捷開發，再到現在對敏捷開發提出了更高的要求。近些年專案的迭代性需求不斷遞增，這就要求前端開發者能夠具備從開發到測試並且快速釋出上線的能力，也需要團隊完成由穩態到敏態的轉變。
2.前端研發效能瓶頸，達成雙週交付面臨挑戰： 敏捷迭代過程中，研發週期縮減並行需求增加，研發團隊難以做到開發到測試和上線的過程中，全方位保證程式碼的高質量輸出。
3.研發過程中不必要的浪費降低交付效率： 重複勞動、過度溝通、環節等待、通知不及時等。
質量&體驗：
1.質量安全把控不到位： 研發團隊大多關注程式碼和架構，對於專案如何能在生產環境穩定執行，需要考慮哪些安全性和可持續性的因素並不是很瞭解。
2.研發流程標準不同，協同開發容易出錯： 開發者的編碼風格不同，提測上線的流程不一致，關鍵流程環節的疏漏，風險行為難以約束，導致上線事故率增加。
3.不同種類的應用服務的部署方式不一致： 涉及到一些應用系統的調整、部署、擴充套件等，需要從新熟悉應用部署和構建環境的使用，使團隊對釋出沒有信心。新的服務或者應用的構建，很難快速上線，被卡在了生產環境部署階段。
二、問題分析
下圖是我們團隊之前的開發流程，黃色為關鍵流程，綠色為必備環節。
我們對各個流程環節逐一分析：
| 行雲評審 | 評審中存在過度溝通，需求規範不統一，排期定不下來 |
|---|---|
| 需求確認 | 缺少與上級溝通，私自承接確認需求 |
| 關聯分支 | 缺乏行為約束，主幹開發易造成程式碼汙染，無法約束開發者按照需求進行分支開發 |
| 程式碼開發 | 缺乏標準，開發架構不同，編碼風格不統一，打包部署命令不一致，多人協作困難 |
| 程式碼評審 | 缺乏流程卡點，開發者經常跳過程式碼評審環節，程式碼問題難以暴露，線上風險增加 |
| 程式碼檢測 | 缺乏流程卡點，易忽略檢測流程，切換多個平臺進行程式碼檢測造成時間浪費 |
| 提交測試 | 缺乏溝通，通知測試人員不及時，提測內容不健全，行雲卡片忘記變更到測試階段 |
| 提交程式碼 | 缺乏質量卡點，缺乏行為約束，人工操作程式碼提交，易造成不確定問題增加發布風險 |
| 專案上線 | 缺乏風險檢測，易忽略上線前的迴歸測試和效能最佳化，存在審批發布等待時間的浪費 |
透過對這些問題和各個團隊的反饋深入分析，發現其中最大的瓶頸在於研發協作之間的溝通壁壘、流程環節的疏漏和質量把控的不到位，而這些又是解決大多數問題的前提。
經過調研，我們發現DevOps恰恰是為這些問題而生，打造高效的交付流程成為我們破局的關鍵。
三、DevOps流水線引入
1）DevOps流水線簡介：
DevOps流水線聚焦於將專案的需求、開發、測試、部署和運營統一起來，基於整個組織的協作和應用架構的最佳化來實現敏捷開發、持續交付和應用運營的無縫整合。
2）DevOps流水線與前端開發
定位：將前端業務中多且複雜的構建流程進行整合，使其成為一條可以覆蓋前端多業務場景的流水線，為前端開發者提供服務。
使命：減少前端開發者在複雜構建流程中所消耗的時間和精力，整體提高前端開發者的工作效率。
四、DevOps流水線設計
1）架構設計
行雲流水線採用了平臺化管理+原子化設計+自定義開發模式，平臺提供基礎服務，能力可以透過原子化形式和自定義開發模式無限擴充套件，即兼顧了平臺的穩定性，又大大減低了現有工具平臺的接入成本。既有工具平臺可獨立對使用者提供服務，也可以透過標準化方式輸出外掛化原子能力，作為持續交付平臺的一環，納入軟體交付流程中，實現互利共贏，完美對接，減少重複建設，共建平臺。
行雲流水線提供了良好的環境基礎和豐富的原子準備，讓我們在構建自動化流水線時更加的方便快捷，也大大提升了我們的開發時間。我們團隊的前端DevOps流水線即是基於行雲流水線搭建。
2）流程設計
下圖是我們為團隊設計的前端DevOps自動化流水線，目的是打破開發、測試、產品、運營等不同崗位人員的溝通壁壘，讓研發團隊人員同時具備不同研發環節的能力，從而實現專案研發全流程的無縫整合。
我們來看看給前端DevOps流水線賦予了哪些能力：
1.專案流程管理的全域性視角： 我們將整個專案研發週期拆解為：需求階段、開發階段、測試階段、預上線和釋出上線。每個階段以流程節點串聯的方式自動化執行，同時以行雲卡片作為媒介顯示當前所處的流程階段。
2.精細化的程式碼質量和風險管控： 透過實現程式碼和需求的關聯，我們設計了更細粒度的質量卡點和風險管控策略。在關鍵節點約束研發操作行為，設定流程卡點並制定不同的質量檢測機制，以便在早期的質量預防、中期的風險發現和後期的問題覆盤都可以很大程度上減少成本投入。
3.自動化的流程觸發和行雲卡片流轉： 透過約定式程式碼提交，自動觸發測試流程和上線流程，解放研發在流程流轉中的額外操作和關注耗時。同時，行雲卡片會伴隨著專案階段的變更自動流轉，用於更精準的統計不同階段的投入成本。並且，高度的自動化流程也為專案帶來更高的品質和穩定性。
4.即時的訊息觸達和流程提醒： 關鍵流程節點達成，會透過咚咚和郵件的方式即時同步給相關人員，進一步降低專案研發過程中的溝通成本，訊息資訊也可作為備忘代辦和存檔記錄，時刻關注流程中的關鍵節點。
五、實踐過程
整體的實踐過程分為：
1.需求階段：制定工作流->需求建立->評審約束->關聯程式碼分支。
2.開發階段：vscode視覺化搭建（模板、除錯、提測、預上線）。
3.測試階段：程式碼比對->編譯打包->圖片壓縮->釋出測試->效能檢測->咚咚郵件通知。
4.上線階段：程式碼評審->程式碼合併->程式碼比對->編譯打包->走查檢測->圖片壓縮->JDOS部署->效能檢測->咚咚郵件通知->迴歸測試->釋出上線->行雲驗收。
1）需求階段
行雲團隊空間設定裡，我們將工作流設定為階段串聯且不可跳過階段和回撤，這樣的好處是便於我們約束研發流程的各個階段逐一流轉，並有效地計算各階段的投入成本。
為了防止員工私自承接確認需求，我們規範了評審流程，設定了評審約束。需求來源為業務和產品的需求必須經過專案管理者，在需求評審階段評審透過後才能進入到後續的開發階段，並可記錄詳細的評審資訊。
為了達到精細化的程式碼質量和風險管控，我們規定需求須和程式碼分支做關聯，因此在工作流的開發階段前置校驗中設定了“檢測關聯程式碼分支”的流程卡點。
工作流轉到開發階段，未關聯程式碼分支會進行彈窗提示去關聯程式碼分支，不關聯將無法進入開發階段。
關聯程式碼分支後，專案正式進入到開發階段。
2）開發階段
我們開發了一套VSCode程式碼編輯器的外掛，整合了模板，除錯，提測，預釋出等功能。讓前端開發者更關注程式碼實現而簡化專案初始化和專案程式流轉。
我們可以透過此外掛直接觸發提測流水線和預釋出流水線，也可以透過流水線的Coding程式碼約定式提交觸發相應的流程。如上圖所示，提交關鍵詞“釋出提測”觸發提測流水線，進入到測試階段。
3）測試階段
觸發提測流水線後，流水線中的功能（程式碼差異比對、編譯打包、圖片壓縮、上傳測試頁面、效能檢測等）會自動執行，執行成功後會給相關人員傳送咚咚提醒和郵件通知。
咚咚提醒：
郵件通知：
4）上線階段
當測試透過需要上線時，我們制定了一個預上線的流程，目的是作為上線前的最後一次迴歸測試和質量風險管控。
4.1 觸發預上線流水線
與提測流程一樣，我們可以在VSCode點選預釋出按鈕觸發預上線流水線，也可以透過Coding提交關鍵詞“釋出預上線”來觸發。
4.2 分支程式碼合併
觸發預上線流水線後，會自動執行分支程式碼合併主幹的操作。因為之後的上線是主幹上線，所以分支合併主幹的操作具有關鍵必要性。
注意：未經過評審透過，分支合併將會失敗，咚咚郵件會提示進行程式碼評審。
4.3 程式碼評審
為進一步提高程式碼質量，降低潛在風險，我們在Coding平臺制定了評審策略，只有程式碼評審透過才可以進行合併主幹的操作，如下圖所配置。
當分支程式碼沒有進行評審時，評審人員會收到程式碼評審的咚咚和郵件通知，以此提高程式碼質量的管控，進一步降低溝通成本。
評審人員收到的咚咚通知：
評審人員收到的郵件通知：
程式碼評審資訊：
4.4 評審透過自動合併主幹
採用Coding系統的自動合併主幹策略，規避人工合併帶來的不確定性風險錯誤，如下圖所示。
4.5 自動觸發預上線部署流水線
為避免評審過程中的等待時間浪費，當評審透過分支合併成功後，自動觸發預上線部署的流水線。此自動化觸發機制來源於流水線的觸發設定，如下圖所示。
4.6 自動執行預上線部署流程
預上線部署流程分為兩個階段串聯：
階段一：
階段二：
階段一進行編譯打包後，我們設定了一個程式碼自測（CheckList）的流程卡點，目的是提醒前端開發者最後檢查一些風險事項，並確認提交，如下圖所示。
全部勾選確認後，自動執行預上線部署流程的階段二，並推送咚咚通知。
4.7 JDOS部署和效能安全檢測
預上線部署流水線已經打通了JDOS的構建部署功能，並加入了Scan效能檢測和燭龍安全掃描，為預上線的頁面進行全方位的質量風險把控。
4.8 迴歸測試併發布上線
預上線部署流程完成後，專案相關人員會收到咚咚郵件通知。
現在，專案人員可以開啟預發機器提供的連結，進行全迴歸測試。測試無誤後，前往JDOS平臺點選“上線申請”即可釋出上線。
4.9 上線完成發起驗收
至此，整個專案研發流程結束併發起行雲卡片驗收。