收錢吧研發效能實踐之工具篇

語言: CN / TW / HK

編輯 | 邵一帆,徐豪

前言

在降本增效火起來之前,每個研發團隊就已經對效能二字充滿了非比尋常的熱忱與執著。究其原因,就在於研發工作經常會給人帶來巨大的困擾。其一,每次程式碼提交後,研發人員都需要進行構建、測試、部署、合併等大量重複性的工作,當專案臨近釋出日期時,便倍感壓力;其二,依賴手工的配置管理難免會在這種重複性的工作中出現人為錯誤;其三,在產品交付過程中,由於必要又不太熟悉的工具、看不懂的各種報錯、搜不到的解決方法等技術上的壁壘存在,同樣耗費研發人員大量的時間精力。怎樣減少研發人員的時間不被無謂的浪費,如何將人的效率最大化激發利用,從而釋放研發人員的創造性和積極性,是每個研發團隊都會耗費心力去思考的事情。

關於研發效能的理論、體系、指標、框架方面的文章,近年來在網上層出不窮,其中也不乏有一些大牛的理論分析與實踐建議,如, InfoQ [1] 上有一整個專題討論研發效能。我們在此對理論和管理上的分析和設計不做贅述,僅簡單介紹收錢吧在工程和工具層面所做的實踐和改進。

CI/CD

研發效能工具鏈的提升,首當其衝離不開CI/CD。

CI全稱Continuous Integration,意思是持續整合,指在開發過程中,經常性地提交程式碼與之前的程式碼進行整合,每次整合都經過一些自動化過程進行驗證,如自動構建、自動測試、自動部署等,這樣就可以提高程式碼開發和整合的效率,並且可以儘可能早的發現整合過程中的問題。

CD通常指Continuous Delivery,意思是持續交付,它建立在持續整合的基礎上,對軟體產品進行釋出和部署。現在,CI/CD通常一起使用,來指代提交程式碼到上線釋出過程中的一系列自動化流程。

CI/CD的建設水平,直接關係研發團隊的生產效率和產品的交付週期。理想情況下,從提交程式碼到上線釋出都通過自動化流程實現,無需人工介入,而現實情況中上線釋出難免會受到一些人工的干預,有時候是因為技術的原因,有時候是因為業務的原因。在這樣的情況下,我們介紹下收錢吧在建設CI/CD流程中遇到的問題以及對應的解決方案。

CI/CD流程優化

2018年之前,收錢吧使用Jenkins作為CI/CD的解決方案。Jenkins是一款開源CI/CD軟體,用於監控持續重複的工作,每次整合都通過自動化的構建(包括編譯,釋出,自動化測試)來驗證,從而儘快地發現整合錯誤。Jenkins擴充套件性較好,外掛的拓展可以大大提升研發效率和規範產品開發流程。

使用Jenkins,可以很容易配置出CI/CD的流水線。但是隨著業務的發展,Jenkins的弊端也逐漸顯現出來。

  • 公司大多數專案是直接通過Jenkins介面配置專案的Pipeline Script,在釋出過程中,由於專案的CI流程如出一轍,造成了大量重複配置,加劇了系統開銷,也增加了維護難度

  • 由於在介面配置Pipeline,開發者無法對指令碼進行版本管理,便導致了同一專案程式碼的不同分支無法執行不同的CI流程

  • Jenkins本身需要一定的維護成本,管理金鑰、外掛,安裝agent,開發共享庫等

在2018年,公司將所有服務從Docker部署遷移到K8S叢集部署,原來Jenkins上的使用Docker部署的CI流程不再適用。由於逐個修改Pipeline指令碼工程浩大,再加上,公司程式碼原本就託管在的Gitlab上,所以考慮到將CI流程遷移到Gitlab內建的CI上。

相比於Jenkins,Gitlab CI具有很多先天的優勢:

  • Gitlab自身就是版本管理工具,CI配置檔案先天就具有版本控制

  • 本身作為程式碼倉庫,無需在拉取程式碼上做許可權控制,開發人員的Gitlab使用者許可權就是CI流程對程式碼倉庫擁有的許可權

  • CI的執行日誌就整合在Gitlab上,檢視日誌的方便度大大提高,並且,日誌可以清晰地顯示程式碼分支和提交時間

  • 可以方便地在不同專案之間觸發關聯的構建

除了這些先天優勢,Gitlab CI的配置檔案也非常簡單,幾乎沒有學習成本,而且模版檔案的建立和引用,相比於Jenkins來說也要簡單許多。Gitlab還支援多種執行器,適應不同的使用場景。我們目前使用K8S執行器。當任務規模達到一定量後,K8S幾乎是一個必然的選擇,相較於其他執行器,它有以下優勢:

  • 安裝簡單,使用Helm一鍵安裝,而且自動註冊

  • 通過提供統一的基礎映象,任務可以執行在我們提供的純淨環境中,避免環境汙染

  • 無需關注任務的資源排程問題,資源分配由K8S叢集處理,資源可以做到彈性伸縮,節省費用

收錢吧使用Gitlab CI的實施方案:

  • 元件化配置:建立了統一的CI配置倉庫,每種型別的任務可以定義成單獨的模版檔案

  • 自由組裝:業務專案引用倉庫配置,最終的執行流程,由多個模版檔案合併後的結果決定

  • 任務管理:CI/CD任務由Gitlab進行管理,包括任務生命週期管理、日誌收集

  • 資源管理:資源排程由K8S叢集管理

程式碼分支自動化

CI/CD進行的是程式碼提交到部署之間的自動化,而我們在不斷優化CI/CD流程的基礎上,又將自動化向前進行了延伸,在程式碼提交之前,也進行了自動化。

在大多數軟體公司中,需求管理和程式碼開發之間常常是斷開的,或者即使有關聯也是人工進行關聯,程式碼分支也由開發人員手動管理,這樣就會造成以下問題:

  • 程式碼分支管理混亂:分支名稱、tag標註如若沒有人為規範,服務擴充套件性便會下降,技術管理的複雜性也會提升

  • 程式碼和需求之間關聯困難:當需求增加、一人多需求並行開發、單需求多人協作,可能會造成程式碼提交錯分支、返工,降低開發效率

收錢吧目前使用Jira做專案管理,依託Jira的外掛和工作流能力,開發了分支程式碼自動化。

  • 一個Jira主任務下可以建立多個子任務,子任務建立時,可以選擇對應的Gitlab專案

  • 子任務進入開發流程時,系統自動會建立對應的release分支和feature分支,開發人員將對應分支pull到本地即可進行開發

  • 子任務提交審查後,會自動建立Merge Request,程式碼審查通過後合併入release分支

  • 測試人員使用release分支進行測試,測試通過後合入主分支,系統自動打上tag

這只是一個簡化的模型,實際應用過程中,可以根據Jira的不同的任務型別,決定程式碼分支的管理模型。統一的分支管理、任務和分支的雙向關聯,可以讓開發人員的認知保持一致,使個人的多工開發的分支管理不再混亂,使多人協同開發、跨團隊之間的合作,減少了很多不必要的溝通成本。

製品管理優化

說到CI/CD,就不能不說製品管理。製品是在CI/CD過程中產生的各種軟體產品,如jar包、npm包、Docker映象等等。這些製品會被其他的專案依賴或者被其他的CI流程使用,需要進行管理,能夠方便地儲存和查詢,同時要對不同的製品進行許可權管理。

在優化之前,製品關聯存在以下亂象:

  • 各種程式語言的製品分散在各個倉庫,沒有統一管理

  • 製品倉庫沒有許可權管理,開發本地、CI流程中都可以任意上傳,甚至覆蓋,造成依賴關係混亂

  • 開發、預釋出、生產等各個階段的製品混雜在一起,無法識別製品的有效性和穩定性

  • 製品的各種規範,如命名、版本管理,沒有強制的流程來保證

交付的軟體都是在這些製品上構建起來的,如果製品是一團混亂,那最終交付的軟體的可靠性也需要打一個問號。所以我們為了完成以下目標,重新設計了製品管理流程:

  • 統一的製品倉庫

  • 分倉庫儲存不同階段製品

  • 製品經過驗證後晉級

  • 區分各階段倉庫讀寫許可權

在製品管理改造的方案上,收錢吧選擇了JFrog,對所有制品進行統一管理。同時在JFrog的基礎上,結合自身的研發流程特性,設計了製品的上傳和晉級邏輯。

製品上傳邏輯:

  • 倉庫隔離:不穩定製品的dev倉庫和相對穩定的staging倉庫隔離,製品解析時互不干擾。

  • CI/CD Runner隔離:dev runner和staging runner的環境配置隔離,不同的runner擁有不同倉庫許可權

  • 上傳許可權:本地除錯和開發階段CI的製品,只能上傳dev倉庫;只有預釋出階段的runner可以上傳製品到staging倉庫;prod倉庫的製品無法上傳,只能從staging倉庫中晉級

製品晉級邏輯:

  • 映象交付:生產環境部署的映象,和預釋出過程中驗證的映象,只能是同一個映象。記錄映象中使用的製品以及製品的依賴。

  • 合規驗證:測試完成之後,在預釋出階段進行映象合規驗證,驗證通過之後,映象晉級,可以在生產部署

  • 製品晉級:映象上線驗證通過後,映象對應的製品及其依賴晉級到生產,供其他專案依賴使用

通過倉庫隔離和許可權控制,既保證開發測試環境的靈活方便,又保證預釋出和生產環境安全穩定。在CI流程中,還可以增加一些個性化的控制,如可以控制製品的覆蓋邏輯、上傳各個倉庫製品需要滿足的命名規範等。

SCA

在建立起規範的製品管理流程的基礎上,CI/CD流程中便可以加入軟體成分分析( SCA [2] )。SCA是分析軟體元件成分的一套方法論,它要求我們重視我們的應用程式程式碼中依賴的元件成分。

為什麼SCA如此重要?根據 Snyk Vulnerability DB [3] 披露的漏洞資料來看,開源軟體每年新增的漏洞數基本都在逐年增加。

如今,絕大多數應用程式的程式碼都會依賴大量的開源元件,只對自研部分程式碼進行靜態掃描、單元測試等動作是不夠的。這些開源元件中可能會包含嚴重的漏洞,包括近期著名的log4j漏洞。如何識別這種潛在的威脅,成了軟體開發中的挑戰。SCA主要具有以下挑戰:

  • 程式碼的低可見性:應用程式中依賴元件,元件中又依賴其他元件,層層的依賴,使得應用程式很難弄清楚到底使用了開源元件中的哪些程式碼

  • 依賴邏輯:層層的依賴過於複雜,我們需要工具來支援元件的邏輯依賴關係

  • 漏洞資料庫:關於元件漏洞的資料分佈在各種資料來源裡面,漏洞和被影響的元件匹配也比較困難,有些資料來源存在漏洞資料滯後的問題

比較成熟的SCA解決方案有:

  • 商業版解決方案:JFrog Xray、WhiteSource、Snyk等,商業版的最大缺點就是價格昂貴,每年至少需要多花費10多萬元

  • 開源解決方案:DependencyCheck,有Jenkins和SonarQube外掛,但是測試下來有比較多的漏報誤報,而且依賴的NVD資料更新不是特別及時

但是不管是開源的方案,還是商業版的方案,都只是用來分析軟體依賴中的存在高危漏洞的開源元件成分,對於公司內部自研的元件,如果存在業務需求需要強制將對應元件廢棄,那以上方案都無法滿足。基於上述原因,收錢吧自研了SCA分析,並將分析結果與釋出流程結合:

  • CI依賴解析:在CI構建過程中,將應用程式的依賴關係上傳Next平臺,Next平臺分析依賴樹,結合漏洞資料庫,生成高危元件報表,同時給黑白名單決策提供依據

  • 上線流程控制:命中黑白名單的元件,包括開源元件和公司自研元件,依賴這些元件的應用、docker映象,Next平臺都會攔截它們的上線釋出,SCA流程的完善,將對應用程式的安全性提供一定保障

系統上線之後,截至目前共分析出469個應用中共206個不同的高危元件,且提供完整的報告和修復建議。

同時,在應用部署過程中進行攔截。

Next平臺

CI/CD中提到的幾種優化方法,僅僅只是一些支離破碎的點和線,所有這些點和線,都由收錢吧內部系統Next平臺編織成面。在 《收錢吧多泳道環境的演進》 [4] 一文中簡單提到過Next平臺。Next平臺定位為一站式研發流程管理平臺,目前它的主要功能有:

  • 專案管理:跟蹤專案管理過程中的各個階段,記錄專案進度,管控上線釋出,管理專案成員,自動化專案過程中的文書工作

  • 應用管理和部署:管理收錢吧的應用程式,提供將它們部署到K8S叢集的能力,提供多泳道環境支援

  • 製品管理:檢視和搜尋製品,漏洞元件資料庫,應用漏洞元件資料統計

  • 團隊報表:各團隊專案用時統計資訊,各專案階段耗時甘特圖,專案bug統計資訊等

常見的軟體交付流程中,大致都會經歷開發、測試、預釋出、上線等階段,雖然每個階段內有CI的支援,但是階段之間的轉換常常需要人工進行確認,可能包含會議或者郵件等形式。在Next平臺上,專案流程管理是核心功能,其他功能都圍繞它進行展開。專案各個階段中產生的技術指標,可以成為進入下一階段的評估條件,在階段的轉換中,逐漸弱化人工確認,強化使用技術指標作為階段轉換的條件。這樣,可以使得CI中各項指標為研發流程所用,研發流程可以最大化地實現自動化、標準化,從而提升研發效率。

雖然Next平臺目前支援的功能還比較有限,但未來將有越來越多在研發流程中需要用到的功能通過外掛的形式整合進來,從而提供更多的技術指標,建立起越來越完善的研發交付流程。

總結

隨著收錢吧業務日益複雜,為了幫助研發團隊提高生產效率、縮短產品的交付週期,我們對CI/CD做了以上優化。在CI/CD流程的優化使得同樣多的硬體資源可以支援更多的任務,並且因為CI任務時間分佈明顯的峰谷特點,依託k8s叢集的資源排程加上節點彈性伸縮,並且硬體成本也進一步壓縮,節省開支。針對技術管理的痛點,程式碼分支自動化和製品管理的優化幫助研發人員更加高效地專注於業務需求,無需處理瑣碎的技術細節,提高生產效率。我們自研的SCA解決方案,在一個季度內也完成開發和推動落地工作,不但具有商業解決方案(至少10萬元/年)的功能,而且能夠融入原有的專案交付流程,降低交付專案中存在的安全隱患。未來,關於Next專案方面的工作,我們將持續擴充套件工具鏈,將工具外掛化,豐富Next平臺生態,同時充分利用工具輸出的結果,完善指標體系,讓專案交付規範化、標準化。

關於作者

劉寧,來自技術平臺部

參考資料

[1]

研發效能啟示錄: https://www.infoq.cn/theme/107

[2]

Guide to Software Composition Analysis (SCA): https://snyk.io/series/open-source-security/software-composition-analysis-sca/

[3]

Open Source Vulnerability Database: https://security.snyk.io/

[4]

《收錢吧多泳道環境的演進》: https://mp.weixin.qq.com/s/8DlQ4Q6lqACn4WUMjsPzgw