iT邦幫忙

2021 iThome 鐵人賽

DAY 16
1
DevOps

DevOps 萌新的 TeamCity 極速上手寶典系列 第 16

第十六天:在 TeamCity 上執行靜態分析

昨天我們在專案裡導入了 detekt 靜態分析套件,只要執行 $ gradle detekt 就可以掃描整個程式碼庫,及早找出淺在問題。我們也介紹了如何在 IntelliJ IDEA 安裝 detekt Plugin,讓我們在寫程式碼的過程中就可以即時的看到掃描結果。而同樣的技巧我們也可以用在 TeamCity 上,只要新增一個 Build Step 即可。

新增靜態分析的 Build Step

先請登入 TeamCity Server,選擇 Shopping Cart 專案頁面,點選左上角 Edit project 進入專案設定。

選擇畫面中間 Build Configurations 表格裡 Build 最右邊的 Edit 進入編輯功能。

選擇左邊側邊欄的 Build Step,準備新增一個建置步驟。

在 Build Step 設定頁,點選 Add build step 新增一個建置步驟。

用我們已經學會 Gradle Runner,Step name 就命名為「Static Analysis」,Gradle task 就是 detekt,其他功能留空按 Save 儲存即可。

調整 Build Step 的執行順序

目前我們總共有 3 個 Build Step,第一個 Build Step 執行了 cleanbuild、第二個 Step 是 lintKotlin、第三個則是 detekt。但假如希望在 Build 之前先做 Linter 及 Static Analysis 的檢查呢?這時我們可以調整 Build Step 的執行順序來達成這個需求。

首先我想把第一個 Build Step 的動作拆開,先修改第一個 Build Step,裡面的 Gradle 指令只留下 build,接著再新增一個 Build Step,Step name 就命名為「Clean」,Gradle task 就是 clean,其他功能留空按 Save 儲存即可。

回到 Build Steps 設定頁,點擊 Reorder build steps 按鈕,這時會彈出一個調整視窗,拖曳每一個項目左邊三條線的圖示就可以調整 Step 的順序,完成後按 Apply 就套用完成了。

用 TeamCity 執行靜態分析

回到 Shopping Cart 專案的 Build 頁面,按下右上角的 Run 按鈕,測試一下調整完的 Build 流程。

因為昨天我們故意留下 Wildcard Import 的問題,所以上面的 Build 會失敗,我們點開 Build 的詳細資訊,點到 Build Log 頁可以看到這次 Build 失敗的原因就是卡在 Static Analysis 這一個 Step。

回到 IntelliJ IDEA,依照昨天學會的作法,用 Option+Enter 來匯入完整的 Package 名稱後,重新 Commit & Push,觸發 TeamCity 再跑一次 Build。

這次就成功通過靜態分析了!以後每當程式碼庫有變更時,TeamCity 就會自動觸發排版風格檢查靜態分析測試,有這三大利器的保護,我們的程式碼品質就受到堅實的保障。

小結

今天將 detekt 與前面學過的 Build Step 結合,也再介紹了調整 Build Step 順序的方式,相信大家對建置設定會更熟悉。不過,每次我們把程式碼變更推送到 GitHub 後,都要自己跑去 TeamCity 看結果還蠻花時間的。對開發者來說,其實只有 Build 失敗時才需要知道結果,不然跑去 Web UI 看通過的 Log 其實沒有意義,是不是有什麼方式可以在 Build 失敗時主動通知我們呢?

沒錯!我們明天就來介紹 TeamCity 的通知功能,敬請期待!


上一篇
第十五天:用 detekt 做靜態分析
下一篇
第十七天:TeamCity 通知機制
系列文
DevOps 萌新的 TeamCity 極速上手寶典31

尚未有邦友留言

立即登入留言