SonarQube是程式碼掃描的神兵利器，可針對每次PR的差異做掃描，讓大家只需對自己的程式碼負責，當每人都對自己負責時，團隊的程式品質就會呈現良好的向上循環。
前言
程式碼掃描工具種類繁多，但SonarQube有一個驚為天人的功能，就是能針對每次PR的差異來做掃描，現今大部分團隊，除了新創公司，大部分都有沉重的包袱，所以傳統專案隨便掃都成千上萬的待處理事項，讓開發人員還沒開始修改就先舉白旗投降了。但如果是針對每次PR的差異來做掃描，那狀況就完全不一樣了，自己的坑自己填，天公地道，當大家都對自己的程式碼負責時，整個團隊就會對壞味道的程式產生厭惡感，進而讓專案的品質呈現正向的向上循環，話不多說，就趕快試試SonarQube來幫助團隊解脫吧。
架設SonarQube Server
由於SonarQube需要Java的環境，因此，需要先安裝Java，Java下載的網址，Windows直接執行安裝檔即可，打開PowerShell，輸入Java出現下圖畫面代表安裝完成。
SonarQube還需要一個資料庫儲存分析結果，因此，需要建立一個SQL Database，當然它不僅只支援MSSQL，但本文範例用MSSQL來實作。新增一個資料庫，名稱輸入SonarQube。
接著調整定序，然後按下OK，資料庫建立完成。
Java環境安裝完成，並且建好資料庫之後，接下來去SonarQube官網下載專案。
下載來的檔案是一個zip檔，直接解壓縮，放到自己喜歡的路徑，我是直接放在C:\底下。接著在sonarQube資料夾下的conf資料夾會找到sonar.properties，點選開啟，按照下面步驟的格式填寫SQL的連線資訊。
接下來移動到sonarqube的bin資料夾，根據主機的windows版本，下圖範例是64位元版本，執行StartSonar.bat，最後如果出現Process is Up代表啟動成功。
在工作管理員的地方確認服務是否有正常跑起來。
都沒有問題的話，直接在瀏覽器上輸入localhost:9000，就會開啟下列畫面，代表服務架設完成。
整合SonarQube到VSTS的Build Step
總共有兩個步驟需要實作，首先，跟Jenkins一樣需要建立Servcie的End point，接下來將SonarQube的Plugin整合到Build Step內。
設定SonarQube的Service
SonarQube沒有專屬的Endpoint類型，所以，請選擇Generic類型。
Connection Name是自訂名稱，取一個喜歡的名字就可以，Server URL是剛剛安裝完SonarQube可開啟網頁的URL，帳密如果沒更改的話，預設是admin/admin，然後按下OK就建立完成。
整合SonarQube到Build Step
接下來的動作就是要將SonarQube整合到Build Step內，由於有plugin的協助，剩下的動作非常容易，打開Build Step新增兩個Step，如下圖所示。
接著移動位置，要像夾心餅乾一樣，把你Build的步驟包起來。
接下來設定Begin Analysis的步驟，如果上一個步驟SonarQube的Service Endpoint設定正確，在1號球處就可以直接選到，2號球處的Project Key和Project Name可以自訂，取一個喜歡的名字即可，最後按下Save存檔。
設定完成就直接來Run一個看看，一樣回到Build的頁面，按下Queue a new build，便會開始執行，由下圖可以看到執行成功，SonarQube已經整合到Build Step內了。
SonarQube展示報表
登入到SonarQube的頁面，可以看到剛剛掃描的結果已經出來了，在上個步驟有填入Project Name是DemoSonarQube，所以可以看到下面的掃描結果有一個叫做DemoSonarQube的專案。
直接點選連結可以看到專案的健康狀態報表，恩，看起來非常健康，迷之聲:因為根本是空專案吧。
讓SonarQube自動將建議填寫在PR的註解區
設定develop branch的Policy，並選擇我們剛剛建立好的Build定義，並且勾選Always require a new build。
設定好之後，只要PR要求合併到develop，便會自動觸發build，等SonarQube掃描完畢，Code Reviewer可以直接在PR的地方看到SonarQube的建議，如下圖所示，我們可以發現兩個變數的命名都有相同的問題，但SonarQube只要標註第二個變數AA002s有問題，卻未標註AA001s，是因為AA001s是原本的Code，而這次的變更只有AA002s，所以，別再找藉口怪前人挖坑，你有權利不填別人的坑，但請別跟著一起挖，自己對自己的程式碼負責，非常的公平!!!
總結
從首篇文章開始，我們走過了透過msbuild將專案封裝成package，並且再透過msdeploy將專案發佈到站點，然後進化成，透過Jenkins一鍵完成前面的動作，然後再進化為VSTS合併分支之後，觸發Jenkins完成前面的任務，接著建立了VSTS的Build Step當我們的守護神，每次PR後會自動編譯、跑測試，最後導入程式碼掃描，為程式品質做更進一步的把關。
整個DevOps的雛型已經完成，接下來就是要再針對團隊的需求再去做更細部的設定調整，但專案產品已經有最基本的保障，隨著測試覆蓋率的不斷增長，想改壞系統終於會變得愈來愈不可能了。呼~好累，最近感覺東西記不太住，走過的路，如果不趕快記錄下來會覺得很不踏實，寫到這裡，終於可以放鬆一下了....
