公司及個人簡介

我所在的 英捷創軟科技（北京）有限公司 (leansoftX.com)是一家專注於軟件工程，敏捷開發和DevOps領域產品開發和服務的解決方案提供商。公司由15年 軟件研發經驗,資深ALM/DevOps專家創建並任公司首席架構師，至今已經為超過100家不同類型和規模的客户提供過DevOps解決方案的諮詢和落地服務。公司在軟件研發效能領域具有多項獲得國家級計算機著作權的自主研發產品。公司及成員具有多項業界認證，包括：EXIN DevOps Master, 認證 ScrumMaster，華為雲最有價值專家，微軟最有價值專家，微軟金牌合作伙伴，GitHub在中國唯一的授權服務合作伙伴等。

薄 濤

英捷創軟 諮詢服務總監

本人從事為企業提供研發效能改進解決方案相關工作十幾年，為國內上百家企業提供過DevOps諮詢及解決方案落地解決方案，涉及行業包括：金融、通信、製造、互聯網、快銷等多種行業。通過對企業的研發現狀的深入瞭解，協助企業建設、優化DevOps平台，給出研發管理流程落地的最佳實踐方案，協助企業進行DevOps研發效能改進內部試點，總結試點經驗，最終逐步進行企業級推廣，同時也為企業提供DevOps平台工具優化解決方案，幫助其建立功能完善，並易於擴展及維護的端到端DevOps工具鏈。

自從2020年開始，我們公司開始承接了更多的DevOps工具鏈改進的項目，隨着工具市場的激烈競爭，更多企業希望從設計、功能、易用性等方面優化自己的產品，我或主導或參與了這些項目，因此在這想聊一聊我對DevOps工具鏈的理解，以及對國內DevOps工具的一些自身看法及建議。

介紹

DevOps的核心是研發效能改進，效能的提升離不開強大工具的支撐，因此在DevOps如火如荼的今天，承載研發效能改進的企業DevOps一體化平台工具建設也變得炙手可熱。在工具鏈建設過程中，很多人都會有這些疑問：當前DevOps工具發展情況如何？為什麼近期國內開始涌現大量的DevOps一體化工具平台，其中很多有實力的企業甚至自研DevOps一體化平台工具？自研DevOps一體化平台工具應該如何做？未來的DevOps發展方向會如何？希望能通過下面的內容使大家在DevOps工具建設過程中少走一些彎路。

當前DevOps工具發展情況

軟件研發管理從最早的粗獷的混亂管理模式，到現在通過完整工具支撐的精細化管理，這個過程漫長而艱辛，在這期間出現過很多很多的方法、框架、工具甚至是思想。有些隨着技術的發展在逐步進步，但也有些漸漸的淡出軟件研發這個圈子。

在2010年以前，我們使用的工具大部分都是由國外的軟件公司或者開源社區提供的，從2010~2015年國內已經逐步誕生了一些軟件研發管理相關工具，2015年以後隨着國內軟件研發管理的逐步完善，DevOps相關工具開始大量涌現。這些工具有些是專注於軟件研發的某個領域，有些則旨在打造一個完整的DevOps管理平台。

本人從2012年開始進入企業研發效能改進解決方案諮詢行業以來，即接觸過國際上主流的工具，也接觸過國內的一些新興工具。給我的·感受就是國際主流工具功能強大，可擴展能力強，但是確實在設計理念上與國人的軟件研發管理思維方式有差異，不能説無法使用，只是讓我們不習慣。國內的工具普遍的問題就是缺少時間的積累和打磨，某些產品在設計上有着強烈的自身企業研發管理基因，但是從設計角度來講，較為符合國人的使用習慣。

豐富的可用工具集

自從2010年DevOps這個專屬名詞推廣開來以後，所有和軟件研發過程管理相關的工具都可以劃入到DevOps工具集中，這些工具從功能範圍上可以分為兩大類：

All-In-One類（DevOps平台類）：即工具具備軟件研發主要過程的管理能力，例如上圖中微軟的Azure DevOps，Atlassian的全家桶（包括我們熟知的Confluence，Jira，Bitbucket，Bamboo等）。這些工具的特點就是基本可以通過一款工具幫助企業實現從需求跟蹤到環境發佈的所有管理要求，不需要企業為了不同管理目的採購不同軟件，極大的降低了管理、維護與學習成本。但這並不意味着企業只需要這一款工具就能解決所有軟件研發過程中的問題，例如：大部分All-In-One產品是沒有質量相關管理功能的，例如：靜態代碼掃描，接口測試工具，安全掃描工具，壓力/性能測試工具等。

領域專注類：這類工具大都只專注於一種或者多種能力，例如只專注於條目化跟蹤管理的Jira，禪道，Clickup等，這些工具大多核心能力是進行條目化跟蹤管理的，可以覆蓋需求、變更以及缺陷等多種企業常見軟件研發管理流程。條目化管理工具的特性就是以表單式條目化基礎結構，加上不同類型條目的流程設置使其具備不同軟件研發流程的跟蹤能力。這些工具的功能較為單一，無法通過一款工具覆蓋完整的軟件研發管理。但是好處就是使用者可以根據自身需要，選擇最優化的工具集來進行軟件研發管理，這樣可以最大限度的滿足不同研發過程對於某些特殊功能的要求，也能通過儘量使用開源工具降低成本，但由於工具多而雜也帶來了維護成本大，管理及使用複雜的問題。同時如果使用者希望能深度改進軟件研發管理時，如何獲取研發大數據也會由於工具集的複雜度帶來諸多問題。

領域專注類工具龐雜，專業性強我們不在這兒逐一討論了，後面我主要針對DevOps平台類產品進行分析。

井噴式出現的國產DevOps工具

國內的軟件行業經過多年發展，逐漸形成了一套適合自身需要的管理方法與工具，同時隨着開源社區的發展，也使得企業基於開源工具定製化更加適合自身要求的平台工具越發簡單。因此很多企業開始基於開源工具內建自己的企業級DevOps一體化平台工具，並通過多年內部使用，產品從功能到質量都在逐步完善，當企業認為工具已經成熟並可以商業化時，就將其推向了市場；也有些企業對標國際上成熟的DevOps平台工具，同時融入國內軟件研發管理習慣，開始研發商用DevOps一體化平台產品。

我所接觸的很多客户，都開始自建DevOps平台，大部分採用的也都是對開源產品的封裝，然後再融入自身的研發管理流程，使其更加符合企業內部的研發管理需要。

同時我們也接觸了很多還不錯的國內DevOps平台產品，例如：Gitee，博雲，阿里云云效，華為雲DevCloud等等。現在我接觸過的很多企業都開始自研DevOps平台工具，目的是國產替代，以及為了提供更加適配企業流程的管理要求。

國內DevOps工具建設問題

其實DevOps平台工具的開發需要很大的投入，以微軟的Azure DevOps舉例，從微軟2005年正式對外發布產品化Team Foundation Server（Azure DevOps前身）開始，經歷了17年的不斷開發與優化，才有了目前國際市場上被廣泛認可的Azure DevOps。在此期間Azure DevOps為了適應不斷變化的軟件研發管理實際要求，也經歷了數次大的技術調整與重構。由此可見想一蹴而就的研發一款優秀的DevOps產品基本是不可能的。

雖然目前市場上有很多國內的DevOps產品，但是或多或少會有一些開源工具的影子，有些乾脆就是基於開源工具套了一個殼子。這種方式可以讓產品快速投入使用，但是同時也會有很多的問題。

• 技術封裝不到位：這類產品的最大特點就是隻是對開源產品進行類簡單的封裝，但由於封裝的不到位，導致了在運行自開發產品的同時，需要維護底層的開源產品。我也見到過一些產品，在基於開源產品進行優化時反而降低了開源產品具備的優秀能力，提高了使用難度，這就有點兒得不償失了。
• 流程管理模式僵化：DevOps平台需要具備的研發流程管理，配置管理，自動化流水線，製品管理，環境管理等重要模塊功能中，除了研發流程管理，其他的主要功能每個產品的功能差異性不是很大。最能體現產品特色的就是研發流程管理。並且我在國內接觸到的所有客户幾乎都將流程管理視為DevOps平台工具的最重要功能，也是我們在提供解決方案時，需要幫助客户着重梳理的部分。但是很多產品在設計這部分時，都只支持敏捷、看板或者帶有自管理方式的流程。研發流程上每個企業都或多或少的存在差異，尤其是在一些中大型的軟件研發部門或企業中，固化的流程管理方式很難適配所有團隊。
• 擴展性差、定製化強烈：國內的很多產品是都支持企業級用户的，但往往在適配企業用户時需要對現有產品進行定製化才能將企業管理流程進行落地。定製化方式往往僅限於基於現有產品的定製化開發。其實基於產品的定製化開發應該是最後才考慮的，這樣做會導致後期維護成本高，同時會給版本升級，產品功能迭代帶來諸多質量問題。
• 管理維度能力較強，工程維度專業度不足：我接觸的DevOps平台產品可以覆蓋軟件研發的主要過程，但是很多產品在設計的時候並沒有考慮到從工程維度的版本交付維度進行管理，這導致了在當前軟件研發過程中很多DevOps平台產品都是以項目 / 系統 / 團隊範圍內的研發管理，但是由於很多企業的不同產品間是存在耦合的，很多時候需要不同系統協同開發與發佈，而很多DevOps平台產品對跨系統支持的並不好。正確的做法應該是從管理維度上平台工具應該覆蓋軟件研發的所有過程，從工程維度上來講，要具備軟件發佈版本上的協同研發管理。
• 可度量設計缺失、數據分散：有些DevOps平台的研發數據分別存儲在不同功能模塊中，各個模塊數據沒有聯繫，這種情況尤其體現在基於開源產品的封裝式產品上；有些則無法簡單的定製化度量報表。

英捷創軟的DevOps工具鏈優化案例

1.華為雲DevCloud -- HE2E框架

華為DevCloud軟開雲是華為雲系列產品中專門提供DevOps工具鏈的一體化解決方案，Leansoft專家團隊作為華為雲MVP與華為DevCloud團隊共同制定了一套HE2E DevOps實施推廣框架，並在過程中不斷的幫助DevCloud產品團隊打磨優化產品，提升平台自身的用户體驗以及產品質量。

我們通過設計一個實踐標準敏捷管理的鳳凰商城樣例項目，來驗證DevCloud產品各個領域模塊的能力，根據驗證情況提出相應的改進建議，再由DevCloud產品以及研發團隊改進產品。並通過將此樣例項目固化到DevCloud內置項目模版的方式，讓用户可以通過創建此樣例項目，配合對應的HE2E DevOps實踐指導手冊，讓用户可以結合場景、故事、事件完整一個端到端的DevOps旅程。這樣即幫助用户瞭解了DevOps相關的文化以及實踐，又讓用户對於如何使用DevCloud平台進行研發管理有了初步的瞭解。

2.某某雲

某某雲是國內知名大型企業旗下的雲服務品牌，是全球領先的雲計算服務商，為數百萬的企業和開發者提供安全可信、雲網一體、專屬定製、多雲協同的高質量雲服務。

XX作為某某雲自研的企業級DevOps一體化平台產品，具有強大的流程管理、源代碼管理、自動化流水線和測試管理功能。XX目前主要作為內部研發管理平台使用，在產品逐步完善後，會作為某某雲產品的一個重要部分推向市場。

協助改進某某雲的Devops平台產品，此產品目前還處於研發階段，主要是內部使用。由於內部自研產品特性導致各系統間耦合性較高，部門間的協同開發情況較多，因此迫切需要在平台產品中提供一種可以幫助研發團隊實現協同開發的功能。

項目為基於XX平台定製一整套從需求到交付生產製品的全研發流程落地管理規範，首先我們在不進行定製化開發的情況下，制定了一整套基於現有功能的版本管理方法，當然這裏需要進行較多的手動信息整理與維護，然後在試點團隊中驗證這種方法是否可以幫助團隊實時掌握自身版本以及協同開發系統的指定版本信息，然後再將此功能固化到XX平台產品中，在此過程中也發現了很多工具無法支撐整個過程的情況，這也是我們對於工具提出的改進建議依據。

最終形成了以版本為信息為核心的統一協同管理，通過版本可以查看和操作整個版本研發過程相關的需求，版本分支，流水線運行，環境部署結果，測試結果等信息。同時通過各系統間的版本關聯，可以查看其他相關係統的版本研發進度與相關詳細信息。

通過這種方式，即驗證了DevOps平台工具的版本管理可行性，也同時優化了產品的功能。

DevOps工具優化方案

經過多年的DevOps解決方案諮詢與實施工作，加上這些年逐步深入的DevOps工具鏈優化改進項目，如下列舉了我對DevOps工具設計的一些看法。

企業DevOps一體化平台能力

一款好的DevOps平台產品從研發流程跟蹤與管理，到端到端的自動化高質量製品生成及交付，應該具備強大的業務功能：

研發過程覆蓋

應該完整覆蓋軟件研發的主要過程：流程跟蹤（需求、變更、缺陷以及測試等），源代碼管理，自動化流水線，測試管理，製品管理等。

開箱即用

為最大限度的滿足主要客户需求，提供開箱即用的配置及工具，例如：提供敏捷、看板等管理工具，提供Java，Nodejs，C++，Android，ObjectC等主流技術棧的流水線開箱即用模板，並且提供調用主流自動化測試工具以及環境部署的流水線任務。

團隊協作

在工程管理維度上，應該具備跨系統，跨團隊的協同管理能力。每個研發團隊基本都需要經過需求、開發、測試、發佈等主要過程，這也是很多DevOps平台產品在設計時只考慮從管理維度出發覆蓋了這些主要的研發過程，但是並沒有從工程管理維度出發去考慮當一個系統存在與其他系統存在耦合，需要協同發佈時的場景，不要説這是產品設計的問題，為什麼不重構為微服務，當你接觸的客户多了你會發現，出現這種為題客户最希望的是通過工具來解決，而不是重構自己的產品。因此DevOps平台產品一定要考慮如何進行協同開發管理。這部分也是我在為客户做工具改進時的一個重點部分，這裏你應該先考慮清楚一個問題，到底從哪入手進行協同開發管理才是最佳的？是從流程上還是組織上？其實最好的協同方式是以工程維度的軟件版本管理上入手才是最佳方案。例如：一家大型金融企業（金融企業的系統耦合度普遍很高）當系統A進行新功能開發時，需要系統B、C和D等三個系統進行協同開發，這時我們可以分別在四個系統中定義自己的版本，並將四個版本關聯起來（也可以考慮定義一個版本），每個系統的版本中應該包含：版本實現的需求有哪些，修改了哪些倉庫的哪些代碼，當前版本的流水線運行情況（包括編譯、自動化測試以及部署等），各個環境的質量驗證情況，並且這些版本信息對於所有相關團隊都是開放的，那麼這樣所有此需求的相關人員都可以實時的瞭解當前系統以及依賴系統的研發集體信息，可以極大的減少由於信息不明導致的系統發佈失敗或延期的情況。

端到端的DevOps工具鏈

一定要具備協助企業搭建端到端的DevOps廣義流水線的能力。也就是説基於DevOps平台工具可以將涉及軟件研發的所有流程工具、研發工具、測試工具及運維工具等統一整合起來的能力。

DevOps度量體系

完善的度量體系：現在大多數客户對於產品的選擇主要是集中在功能性上，但是如果我們希望建立企業級的DevOps持續改進機制，希望企業能有一種持續可行的研發效能提升體制，那麼研發度量一定是必不可少的最重要依據，但是現在所有產品在這部分做的都不好，大家還是主要關注的產品功能，在當下工具功能已經足夠完善的情況下，產品的最大賣點應該是幫你發現問題，幫你分析問題，以及提供解決問題的數據依據，最後成為企業持續改進的內建度量標準。舉例來説：大家都知道DevOps的本質就是研發效能改進，那DevOps諮詢服務的起點應該就是企業研發效能的現狀評估，如果有一款工具能從管理維度上提供團隊的研發效率，交付效率，產品質量，效能瓶頸，以及團隊間的協同效率或者説組織效率相關數據，再結合工程維度的端到端的版本交付相關數據，那麼一個團隊或者一個組織的基礎能力就能很容易評估，同時也更佳方便企業分析自身問題，為解決問題提供最優改進方案數據依據。

一切皆代碼

基礎架構即代碼是一個重要的DevOps最佳實踐。但是最為一款好的DevOps平台工具，自身應該具備功能強大，使用靈活簡單的基本特性。如何實現此特性？首先應該清楚，作為一個軟件系統的研發管理過程主要包含哪些內容：需求，應用源代碼、數據庫、測試、製品生成、運行環境及其他依賴。除了需求以外，其他應該都可以用腳本來編排，例如：通過腳本實現數據庫持續交付，通過腳本實現自動化測試，通過腳本實現流水線編排和環境編排。因此DevOps一體化平台工具除需求管理外，其他主要功能模塊應該都可以通過腳本進行編排，即Everything As Code（一切皆代碼）：開發人員在自己的IDE中就可以掌控軟件工程維度管理內容，自動化測試腳本幫助開發團隊內建質量在代碼中，數據庫腳本幫助研發團隊實現軟件的完整交付，流水線腳本幫助開發人員簡單快速的配置及維護流水線，環境編排腳本用來定義軟件運行環境及所有運行依賴，目前基礎架構即代碼實踐的最優方案是將容器化應用部署到基於容器化的微服務編排平台來實現，其次可以考慮使用雲產品來支持，私有云可以通過CHEF,Puppet,Ansible這種環境編排工具來實現，但是這種方案的複雜度高，維護成本大，並不推薦。如果想軟管團隊的DevOps工程管理能力變得優秀，那麼實現一切皆代碼是最終的歸宿。

DevOps一體化平台結構

如果DevOps平台工具光具備好的業務能力是不足夠的，還應該具有優秀的產品結構。如何讓產品易於部署與維護，如何適配不同企業、不同團隊及不同流程，這些問題都需要通過產品設計來解決，如上圖的產品結構就是一款優秀DevOps平台工具需要具備的：

具有普適性的基礎管理能力

核心功能具備軟件研發管理的基礎能力，也就是説應該面向最廣泛的用户，提供最通用化的研發管理基礎能力。比如説Gitlab內置的Issue管理功能，可能對於大型研發組織來講Issue無法落地所有研發流程，但是如果只將範圍限定在只負責一個微服務或模塊研發的研發團隊，Issue功能足以支撐其研發管理需要的，並且其對於不同流程的適配能力其實也很強，無論是敏捷/瀑布還是其他流程都可以匹配。同時產品的各個功能模塊應該具備良好的銜接能力，例如：從需求到任務，從任務到代碼，從代碼到製品，從製品到環境，從製品到缺陷，這個軟件研發的端到端的環節應該被完整的串聯起來，具備可以通過過程中的任意一點追溯整個過程的能力。

具有靈活的流程管理配置能力

為了適配不同行業，不同企業，可以通過產品的配置化功能進行研發管理流程落地。之前也提到過，不管是配置管理還是自動化流水線，這些功能在各個工具上的差異並不是很大。配置管理上現在都是採用的主流工具Git，再結合拉取請求（合併請求）進行代碼集成管理。流水線的基礎功能大同小異，核心功能都是製品生成、發佈以及自動化質量控制。因此最能體現產品特色的就是流程管理，能否更好的落地不同企業的研發管理過程，主要取決於工具的流程管理可配置性。還是拿微軟的Azure DevOps來舉例，如果是一個小型企業使用，不需要配置，原生使用就足夠了。對於一箇中型的軟件研發企業，他們有着自己的流程，自己內部已經形成了通用的業務術語，那就需要進行簡單的過程管理配置了。但是對於一個大型的金融企業來講，原生功能外加原生配置也無法滿足要求的，那就不得不進行一些定製化開發了。特別是對於傳統制造業企業（比如汽車製造）來講，如果想使用Azure DevOps進行工業產品研發過程的完整覆蓋，不管如何配置及定製化開發都會覺得很彆扭，這就是由於傳統制造行業中的軟件研發管理是有別於互聯網式的軟件研發管理的。

具有完善的產品擴展能力

優秀的產品化DevOps平台工具必須具備完善的擴展能力，這可以使產品獲得更大的用户羣體，降低產品售後的實施難度，可以將產品的研發團隊以及支持企業客户的技術支持團隊解耦，降低管理成本。同時用户在使用上也具備更大的自由度，可以在框架之下靈活擴展，使原本無法滿足需求的DevOps平台工具實現研發流程的完整支撐。打造完整企業級DevOps工具鏈也要求核心的DevOps平台工具具備良好的擴展能力。

對外提供標準Web API

從後台管理相關的系統用户、安全設置、系統設置等，到流程、源代碼、流水線、測試以及製品等前台管理的所有功能都應該有相關接口提供，也就是用户能在產品上使用的大部分功能都應該提供相關的接口，並且這些接口能做到產品升級後對於舊接口版本的向下兼容。

通過Web API調用，用户可以自行進行需要的擴展功能開發，例如：如果需要在項目管理工具中將通過審批的項目、工單或需求同步到DevOps平台工具中，則可以在項目管理系統中通過調用接口實現信息推送。

基於DevOps一體化平台產品的擴展框架

DevOps一體化平台工具需要具備定製化擴展框架，基於框架可以對產品功能界面、菜單和某些功能進行調整，這樣就能滿足絕大多數對於產品定製化的要求。

例如下圖就是Azure DevOps的擴展定製化開發框架，通過擴展定義的JSON文件來定義此擴展的名稱、作者、類型等配置信息，通過靜態文件實現功能定製。

完善的消息推送機制

通過消息推送（也就是Hook）可以將系統事件延展到其他集成系統中，以此完善工具功能，提高平台工具流程的完整度，並且可以簡單實現與其他系統的實時信息同步。

通過這三種對於擴展的技術支持即可滿足絕大部分對於產品的定製化需求。好處就是DevOps平台工具不需要為不同客户定製化開發不同版本，對於產品的開發企業可以極大的降低產品本身的維護複雜度，可以將產品的研發團隊以及支持企業客户的技術支持團隊解耦，降低管理成本

不可或缺的產品定製化能力

當然如果有一些特定用户無法通過之前的三種手段實現研發流程的全覆蓋，那麼就需要終極手段-定製化開發了。其實這種情況也不少，例如：一個大型企業中有幾千軟件研發人員，那麼他對於DevOps平台的要求可能會更多，他們會希望能落地所有流程，能和公司其他管理工具做深度集成，希望平台套用企業統一樣式等等。

如果產品設計上能做到以上四點，那麼可以説這款DevOps平台產品具備了一個比較優秀的維護與擴展能力。

DevOps工具鏈的終極形態構想

未來的編碼趨勢一定是IDE輕量化，這點大家可以查一查現在Web IDE的熱度，VS Code在短時間內收穫大量用户就是一個最好的證明。那麼基於IDE的網頁化，DevOps一定將走向輕量化，不應該再像現在一樣，需要維護一個功能複雜的工具界面，這些功能應該被直接集成在IDE中。DevOps平台工具在功能設計上應該只有3個核心模塊：流程管理，後台服務，度量。

• 流程管理：主要提供給利益干係人、管理者進行信息查看和流程操作使用，此功能需要有對外展示頁面。但是開發團隊只需要使用輕量化的IDE完成所有操作即可，所有信息與操作均可以在IDE上直接、精確的顯示與操作。
• 後台服務：提供包括代碼管理、流水線管理等其他核心服務
• 度量：可以根據任意維度顯示所有與開發活動相關的數據，包括流程管理數據、工程管理數據、行為數據（例如開發人員的代碼開發習慣，開發時長，代碼質量分析等等）。並且可以快速的形成報表進行展示。

從技術上，整個環境應該都運行在基於容器化編排平台運行的容器中，並且相較於傳統DevOps平台工具上的差異：

1. 環境：

1. DevOps平台工具：簡易部署，便於維護
2. 開發IDE：解決所有IDE環境依賴配置複雜困擾，提供協同開發優秀解決方案，強大而不復雜的DevOps平台工具深度綁定
3. DevOps自動化流水線運行環境：自助式的容器化流水線運行環境
4. 應用運行環境

2. DevOps組件：

1. 豐富的DevOps功能接口
2. 通用化JS集成框架：方便開發者定製化DevOps集成功能
3. 實時的研發數據動態收集功能

3. DIS（DevOps Integration Service)

1. 易於配置的集成服務
2. 兼容主流DevOps工具集
3. 開源化運營，便於使用者的二次定製化