Azure DevOps in Action - 如何避免開源套件的使用風險

近代軟體開發，不管是使用哪一種語言，幾乎都一定會使用到套件(Package)，套件的使用都有著非常重大的意義。套件不只是讓開發變的更方便，套件的版本管理，能夠讓專案之間的相依性被有效管控，避免dependency hell的發生。

所以各大開發語言，不管是node.js、python、Java…都有自己的套件庫，微軟的.net當然也是，nuget就是.net開發人員的標準套件庫。如今，使用套件庫上的組件來開發企業內的專案，已經是理所當然的習慣了。

套件庫的使用風險

然而，使用套件並非100%毫無風險，由於開源軟體的觀念盛行，這個時代任何人都可以將自己開發的套件貢獻上nuget讓大家使用，雖然開發社群與nuget站台會針對有潛在或惡意風險的套件提出警訊，但由於這些資訊並非即時提供，且有可能因為開發人員的疏忽而沒有被發現，導致你的專案使用到有品質不佳，或是有安全疑慮的套件。

除此之外，套件還有許可授權的問題，並非每一個套件使用上都是毫無代價的，雖然nuget會要求套件開發人員具體標明套件的使用授權許可，但倘若開發人員不察，使用到一些並非可以免費使用的套件，或是使用到了標註為GPL的套件，那你依賴該套件開發的專案，也會被要求開源，這對於公司來說，可能會造成一場災難…

在CI Pipeline中掃描套件

因此，為了避免軟體開發人員一時疏忽，CI Pipeline有必要針對軟體套件的使用作一些掃描和檢查。而WhiteSourceBolt就是這樣的一套免費工具。

你可以在Azure DevOps Pipeline中，加入WhiteSourceBolt這個task，就可以輕易的掃描整個專案中使用的套件：

呈現出的報表如下：

你會發現，報表中清楚的告訴我們，哪些套件是高風險的，並且原因為何(上圖A)。如果你的專案有紅色高風險套件，強烈建議你要立即著手處裡(升級版本或尋找替代套件)。

要在Azure DevOps中啟用WhiteSourceBolt非常簡單，只需要為你的組織安裝Azure DevOps Marketplace中的外掛：

下載位置位於：
https://marketplace.visualstudio.com/items?itemName=whitesource.ws-bolt

安裝好之後，你重新進入Azure DevOps，可以看到在Pipeline選單下，出現了WhiteSourceBolt：

請點選進去，輸入你的聯絡方式註冊後即可使用。

接著，請進入Pipeline，在其中加入WhiteSourceBolt task，並且設定working directory:

完成之後，重新觸發運行pipeline，完成後即可看到報表囉：

幾個小小的動作，讓專案免於套件使用的風險，非常划得來吧。

---

YouTube頻道：https://wwjd.tw/809k364
電子書: https://www.pubu.com.tw/ebook/288713
最新著作:

https://www.tenlong.com.tw/products/9786263241251?list_name=b-r7-zh_tw

內容審查(Content Moderator)服務

當網路上出現一則訊息，誰有權力判斷這則訊息的真假?
1.政府 2.平台業者 3.KOL(Key Opinion Leader, 意見領袖) 4.我自己

上面這個問題，不知道你的答案會選擇甚麼?

這兩天沸沸揚揚的中介法，造成了很多網路上的輿論。主因是平台業者被要求有責任管理(刪除或標註)不實言論，否則要罰款。

但這中間出現了兩個問題 1. 誰決定不實? 2. 如何做到有效即時的內容管理?

身為技術人員，我想從技術的角度談這件事情。首先，有沒有可能即時發現用戶將有問題的內容張貼到網站上? 技術上確實有可能。

現在微軟Azure, AWS, Google都有許多雲端AI服務，可以辨識圖片、影音、文字，近乎即時的判斷內容是否涉及情色、猥褻、或是具有冒犯意味甚至鼓吹自裁。這服務微軟叫做 Azure Content Moderator，內容仲裁。總的來說，在當今的AI技術上，我們早就可以針對圖片、影像、或文字進行客觀的內容判斷，這些技術已經逐漸成熟，經驗上準確度大約八九成沒問題。

所以各大網站(像是FB)可能早已把這些技術用在內容分析上了(如果你的網站也需要，但不知道該怎麼做，可以與我聯繫)。但問題是，這些AI服務，可以判斷內容，無法知道對錯。

因為內容的正確與否，涉及價值觀的判斷。
在這個世界上，並不是所有事情都是非黑即白，一翻兩瞪眼的不是對就是錯，更何況，真假對錯很可能因為時間而有所改變。一開始你可能以為是對的(內容為真)，但經過時間，很可能發現是錯的(內容為假)，反之亦然。舉個更簡單的例子，不同世代對於同一件事情的看法，也往往南轅北轍。

如果第一時間不分青紅皂白的，就直接屏蔽刪除或標註某種論點，很可能事情將永遠沒有水落石出的一天。當然，如果你不在意真相(只在意管理)，也就無所謂。

所以，從技術的角度來說，現在的科技就算不用靠誰立法、無須哪個單位協助，單單使用AI技術，就足以判斷內容是否違背善良風俗，這個也早就在做了。然而問題是，會不會我覺得的裸露、是你覺得的藝術呢? 這條界線該如何決定? 誰決定? 因為一旦涉及主觀價值判斷，所有的一切就變的不再簡單。

因此，AI就算能幫你辨識內容，卻無法幫你判斷真偽。
是非、對錯、真假，都很難由誰單方面說了算。

因此，我們再看一次這個問題。
當網路上出現一則訊息，誰有權力和責任判斷這則訊息的真假?
1.政府 2.平台 3.KOL(Key Opinion Leader, 意見領袖) 4.AI(人工智慧) 5.我自己

好，現實問題是，網路層出不窮的假訊息，詐騙事件頻傳，已經對很多人造成傷害，如果不該由特定單位、特定人來過濾特定訊息，那該怎麼辦? 難道讓人民自己判斷?

底下有個關於真偽的小故事…
有人問銀行裡面假鈔辨識員 : 為何你能夠瞬間就識別出仿製精良、栩栩如真的假鈔? 你們是有受過什麼特殊的訓練嗎? 是不是因為早已看過了市面上每一種假鈔，所以才能迅速識別?

行員回答: 我是沒有看過每一種假鈔，但我因為每天都在看真鈔，所以碰到假鈔自然比一般人敏感一些。

就是這樣，沒別的答案了。
所有的真假，都涉及主觀判斷。

真的訊息可以聽起來匪夷所思，假的訊息也可能看起來毫無破綻，不是有權力、有資源的單位就一定可以判斷正確。如果無法讓人民成熟、成長…到有獨立判斷的能力，那一切最終都是白搭。更何況，與其相信政府、相信特定KOL、相信特定網站平台的判斷，那我還不如相信AI，因為至少，我知道這些雲端AI服務，設計的時候已經盡量排除既定的價值觀(主觀)。

然而，真正能判斷對錯是非的，永遠只有自己。

政府該做的，是提供民眾更多的管道、教育資源、技術，來幫助民眾自行判斷(決定)真偽，並且持續增加民眾的素養，讓大家有能力自己做出正確的判斷。而非幫民眾進行內容審查，或由特定單位(或網路平台)來幫民眾決定真假是非對錯。

最近開飛機的湯姆克魯斯很紅，但我卻想到另一部他主演的電影–《關鍵報告》(Minority Report)。劇中的預知科技，可以讓罪犯在還沒行動前就被制止，在還沒造成傷害前就把加害人給逮捕，這樣的社會看似超完美，完全沒有任何犯罪。所有可能的犯行都被預先銷聲匿跡於無形。

但這真是你要的世界嗎?

網路假訊息確實造成了很大的困擾，網路霸凌、情色甚至手機成癮都引發了不少的問題，但這現象表示，人類的理智與成熟度似乎跟不上網路發展的快速。這意味著，我們必須投入更多的資源，來培養人民獨立判斷是非、獨立思考的能力，而不是簡單的封鎖、禁止、遮蓋或屏蔽。當然，我知道這樣做在技術上簡單多了。

然而解決核心問題，才是我們需要有權力、有資源的政府和與單位，更多投入心力的，不是嗎?

Let it be

每當寫程式或文稿累了的時候，我會到河堤騎車。

最近這幾年，台北鄰靠基隆河的兩岸，都有了挺不錯的自行車道，幾乎沒甚麼難騎的上下坡，很適合以悠哉閒逛的心情慢慢騎吹吹風…

一天，忙了一整個下午，趁夜幕微微垂下，趕在日落前，我租了YoiuBike在河堤邊緩緩騎乘。岸邊隨風飄來青草的香味，讓人很是愉快。

正當我覺得身心放鬆，通體舒暢。卻不知耳邊何時傳來了一陣犀利(你要說淒厲也行)的對談聲，有點像是你去傳統菜市場會聽到的那種婆婆媽媽在攤販前理直氣壯的討價還價聲，聲音從遠而近，由小而大，漸漸飄了過來。

仔細一聽，位於六點鐘方位，後方。
一群騎著貌似淑女自行車的大媽，集團似的緩緩逼近。

我側眼一瞥，數了一數，五位。喔不，是六位，其中一位有些落單，奮力的在後面追趕。

前面五位大媽，領頭的三人，並排而行，佔據了來往雙線車道，伴隨著中氣十足的對談，讓人不注意到她們都很難。雖然距離有些遠，但言談中我依稀聽到關於某位大媽的兒子的太太的最近一些態度問題…呃…不關我事，非禮勿聽，我騎我的車。

加速前進。

可能是我租賃的YouBike齒輪比不佳，也可能是每天騎車的大媽中氣十足，我雖然加速超前了一定的距離，但每當我放鬆開始欣賞河邊的景色和迎風吹來的芬芳草香，一不注意，這群大媽集團立刻從後方逼近。一連數次，我在聽到了大媽們對談的特殊嗓音時，才意識到我快要被集團軍輾斃，只能瞬間加速遠離…但沒多久，我優閒的騎車氛圍就又會被身後堅持出現的音量所打破。

大媽們像是擁有裝上了勁量永備電池一樣的持久續航力，以堅毅且穩定(甚至我覺得似乎有愈來愈快)的速度屢屢逼近。

每當大媽集團軍從後方接近，我airpods裡的音樂聲量，總是不爭氣的敗陣下來…
當這條沿岸車道已經騎了約莫三分之二時…我，終於做出了決定。

在車道轉角處的某一個空曠處，我停了下來。站穩步伐，拍拍身上的風沙灰塵，好整以暇的，帶著敬佩與釋放的心情，目送大媽集團軍隊從我眼前騎過去…

喝了口從家中帶出來的水壺裡的氣泡水，整理了一下裝束，跨上自行車，我開始緩緩而行。

我何苦讓自己被身後追趕的雜音持續干擾著呢?

人生旅程上總是會碰到不同的人群，路程上人來人往、來來去去，我又不是要和誰比賽，幹嘛跟自己過不去，身後的雜音，不如就讓它從眼前過去。

等雜音遠離，我戴上耳機，依舊開始自在的騎自己的路，欣賞屬於自己的風景，以我自己習慣的速度，自由前行。

Azure DevOps in Action - 使用Deployment Group進行地端大量部署

使用Azure DevOps Services，部署到雲端相對容易，部署到地端環境，得考慮的事情就多了。主要的原因是，Azure DevOps Services在雲端，無法(也不應該)直接跳過防火牆存取地端環境上的伺服器。

另外，如果不管是雲端或地端伺服器，若是HA(高可用性)架構，做了負載平衡(Load Balance)或是Failover，部署站台時，需要把同樣的artfact一次部署到多台伺服器，在pipeline的設計上也有一定的難度。

上面提到的這些事情，解決方案就是『Deployment Group』。

功能說明

Deployment Group可以讓你把特定artifact一次部署到多台伺服器，同時，也可以突破防火牆的限制，從雲端部署到地端。其中的關鍵就在於，你必須在伺服器端安裝一個代理程式。

我們來看一下底下這個準備好的情境，我們準備了兩台Windows Server 2019 VM，名稱分別是testdpvm1與testdpvm2。並且，在這兩台伺服器上開啟了IIS，也運行了基本的網頁如下:

同時，我們也建立了一個Azure DevOps Team Project，其中的repo很簡單，只有一個html檔案：

並且，我們為這個repo的部署建立了一個CI Pipeline:

這個CI Pipeline的功能也超單純，只是打包這個 .html頁面成為 .zip檔案，然後放入(publish)到drop資料夾，準備給CD Pipeline使用。

建立Deployment Group

接著重點來了，我們待會要將drop資料夾中的artifact透過CD Pipeline如同『穿越防火牆』一般地『同時』發佈到那兩台剛才建好的VM上，為此，我們來建立Deployment Group。請在Pipeline功能中，找到Deployment Group，並且建立新的Deployment Group：

接著，為Deployment Group命名，一般採用的是你的環境名稱，例如Dev、QA、Production…等。

然後，請複製出現的PowerShell Script (別忘了要勾選Use a personal access token in the script for authentication)：

運行代理程式

接著，請到剛才那兩台VM上，以PowerShell的admin模式，執行複製的PowerShell Script：

其中的問答都以enter跳過即可。

完成後，你回到Azure DevOps的Deployment Group畫面檢視，會看到兩個agent已經出現：

透過deployment group進行部署

接著，我們來設計CD Pipeline，你可以透過『IIS WebSite』這個關鍵字過濾，找到『IIS WebSite Deployment』這個範本：

這個範本預設採用Deployment Group Job：

你只需要透過設定畫面選擇剛才建立好的Deployment Group名稱，你會發現，上圖右下角畫面會出現該Group預計部署的機器數量。

接著，在job中只需要保留IIS Web App Deploy這顆task即可：

設定完成之後，我們可以試著運行CI Pipeline產生artifact。接著，觸發CD Pipeline進行部署：

如果部署成功，將會出現底下畫面：

這表示兩個環境都成功了，我們來看運行的結果：

果然，兩個站台上的網站都變成我們CI Pipeline所建置出的artifact了。透過Deployment Group，我們可以不僅可以進行目標站台的大量部署，同時，由於目標環境上安裝友agent，我們也可以突破防火牆的限制，部署到地端或是較封閉的環境，Deployment Group的使用是一個非常重要的技巧。

---

更多資訊:
Azure DevOps 顧問實戰
https://www.tenlong.com.tw/products/9786263241251?list_name=b-r7-zh_tw

電子書:
https://www.pubu.com.tw/ebook/288713

教育訓練:
https://www.studyhost.tw/NewCourses/ALM

快速產生 .net core 測試程式碼覆蓋率報表

昨天，幫客戶介紹 .net core 的單元測試(Unit Test)開發。

其實，單元測試(Unit Test)是個非常簡單的概念，近代開發工具本身也都進化的超級方便，輕輕鬆鬆的就可以建立出單元測試專案的架構。

單元測試(Unit Test)看起來一點都不難。

這話只對了一半，單元測試難的地方並非撰寫單元測試程式碼本身(甚至，單元測試程式碼本來就應該盡可能的簡單，簡單到不該出現邏輯)，難的地方是為了實施單元測試前的程式碼重構(如何增加程式碼的可測試性)，以及如何在企業內真的推廣和實作。(因為上至主管下至開發人員，總有成千上百個看來非常合理的理由，解釋為何自己現階段無法導入單元測試)

不過，這些困難的問題，我們留到課程裡面再討論。

我們今天先來看一個簡單的，如何在 .net core 產生測試程式碼覆蓋率的報表。

其實，只有三個動作，第一個，請安裝 .net tool:

dotnet tool install -g dotnet-reportgenerator-globaltool

然後
透過 dotnet CLI 跑一次單元測試進行資料蒐集，記得請在 .sln 或 .csproj 所在的目錄下執行:

#收集資訊
dotnet test --collect:"XPlat Code Coverage"

請注意上面的 --collect:“XPlat Code Coverage” 參數，是為了蒐集單元測試涵蓋率資訊，執行完畢之後，會出現底下畫面，請特別注意XML檔案所在位置:

因為我們下一個指令需要該位置資訊。

最後，請執行:

reportgenerator  -reports:"路徑\coverage.cobertura.xml" -targetdir:"report" -reporttypes:Html

嘩啦，單元測試涵蓋率報表出來了(位於report資料夾中，還是HTML格式的)，就這樣:

簡單吧~

迭代、敏捷 與 滾動式調整

今天上課的時候，跟同學聊到，最近很流行的一個詞彙 『滾動式修正』(或 滾動式調整)。

不知道你自己對這個詞的定義是什麼? 所謂的『滾動式調整』是不是走一步算一步? 是不是朝令夕改的美化版? 是不是先做再說，後面再看著辦?

儘管很多人不明所以，但『滾動式調整』這個詞彙這幾年仍被許多團隊理所當然地使用著。為何過去從沒聽過，這幾年卻如此盛行? 我自己覺得，和敏捷(Agile)似乎脫不了關係。

敏捷(Agile)存在的意義，是因為我們認知到並承認，現今外在環境的變化實在太快了，快到我們再也沒法像過去一下，先妥善地做完計畫，然後再動手實行。如果堅持如此，將會錯失先機。

此外，更重要的是，倘若沒有先著手實施，試著得到外界真實的反饋，只在辦公室裡籌算，即便覺得計畫得再周密，一但拿到真實世界裡，很可能就會立刻破功。

這兩者都是同樣的前提 --> 這個世界變化得愈來愈快。
這也是敏捷之所以日趨主流的原因。

而敏捷的被認可，或多或少讓『滾動式修正』變得理所當然。然而，真的每一個組織，每一個單位，每一個計劃，都適合滾動式修正嗎?

今天上課談的是DevOps。
我問學員：『如今需求變化快速已不可避免。假設，持續交付 (所謂的持續交付，一般是指一天數次這樣的頻繁上版，最少也是一周數次，不會更低)是必須的，那什麼是持續交付的基礎?』『一家公司、一個團隊，一個專案，能夠毫無準備的就實施頻繁交付(CD-Continuous Delivery)嗎?』

答案是 : 『不能』。

因為，沒有良好準備的頻繁交付，將會帶來災難。

頻繁交付的前題是持續整合(CI-Continuous Integration)，持續(密集)到什麼程度? 最好應該是一天數次，至少是一周數次，將程式碼頻繁的簽入並且合併至主線(main)。同時在合併前進行程式碼品質掃描、安全性掃描、單元測試。如果這些都沒做到，那請容我這麼說，目前這個團隊(專案)恐怕還不到可以實施頻繁交付(CD-Continuous Delivery)的程度。

所以，持續交付(或謂 頻繁交付，不過這兩者其實有些許不同)的前提，是良好的基礎建設(這邊指的基礎建設是指 CI - Continuous Integration)。

同樣的，若企業想要執行『滾動式修正』，你的團隊和行政體系必須要有足夠良好的體質，這體質指的是 : 快速的執行效率、順暢的溝通管道、卓越的行政系統、高效的組織架構。不僅如此，還要有良好的防呆機制和安全性防護措施(就如同我們在CI的過程中，有著各種自動化檢查和安全性掃描一樣)。

唯有已具備良好體質的團隊，在面對快速迭代、持續修正的計畫與指令時，才能游刃有餘。

否則，我們的『滾動式修正』將帶來災難，大家看到的只會是『滾動』，而沒有『修正』。沒有辦法得到持續修正、持續改善的效果。要記得，並非所有的『滾動』都會帶來價值，就如同並非所有的『頻繁交付』都會為帶來價值一般。

我們真正想要的並不是滾動，而是修正。正如同敏捷想要的並不是迭代，而是持續改善。

唯有頻繁修正、持續改善才是價值的來源。而為客戶帶來價值，才是我們真正想要實現的成果。

Azure DevOps in Action - 部署到僅支援FTP的環境

除了採用Azure WebApp作為網站應用程式的運行環境之外，肯定有更多的開發人員，是採用其他的環境作網站的部署。有可能是主機代管，有可能是其他的雲端服務，也有可是地端環境。

那這些環境該如何進行部署呢? 最簡單的方式是透過FTP。

FTP是絕大部分網站肯定都支援的部署方式，也是傳統手動進行網站部署行為的時候，最常見的選擇。

要在Azure DevOps的pipeline當中進行FTP部署相當容易，你可以透過FTP Upload這個內建的task，即可完成上傳動作:

當你把該task加入job中之後，會看到底下設定：

上圖A的部分，是站台的身分驗證方式，你可以選擇為此站台建立一個connection或是直接輸入身帳號密碼，上圖中，我們選擇直接輸入帳密。

而上圖B、C、D三個欄位則是FTP伺服器的URL以及帳號密碼，這應沒什麽疑義。但需要注意的是上圖E，這個欄位需要輸入的是FTP來源檔案位置，也就是Pipeline當中，先前build好的artifacts所在的位置。這個位置從何而來? 由於目前我們展示的是CI Pipeline，因此該位置你應當參考前面Publish Task的結果：

參考上圖A，Buld好的結果預設的輸出位置使用了系統變數『＄(build.artifactstagingdirectory)』，因此，我們在FTP Upload的Task中，Root Folder就是設定為『＄(build.artifactstagingdirectory)』：

另外，請特別留意Publish Task中的『Zip published projects』選項，它預設是勾選的，你會發現我們將其取消了。原因是，勾選該項目，會讓publish task將發佈的成品壓縮成.zip檔案，但如此一來我們透過FTP送上站台的時候，反倒不能直接運行了。

因此，原本publish的zip選項必須取消。然後，我們再回頭看FTP Uploader task的Root foder，其設定就是先前Publish task的output位置:

最後，別忘了設定你上傳後這些檔案要放在遠端站台的哪一個路徑(上圖F)，這個位置可能因為你選擇(或設定)的Web Server的不同而不同，上圖site/wwwroot是因為我們選用的是azure web app，其預設路徑就是site/wwwroot這個位置。

當你運行該Pipeline，會發現FTP Uploader確實可把檔案上傳到伺服器端：

如此一來，就可以順利地透過FTP在Pipeline中發佈網站囉。

備註：
上面的範例雖然是採用CI Pipeline來進行，但若讀者想要使用CD(Release) Pipeline來進行一樣的動作，當然也是可行的。

YT Video:
https://youtu.be/GgmwpaoJo84

參考資料:
Azure DevOps 顧問實戰
https://www.tenlong.com.tw/products/9786263241251?list_name=b-r7-zh_tw

電子書:
https://www.pubu.com.tw/ebook/288713