作者：胡駿

一、背景現狀

軟體開發從傳統的瀑布流方式到敏捷開發，將軟體交付程序中開發和測驗形成快速的迭代交付，但在軟體交付客戶之前或者使用程序中，還包括集成、部署、運維等環節需要進一步優化交付效率，因此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 上線完成發起驗收

至此，整個專案研發流程結束并發起行云卡片驗收，

標籤：其他

上一篇：幫你短時間拿下Git，Git詳細教程（濃縮的都是精華）

下一篇：軟體工程 專案管理 實驗 圖書館座位管理系統