史丹利好熱

把CI/CD 訊息通知也丟到指定的Teams頻道上。

最近在新的專案CI流程內開始加入聲納(SonarQube)來進行程式碼分析，希望能獲得海面下更多有關程式碼品質度量的指標。從Jenkins以Command Line執行大型程式庫掃描時，卻出現了記憶體不足的異常，不過小型程式庫則可以正常完成掃描。

進入疑難排解階段，我們先確認伺服器記憶體是充足無虞的，不過觀察掃描程式在大型程式庫執行時，只吃到1G多一點就出現記憶體不足的異常。筆記解題方法。

.NET專案完成建置、掃描及測試等等等的持續整合程序後，下一步就到了過版到QA環境的佈署階段了，要佈署到IIS的Web專案可以靠Web Deploy單鍵佈署建立的發行組態與Jenkins直接整合，透過web deploy(8172)直接佈署到WEB Server的IIS。但遇到Windows Service或是其他執行檔專案時，就稍微麻煩一點。這次我們在Jenkins Master作建置並且產生發行成品，但佈署時，直接從測試機連回Jenkins Master取得封裝成品來作版本更新。

由於工作的關係，時常需要和源碼檢測工具神鬼交鋒一下，持續整合之路上也有源碼檢測的探險，累積幾家客戶的要求，半數是以Fortify SCA(Source Code Analyzer)作為檢測工具，也寫筆記留給同事及以後的自己參考。

上一篇，我們用cloc.exe 自動計算程式碼行數作為程式碼開發進度的概觀，但如果想調查專案中的程式有沒有波動拳的情形(很深的巢狀邏輯)，觀察程式碼複雜度、可維護性指數都是找出快打旋風Ryu與Ken的方法。

在時間還是充裕的時候，也許我們人工Review時可以用上Visual Studio擴充套件的CodeMaid或是Visual Studio 內建的程式碼度量(Code Metrics)功能來識別出潛在的技術債，不過，在自動化持續整合階段，如果沒用SonarQube，要找一個設定方便，資訊又完整的就令人傷腦筋。

繼續往持續整合之路前進，有時老闆會想知道最基本的程式碼度量，究竟專案中使用了幾種程式語言，多少支程式碼，多少行程式碼(LOC:Line Of Code)?如果專案程式碼沒送SonarQube掃，還有哪些方式能持續自動的紀錄?

走過前幾天持續整合之路，每天我們可以確保專案擁有能編譯正確的程式版本，完成了最基本的版控和Daily Build要求。不過，我們開發的log程式沒經過測試，執行整合後，如果直接佈署上SIT/QA測試機，一定有被開單和罰站的風險，雖然面對可怕的使用者，我們心無雜念，更練就老僧入定的技巧，但還是要讓自己能免於老闆的關心，來補簡單的單元測試，讓CI Server幫我們持續整合，未來收到千變萬化的使用者需求，我們也能既快速又自動的執行基本測試。

前幾篇(二~四)依序完成了準備可編譯.NET的環境、TFS、MSBuild、NuGet到Slack的組態，為了接下來更多的持續整合(CI)工作，我們這篇前半部先開一個乾淨的.NET類別庫專案，並且完成最基本的版控、Daily Build及通知組態工作，讓新的Jenkins Server 開始整合我們的專案。

除了用風靡全世界的專案管理工具Outlook透過Email來收CI訊息，也能把Jenkins CI訊息也像Log或是TFS  CI、Jira訊息丟到Slack或Teams頻道上，今天先記錄Slack。

Jenkins預設安裝的原始碼管理只有Git和Subversion，由於公司政策的因素，一直以來專案都是使用TFS(TFVC)作為版本控管及Daily Build，好，來增加TFS plugin，順便到TFS設定TFS Check-in時觸發Jenkins工作。

支援的專案都是以.NET(C#)開發為主，走進CI持續整合之前，得先幫Jenkins Server準備好可以編譯.NET程式的環境並且完成Jenkins的MSBuild組態工作。在建置過程中，專案也可能需要還原NuGet 上的套件，同時library專案建置完成後，也希望將編譯並且測試好的套件發佈到公司內的Private NuGet Server，好，來完成準備工作。

軟體專案的開發過程中，如果建置、測試及佈署可以更自動的執行，專案團隊就可以更快收到回饋，更即時改善及修正。為了讓新參與的專案走向持續整合及佈署(CI/CD)之路，來筆記Jenkins工具的使用及組態，下次同事就可以按圖施工，加快設定的速度。

最近修改了Jenkins Email Notification的帳號來避免每月換密碼，變更改為密碼永久有效帳號後，一寄信卻出現Client does not have permissions to send as this sender訊息。