在第四個關卡中(Test and Scan)，除了自動測試，另一個需要持續整合的就是程式碼檢查了。除了常用的程式碼風格(StypeCop)、收集程式碼警告(Warnings) 到程式碼度量(SourceMonitor)、程式碼行數(SLOCCount)及未完成工作的plugin(Task Scanner)外，通常可能會加上源碼檢測工具(Fortify SCA、Checkmarx)，不過最近被老闆交代看好進行中專案的技術債(Technical debt)，試用了一陣子SonarQube來把關程式碼品質，透過量化的技術債指標來盯緊品質，來筆記安裝及搭配Jenkins組態過程。
走過前幾天持續整合之路，每天我們可以確保專案擁有能編譯正確的程式版本，完成了最基本的版控和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工具的使用及組態，下次同事就可以按圖施工，加快設定的速度。
SQL Server 2017推出STRING_AGG 字串集合的串接函式，但限制是SQL2017的版本。上個月重新加入一個大型專案中，專案的版本要求是SQL 2016，Code Review時發現同事改用For Xml Path再Distinct的替代，T-SQL閱讀起來多了點複雜，捲手來救援T-SQL程式的可讀性。
最近修改了Jenkins Email Notification的帳號來避免每月換密碼，變更改為密碼永久有效帳號後，一寄信卻出現Client does not have permissions to send as this sender訊息。
幾年前使用Visual Studio 2012曾發生過類似的問題，當時是安裝SQL Server Data Tools解決，Visual Studio 2017的年代，再次遇到。好，來解決這個惱人的小問題。
再次和Fortify神鬼交鋒(新的Rule Pack上市)，Fortify SCA新檢測出Path Manipulation及XML External Entity Injection(Input Validation and Representation, Data Flow)，來筆記這次的修正。
如果不想開瀏覽器進Jira網站查詢或修改issue，我們可以有另一個選擇，Visual Studio的擴充套件VSJira。
最近重新用Yahoo YSlow和Google PageSpeed Insights檢測網站前端的效能，其中在YSlow工具上，自己負責的專案被打了兩個Grade D，一個是Configure entity tags，另一個是Use cookie-free domains，今天先來解決ETAG。
最近同事的程式在兩個專案陸續發生SQLCLR無法載入檔案或組件問題，一個發生在測試環境因為備份還原的場景，另一個則是正式環境突發性的發生，自己太少用SQL CLR了，來試試解題然後筆記。
同事的專案寫了一個控制Gridview每頁顯示幾筆的Custom Control(user control)。但同事初始設計時，Custom Control內容只有一個下拉選單DropDownList，沒有把她和gridview結合在一起；後面開始大量開發表單時也沒特別在分頁筆數控制項加上Postback時對應控制Main page Gridview更新的方法，因此當user選擇新的筆數選項後，Gridview內容不會同步更新，使用者操作有點不順手，被開單告發了，來前線救援。
最近同事在匯入大量資料常碰到SQL Msg 8152, String or binary data would be truncated，中文訊息是是字串或二進位資料會被截斷。
除了找出有問題的資料行與列或是將欄位型別改為varchar(max)兩個方法外，能不能在SQL裡自動截斷過長的資料，不要讓SQL出現錯誤?
同事專案的SQL版本是SQL 2016，可以使用SQL 2012 在ORDER BY的延伸功能Offset Fetch，因為某些因素，暫時還是用舊的方式分頁，來幫同事試試新的做法，同時也用兩個小技巧，回傳總筆數及資料序號再來比較。
DB分頁處理時除了回傳總筆數的需求，有時候還得回傳資料在整體資料中的序號，雖然我們用了Offset Fetch，但還是可以和ROW_NUMBER函式結合，透過ORDER BY NOTHING(NULL)，用相同的值來替代排序，SQL查詢只多吃一點可以忽略的成本，來試試。
排序條件在DB的分頁處理中扮演重要的角色，邏輯上，排序能確保每一次的分頁查詢，分頁資料的順序都有一致的預期；在效能上，也因為她的名字是排序，她有決定性的影響。來比較叢集索引、非叢集索引及非索引欄位來作分頁排序時的差異。
Web程式要顯示大量資料時，為了追求效能，被逼上梁山的攻城獅會將資料作分頁(pagination)分次呈現，資料量少點的會透過Web程式進行分頁處理；多一點的，也許就會透過SQL，從DB端作分頁處理來降低資料量傳輸。