開發十年，就只剩下這套架構體系了！ >>>   

關注嘉為科技，獲取運維新知

 

前面一篇文章《藍鯨DevOps深度解析系列（1）：藍盾平臺總覽》，我們總覽了藍鯨DevOps平臺的背景、應用場景、特點和能力；

​

 

接下來我們繼續解析藍盾平臺的核心元件——流水線引擎。本文介紹的是藍盾流水線的使用者體驗，為了讓大家有更直觀的感受，所以圖片較多，請諒解。

 

傳統的瀑布式軟體開發模型在需求明確、業務穩定的專案中，有著明顯的優勢；而面對需求頻繁變化的專案、持續迭代的網際網路產品，敏捷開發方法正好適合。

 

DevOps則幫助開發、測試和運維團隊共同建立了一個強大的、可預測的軟體交付方式。

 

DevOps強調“將軟體建設的所有環節進行自動化&全面監控”，也就是使用正確的持續整合（CI）和持續交付（CD）工具集，把持續交付的過程變得自動化，更快速、可靠；並且將過程資料進行儘可能完整的資料採集和分析，用於持續的精益改進。

 

實現這一切的核心是實現高效交付的自動化流水線。根據《2018全球DevOps現狀調查報告》，基於 DevOps 改進了軟體交付效能的精英組織相比低效組織來說，吞吐量和可靠性的提升，流水線居功至偉。

 

 

 

藍盾流水線的背景

在騰訊互動娛樂事業部（IEG），龐大的持續部署和持續整合、持續運營的需求，驅動著流水線也經歷了兩條不同主線的發展：

 

1） CD/CO流：從自動化應用部署和釋出工具，到通用的運維平臺支撐部署和運營作業流水線

 

時至今日，騰訊IEG運營的六百多款產品使用的語言、技術架構、資料庫、執行環境差異化仍然非常大。面對每個產品的部署釋出、運營作業的編排和執行需要，擺在面前有兩條路可以選擇：

 

●  為每個產品的部署釋出、運營場景定製開發特定的工具，一個個工具變成一個個煙囪，開發團隊需要面對不同的需求疲於奔命；

 

●  建立技術運營的體系，將平臺的建設和運營場景的建設分開，平臺建設團隊不斷的豐富平臺能力，產品運營團隊基於平臺以組裝的方式來實現部署釋出和運營場景。

 

如果我們為數百款產品開發數百個部署、運營工具平臺，那麼數百款產品的運維、運營工具的開發，會導致巨大的成本、穩定性問題。

 

顯然，建立技術運營體系這條路是不得不走的路，這個平臺也就是誕生於IEG的藍鯨平臺。藍鯨平臺的介紹文章頗多，在此不做詳細的介紹。

 

2） DevOps流：從基於Jenkins的持續整合流水線，到自研的強大流水線引擎

 

無論是在初創公司還是大型企業，在需要持續交付的專案/產品研發中引入DevOps都可以減少人為錯誤的發生。

 

該模型允許研發維持質量，同時加快端到端快速交付流程。在DevOps體系中，流水線結合研發效能工具可以幫助企業建立自己的快速交付管道。

 

DevOps落地過程中，最關鍵的、同時挑戰最大的是構建自動化持續交付流水線。

 

自動化持續交付流水線涉及到程式碼拉取、程式碼靜態分析、編譯構建、單元測試、製品歸檔、自動化測試、安全掃描、壓力測試、部署測試環境、部署預釋出環境、釋出等等環節的串聯和自動化執行。

 

建設企業級的統一DevOps平臺，開源的Jenkins 流水線在效能、可擴充套件性、穩定性、安全性、使用者體驗方面都存在明顯的不足，踩過了若干坑之後騰訊IEG不得不重新設計了流水線引擎，而且它必須要比Jenkins更為強大，才能有存在的價值。

 

 

藍盾流水線的使用者體驗

如果流水線引擎不能帶來良好的使用者體驗，不能適應各種場景下的流水線靈活編排，那麼它和執行指令碼有什麼區別？

 

在使用者體驗方面，藍盾的流水線可以說做到了極致，本文就從使用者體驗著手，來初步解析藍盾流水線：

 

1)   輕鬆簡單的流水線編排

藍盾流水線讓使用者不需要學習Jenkins的Pipeline語法，也不需要過於關注和工具平臺如何對接。

 

圖形介面的視覺化的流水線設計，靈活組裝各種原子，配置化原子設定，降低了使用難度，也減少了指令碼難以除錯、容易出錯的問題。更不會出現人員更迭導致無法維護的問題。

 

下面的流水線示例，各一個縱列是一個階（Stage），每個塊是一個任務原子（Task），近百種原子模板可以根據業務的需求，靈活組裝出各種流水線，對接各種工具實現CI/CD環節的各種功能和流程。

 

 

我們可以從空白模板開始建立流水線，也可以從流水線模板庫中的模板來建立流水線。模板可以預先設定好流水線的階段、構建環境、原子型別等，降低流水線編排的難度。模板可以由使用者自己來建立。

 

 

流水線可以把任務分為多個階段（Stage），每個階段（Stage）下面，還可以有多個並行的作業（Job），每個作業都可以指定不同的構建環境，我們可以在構建階段並行進行不同的構建環境下的程式的構建，例如：後臺服務、Web端、移動端。每個作業下面，還可以有多個序列執行的任務原子（Task）。

 

 

每個任務原子都是可以配置的，每個原子模板都有特定的功能，我們可以選擇任何一種原子型別下面的原子模板。藍盾內建了近百種原子模板供我們選擇和組裝，如果沒有滿足的原子，也允許使用者自己擴充套件開發。

 

 

例如，我們選擇了拉取GitLab倉庫程式碼原子模板，我們就可以直接在圖形介面進行原子的引數化配置GitLab程式碼倉庫的資訊，流水線執行到該原子時，就會根據配置自動的從指定程式碼倉庫拉取指定版本的程式碼。

 

 

如果我們選擇了程式碼檢查任務模板，我們就可以配置程式碼檢查執行任務中的語言和程式碼檢查工具；流水線執行到該原子時，就會啟動程式碼檢查平臺按照指定的設定開展程式碼掃描了。

 

 

2)      直觀清晰的流水線跟蹤

流水線被執行之後，我們需要了解流水線的執行情況，例如：成功與否、耗時、日誌；我們還需要拿到流水線執行的產出物（即製品包）、報告（程式碼檢查報告、單元測試報告）。過往這些資訊往往是散落在不同的工具平臺中的，給我們的實際工作帶來很多不必要的困擾。

 

 

上圖中，流水線的每次執行的結果，都可以在執行歷史中被展示出來。包括：啟動時間、構建序號、耗時、版本號、觸發方式和執行人等。如果需要看更加詳細的資訊，我們可以點選其中一次記錄，就可以看到該次執行的具體資訊。

 

 

如果有異常，流水線會自動停止和傳送通知，在執行結果介面清晰的標識出哪個原子出現了異常。

 

 

如果需要進行更進一步的瞭解原子的執行情況，在執行結果中點選任何一個原子，我們可以深入檢視和分析該原子更細節的日誌，例如：

 

 

在“檢視構件”標籤頁，我們可以直觀看到本次流水線執行生成的製品包，如果有需要可以直接下載到本地或者檢視元資料，而不是需要到切換到製品倉庫軟體中去查詢。

 

 

在“程式碼變更記錄”頁，我們直接可以檢視到本次流水線的執行涉及的程式碼變更版本號範圍以及具體的Commit資訊，可以用於追蹤產出的新的版本，涉及了哪些需求或變更、缺陷的修復。

 

 

在“產出物報告”標籤頁中，集中展示流水線中各個環節產生的報告，例如下面的程式碼檢查原子產生的程式碼檢查報告。

 

 

 以及在單元測試環境產出的單元測試報告。

 

 

3)   流水線的設定

在流水線的設定中，我們可以配置流水線的執行鎖定、通知設定、許可權設定等。例如：可以設定流水線在同一時間可以執行一個或多個例項。

 

 

流水線在構建成功或失敗時，對哪些人進行某種方式的通知。

 

 

總結

從上述資訊可以看到，藍盾流水線的使用者體驗可以說超越了所有的其他流水線工具，這種使用者體驗帶來的不只是介面好看本身，而是藍盾產品團隊對DevOps的更多考慮：

 

●  藍盾作為企業級的DevOps平臺，我們希望的是靠平臺的強大、極致的使用者體驗吸引各個研發團隊將研發流程遷移到平臺上，而不是通過行政命令要求各個團隊必須使用藍盾DevOps平臺；行政命令則可能會帶來使用者反彈和博弈，而藍盾是一個能“潤物細無聲”的幫助企業把DevOps研發標準、規範體系推廣到全企業的研發效能平臺；

 

●  使用者體驗絕不只是“介面好看”四個字所能概括的，極致的使用者體驗是建立在對市場競品的調研和分析，對龐大的DevOps團隊使用者進行調研和分析，對平臺的不斷優化和打磨，對藍盾工具鏈的各個工具進行深度打通等等的基礎之上；平臺的功能、穩定性、擴充套件性等必須做到極致，才是使用者體驗能達到極致的前提；

 

●  使用者體驗不應只是帶來使用者的方便，直接或者間接帶來的更多是：學習成本的降低、研發效能的提升、交付頻率更高、交付時間更短，由於流水線編排出錯導致的部署失敗、執行事故降低到極低，由於人員變動帶來的影響更小；IT團隊在DevOps專案中的參與度更高、團隊更加穩定，可以有更多的精力放在業務層面的運營和優化中。

 

未完待續，敬請期待……