.NET Walker

在CI Pipeline當中，想要持續提升開發品質，除了單元測試，靜態程式碼檢查也很重要。在Build Pipeline運行過程中，適度的加上程式碼檢查工具，可以幫助我們掃描程式碼的狀況，檢查是否有具有潛在風險的程式碼。 我們常聽到的程式碼壞味道(code bad smells)，或是技術債(technical debt)，都是靜態程式碼檢查的主要標的。 技術債這個概念是1992年，由Ward Cunningham首次提出。而後常出現於Martin Fowler等大師的文章中。泛指為了縮短開發時程，而在開發過程中做出的妥協(像是安全性、測試、變數的命名…等)雖然可以得到立即的效果，但未來將可能連本帶利付上更大代價。 而SonarCloud，就是這類掃描工具中的翹楚，他是一個獨立的第三方產品，但可以跟Azure DevOps Pipeline做很好的整合。 要在Build Pipeline當中加入SonarCloud進行程式碼檢查非常容易，你只需要到SonarCloud.io申請帳號，並且在Azure DevOps站台上安裝免費套件後，即可進行這樣的掃描。 整個服務完全免費。 安裝SonarCloud 要使用該服務在Build Pipeline上，首先得安裝套件，請至底下網址： https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarcloud 在出現下列畫面時，選擇 Get it free: 接著在出現的畫面中，選擇你的組織(站台)，然後按下Install即可： 安裝完成後，你會發現在建立Pipeline的時候，多了幾個Tempalte： 上面這幾個『…With SonarCloud』的Build Process Tempalte，就是安裝套件後，自動幫您加上的。針對 .Net Core和傳統 .Net Framework環境的開發專案，都有著適合的建置範本可供參考。 申請帳號 在使用之前，我會建議你，先到 https://sonarcloud.io/ 這個站台建立帳號，你只需要透過Azure DevOps帳號(也就是MS Account)即可以Single-Sign-On的方式，取得SonarCloud帳號： 進入SonarCloud的P

在 上一篇 ，我們介紹過如何建立Build Pipeline，完成自動化的建置之後，我們接著要來看如何透過Build Process中的Trigger實現CI(Continuous Integration)。 也就是說，我們要讓雲端上的CI Build Pipeline在有任何程式碼被簽入(異動)的時候，自動運行雲端的Build 我們來修改一下上面這段程式，讓CI Build可以正確地完成Pipeline中的每一個tasks。 但在開啟Visual Studio 2019進行程式碼修改之前，我們先在Pipeline上做一件事情，請點選下圖的Edit切換到Pipeline設計畫面： 進入到設計畫面之後，請在Triggers分頁，勾選『enable continuous integration』： 請留意上圖中的A選項，這意味著， 若source code所在的repo中，master分支上的code有所異動時（不管是直接修改或是透過PR修改），就會自動觸發這個Pipeline進行自動建置 ，這就是所謂的CI(continuous integration)。 設計完成之後，這次我們只需要選擇Save，暫時先不queue一個執行個體(instance)： 因為我們要讓你體驗看看CI Build的威力，待會讓CI機制幫我們自動觸發Build Process。 請依照上圖儲存完之後，回到你用戶端剛才Visual Studio 2019開啟的專案(如果你不想使用Visual Studio 2019，其實也可以用Azure DevOps內建的Web UI，這部分我們日後介紹)，我們把關鍵程式碼(\WebBMI\HealthMgr\BmiCalculator.cs)從int改成float： 完成後，我們透過Git工具將程式碼同步到伺服器端： 當同步完成後，我們可以切換到Azure DevOps管理站台，你會發現由於我們修改了master分支上的程式碼，雲端的Pipeline CI Build被自動觸發了： 同時，由於我們把程式碼改成正確的了，因此Unit Test順利過關： 整個CI Build自動完成了。 到這邊，我們可以看到幾個結論： Pipeline可以在雲端對專案作自動化的建置。 如果將Pipeline的Trigger設定

好，接著我們來看 .net core 應用程式的CI Build。 .net core應用程式的建置環境和傳統 .net framework 有所不同，主要是因為 .net core是跨平台開發技術，你根本可以在 Linux環境上對程式碼進行Build的動作，從頭到尾都無須採用Windows環境。 如果是開發網站，也不需要IIS，直接佈署到Linux伺服器上即可(這個我們後面講CD的時候提)。 我們先來看底下這個Github上的範例： https://github.com/isdaviddong/dotNetCoreBMISample.git 這個範例跟前面 .net framework的範例幾乎一樣，只是以 .net core的Razor Page形式開發。 我們運行起來： 整體功能和先前 .net framework版本完全相同，程式碼結構也相同，唯一的差異就是這個版本是 .net core 3.1開發的。 你可以建立一個新的Azure DevOps Project，並且依照先前介紹過的方法將Github上的程式碼匯入，完成後，應當會看到類似底下這樣： 接著，我們來嘗試建立這個repo的CI Build： 前面的動作都一樣，請留意選擇的Repository別選錯了，按下Continue之後，重點來了，在選擇專案範本的時候，你可以在下圖1的地方，輸入『.net core』作為過濾的關鍵字： 然後在出現的範本中， 選擇上圖A的ASP.NET Core。 你可能會納悶有兩個選項(另一個是上圖B)，原則上兩個都可以， 因為.net core是跨平台開發技術，你可以選擇用Windows或非Windows環境進行Builld，我們選擇上圖A的Ubuntu環境。 接著，會看到該範本中的Tasks大致如下： 你先不用做額外的設定，請直接點選上圖1的Save & queue，系統將會用此範本跑一個Build的執行個體： 請留意上圖中的Agent是ubuntu 16.04。 建置的動作你會發現明顯比Windows環境來的快速很多，很快的整個Build就運行完畢了： 這個.net core版本的程式一樣有運行Unit Test，但我們並沒有故意留下bug，因此建置的過程應該會十分順利。筆者寫稿時雲端的Ubuntu環境上的

當開始邁向CI(continuous integration)，我們第一個要實現的任務是，以雲端(伺服器端)的環境為準，來進行系統的開發、建置、佈署、與測試。 在過去(仿佛是上個世紀以前了)，開發人員可能是以某一台個人開發環境的電腦為準，在多人開發協作之後，把程式碼集中在這台電腦上，進行最終的建置與測試。 但當我們導入了版控系統(像是Git)之後，即便多人同時開發、修改、增添新功能，甚至嘗試一些特殊調整。但在伺服器端，應該總是保持著一套最穩定的版本，可能是Master分支、或是Release分支(選擇分支的策略由團隊決定)，這是之前我們討論版控時候的最終目標與CI的基礎。 當有了這個基礎之後，我們可以建立一個自動化建置的流程，一般稱之為CI Pipeline。由於使用不同的開發語言(或框架)，可能會有著不同的建置流程，因此我們接著會逐步來看，在不同的開發技術下，CI Pepiline的設計方式。 建立 .net framework 專案的Build Pipeline 我們先來看基本的 .net framework專案，如果要練習，你可以建立一個新的Azure DevOps專案，並且在Repos處Clone/Import我們底下這個在GitHub上的程式碼。 https://github.com/isdaviddong/dotNetFxBMISample.git 這是筆者在github上的範例，是一個傳統的 .net framework MVC Web專案(後面我們會在介紹 .net core的做法)，功能是實現一個計算BMI的Web應用程式。 你可以使用Azure DevOps Repos起始畫面的import功能，匯入這個GitHub上的Repo: 一陣忙碌： 完成後，你會看到類似底下這樣的程式碼： 有了source code在Repos中，接著，我們就可以來試試看建立Build Pipeline了。 請點選Azure DevOps左方主選單的Pipelines a New Pipeline： 在緊接著出現的畫面中(下圖)，選擇最下方的『Classic Editor』。 下圖中上面的幾個選項是透過撰寫YAML Code的方式來設計Pipeline，而我們先選用GUI(Classic Editor)： 由於我們的sourc