我們如何實施 SonarQube 並實現其巨大潛力

我們如何實施 SonarQube 並實現其巨大潛力

我們希望分享我們在國家結算存管機構開發 DPO 系統(阿拉米達存託和清算會計系統的補充)的現有流程中實施持續分析和衡量 SonarQube 代碼質量的平台的經驗。

國家結算存管機構(莫斯科交易所集團公司)是主要的金融基礎設施公司之一,存儲和記錄俄羅斯和外國發行人價值超過 50 萬億盧布的證券。 系統執行的操作量不斷增長,功能不斷增加,需要保持系統源代碼的高質量。 實現這一目標的工具之一是 SonarQube 靜態分析器。 在本文中,我們描述了將SonarQube靜態分析器無縫實施到我們部門現有開發流程中的成功經驗。

簡單介紹一下部門

我們的能力包括以下模塊:向 NSD 客戶付款、電子文檔管理 (EDF)、交易存儲庫消息處理(場外交易註冊)、客戶與 NSD 之間的電子交互渠道等等。 一般來說,大部分工作都是在運營的技術方面。 我們以應用程序為基礎開展工作。 出納員的申請由分析師處理:他們收集客戶需求並向我們展示他們對如何融入該計劃的願景。 此外,標準方案是:代碼開發-測試-試運行-將代碼交付到生產電路給直接客戶。

為什麼選擇 SonarQube?

這是我們部門第一次實現代碼質量控制平台——之前我們都是手工做的,只是代碼審查。 但不斷增長的工作量需要該過程的自動化。 此外,團隊中還存在經驗不足的員工,對內部開發規定不完全熟悉,容易犯更多錯誤。 為了控制代碼的質量,決定實現靜態分析器。 由於SonarQube已經在一些NSD系統中使用,所以沒花太長時間就選擇了。 此前,其他部門的同事用它分析了Alameda系統(NSD自己的存管和清算會計系統)、CFT(會計、餘額、強制和內部報告準備的信息系統)、其他一些系統中的微服務代碼。系統。 為了進行實驗,我們決定從 SonarQube 的免費版本開始。 那麼讓我們繼續我們的案例。

實施過程

我們有:

  • TeamCity中系統的自動組裝;
  • 在GitLab中設置通過MergeRequest從feature分支上傳代碼到master分支的流程(根據GitHub Flow開發流程);
  • SonarQube 配置為按計劃分析 DPO 系統的代碼。

我們的目標:在AVE的CI/CD流程中實現自動代碼分析。

需要定制:通過靜態分析器自動檢查代碼的過程,每個 MergeRequest 都會發送到主分支。

那些。 目標圖片如下:開發人員將更改上傳到功能分支後,就會開始自動檢查代碼中的新錯誤。 如果沒有錯誤,則允許接受更改,否則必須更正錯誤。 在初始階段,我們就能夠識別代碼中一定數量的錯誤。 該系統具有非常靈活的設置:它可以配置為適合開發人員的特定任務、每種系統和編程風格。

在 SonarQube 中配置 QualityGate

QualityGate 分析是我們在互聯網內部閱讀的內容。 最初,我們使用了不同的方法,更複雜並且不太正確。 首先,我們通過 SonarQube 運行掃描兩次:掃描特徵分支和要合併特徵分支的分支,然後比較錯誤數量。 該方法不穩定並且並不總是給出正確的結果。 然後我們了解到,您可以設置錯誤數量限制 (QualityGate) 並僅分析您上傳和比較的分支,而不是運行 SonarQube 兩次。

我們如何實施 SonarQube 並實現其巨大潛力

目前,我們仍然使用相當原始的代碼檢查。 需要注意的是,SonarQube 與某些編程語言不兼容,包括 Delphi。 目前,對於我們的系統,我們僅分析 PLSql 代碼。

它的工作原理如下:

  • 我們僅分析項目的 PL/SQL 代碼。
  • 在 SonarQube 中配置 QualityGate,以便錯誤數量不會隨著提交而增加。
  • 第一次運行的錯誤數為229。如果提交期間有更多錯誤,則不允許合併。
  • 此外,在糾正錯誤的情況下,可以重新配置 QualityGate。
  • 您還可以添加新的分析項目,例如測試的代碼覆蓋率等。

工作計劃:

我們如何實施 SonarQube 並實現其巨大潛力

在腳本的註釋中,可以看到feature分支的錯誤數量並沒有增加。 所以一切都好。

我們如何實施 SonarQube 並實現其巨大潛力

合併按鈕變得可用。

我們如何實施 SonarQube 並實現其巨大潛力

在腳本的註釋中,您可以看到功能分支中的錯誤數量已超過允許的數量。 所以一切都很糟糕。

我們如何實施 SonarQube 並實現其巨大潛力

合併按鈕為紅色。 目前,不禁止上傳對錯誤代碼的更改,但這由負責的開發人員自行決定。 將來,您可以防止對主分支進行此類提交。

我們如何實施 SonarQube 並實現其巨大潛力

自我處理錯誤

接下來,您需要檢查系統檢測到的所有錯誤,因為 SonarQube 是根據其嚴格的標准進行分析的。 他認為的錯誤實際上可能並不存在於我們的代碼中。 因此,您需要檢查並記下這是否真的是一個錯誤,或者在我們的條件下是否不需要編輯。 因此,我們減少了錯誤的數量。 隨著時間的推移,系統將學會理解這些細微差別。

我們到了什麼地步

我們的目標是了解在我們的案例中將代碼驗證轉移到自動化是否有利。 而結果也達到了預期。 SonarQube 允許我們使用我們需要的語言,進行相當有效的分析,並且有可能從開發人員技巧中學習。 總的來說,我們對 SonarQube 的第一次體驗感到滿意,併計劃朝這個方向進一步發展。 我們期望未來我們能夠在代碼審查上節省更多的時間和精力,並通過消除人為因素來使其變得更好。 也許在這個過程中我們會發現這個平台的缺點,或者相反,我們會再次確信這是一個很酷、潛力巨大的東西。

在這篇概述文章中,我們討論了我們對 SonarQube 靜態分析器的認識。 如果您有疑問,請寫在評論中。 如果您對此主題感興趣,在新出版物中,我們將更詳細地描述如何正確設置所有內容並編寫代碼來執行此類檢查。

文字作者: 阿塔尼亞

來源: www.habr.com

添加評論