持續集成頻繁的代碼檢查怎麼辦,瞭解下自動化的靜態代碼檢查!

靜態代碼檢查分析是DevOps持續集成環節非常重要的組成部分,每個開發項目團隊都會制定相應的編碼規範,要求編碼實現中遵守相應的編寫規則。但僅依靠規則是不夠的,在實踐中還需依賴靜態代碼檢查工具的能力,以助於持續集成自動化程度。

 

 

持續集成的前提

 

中國信息通信研究院聯合開展了2019年中國DevOps發展現狀的調查,受訪企業包括科技、互聯網、金融、零售、電信、教育、政府、能源、諮詢等多個行業。目前DevOps已經在各行各業逐步落地實踐。

 

在調查報告中看到, 46.65%的企業在組織內較大範圍推廣DevOps實踐並且初見成效,28.07%的企業已經在組織內全面推行DevOps實踐,並將其貫穿於軟件開發的全生命週期中,整體交付效率得到顯著提升。而超半數企業使用敏捷工程實踐管理開發項目,近 6 成企業在敏捷工程實踐中選擇並應用編碼規範。既然這麼多企業都在探索DevOps,爲什麼只有部分的企業實現了效率的提升?

 

事實上,敏捷開發頻繁交付的模式對組織的效率也有很高的要求,如果開發流程內的各項工作本身就需要花費大量的時間,交付的越密集最後效率反而越低,所以實踐DevOps的前提之一是需要利用自動化爲各項工作提速。這裏我們針對代碼檢查的部分進行探討。

 

 

基於持續集成的代碼檢查思路

 

在傳統的開發模式下,開發人員編寫完代碼後即更新提交至公共代碼倉庫,待開發完成之後由專人對所有開發人員提交的代碼進行整合以便準備構建,如果構建失敗,則需要檢查或修改代碼。但開發人員對代碼及業務邏輯的熟悉程度可能會隨着時間推移而下降,修改的難度和工作量也大大增加。而修改完成後還需要重複進行合併、檢查工作,延長了集成環節時間。

 

如果將代碼檢查工作前置,開發工程師編碼完成後及時對代碼規範、語法等進行檢查分析,讓問題暴露在開發初期並及時得到解決,使得編碼階段就讓質量最大化接近可發佈標準,減少後續集成複雜度和返工修改率。

 

要求開發人員對每次增量更新的代碼進行人工檢查測試,不僅效率不高且耗時過長。嘉爲藍鯨DevOps提供的代碼檢查服務則爲靜態代碼分析提供自動化能力,實現持續集成。

 

 

嘉爲藍鯨DevOps代碼檢查

 

代碼檢查中心是藍鯨DevOps一個開放性代碼檢查平臺,集成基於C/C++、JAVA、C#、JS、Python、PHP、Golang語言的多款開源或自研的代碼檢查工具,包括Spotbugs、CppLint、CheckStyle、ESLint、StyleCop、Gometalinter、PHPCS、PYLint、圈複雜度、重複率、fireline等。通過內置或自定義配置的檢查規則可快速靜態檢查分析源代碼,找出質量問題和漏洞並提供修復建議。

 

創建代碼檢查任務,可根據編程語言設置啓用的檢查工具,可結合實際情況自定義代碼檢查任務是否需自動定時觸發,並支持自定義代碼檢查屏蔽路徑,被屏蔽路徑下代碼文件將不再進行檢查及不會產生告警。

 

已接入的代碼檢查工具除默認規則包外,系統還提供了多種風格規則及邏輯規格條目,用戶可根據實際情況爲代碼檢查工具配置啓用。

 

代碼檢查工具根據已啓用的規則對代碼文件進行靜態掃描,實時呈現檢查結果並提供告警定位及告警修復提示。

 

 

代碼檢查中心提供任務近期檢查結果趨勢的數據呈現,用戶可通過新告警遺留趨勢、歷史告警遺留趨勢、告警處理人分佈等數據瞭解項目團隊的編碼質量,以便持續改進。

 

代碼檢查任務不僅可單獨創建使用,更支持與嘉爲藍鯨DevOps的流水線服務、質量紅線服務結合,通過對靜態代碼檢查結果的准入、準出控制,提高代碼合規檢查和構建效率。

 

 

其他優質文章

 

【深度分析】關於SPN不正確導致SQL數據庫連接失敗

【知識科普】安全測試OWASP ZAP簡介

jmeter無法滿足敏捷理念怎麼辦,使用二次開發集中管理!

【知識科普】廣泛應用的敏捷開發方法論,極限編程與持續集成!

【Azure】混合環境下的身份驗證

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章