2022年8月19日 星期五

Let it be

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

最近這幾年，台北鄰靠基隆河的兩岸，都有了挺不錯的自行車道，幾乎沒甚麼難騎的上下坡，很適合以悠哉閒逛的心情慢慢騎吹吹風…
enter image description here
一天，忙了一整個下午，趁夜幕微微垂下，趕在日落前，我租了YoiuBike在河堤邊緩緩騎乘。岸邊隨風飄來青草的香味，讓人很是愉快。

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

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

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

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

加速前進。

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

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

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

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

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

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

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

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

張貼者： 於 沒有留言:

2022年7月25日 星期一

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

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

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

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

功能說明

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

我們來看一下底下這個準備好的情境，我們準備了兩台Windows Server 2019 VM，名稱分別是testdpvm1與testdpvm2。並且，在這兩台伺服器上開啟了IIS，也運行了基本的網頁如下:
enter image description here
同時，我們也建立了一個Azure DevOps Team Project，其中的repo很簡單，只有一個html檔案：
enter image description here
並且，我們為這個repo的部署建立了一個CI Pipeline:
enter image description here
這個CI Pipeline的功能也超單純，只是打包這個 .html頁面成為 .zip檔案，然後放入(publish)到drop資料夾，準備給CD Pipeline使用。

建立Deployment Group

接著重點來了，我們待會要將drop資料夾中的artifact透過CD Pipeline如同『穿越防火牆』一般地『同時』發佈到那兩台剛才建好的VM上，為此，我們來建立Deployment Group。請在Pipeline功能中，找到Deployment Group，並且建立新的Deployment Group：
enter image description here
接著，為Deployment Group命名，一般採用的是你的環境名稱，例如Dev、QA、Production…等。

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

運行代理程式

接著，請到剛才那兩台VM上，以PowerShell的admin模式，執行複製的PowerShell Script：
enter image description here
其中的問答都以enter跳過即可。

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

透過deployment group進行部署

接著，我們來設計CD Pipeline，你可以透過『IIS WebSite』這個關鍵字過濾，找到『IIS WebSite Deployment』這個範本：
enter image description here
這個範本預設採用Deployment Group Job：
enter image description here
你只需要透過設定畫面選擇剛才建立好的Deployment Group名稱，你會發現，上圖右下角畫面會出現該Group預計部署的機器數量。

接著，在job中只需要保留IIS Web App Deploy這顆task即可：
enter image description here
設定完成之後，我們可以試著運行CI Pipeline產生artifact。接著，觸發CD Pipeline進行部署：
enter image description here
如果部署成功，將會出現底下畫面：
enter image description here
這表示兩個環境都成功了，我們來看運行的結果：
enter image description here
果然，兩個站台上的網站都變成我們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

張貼者： 於 沒有留言:

2022年6月18日 星期六

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

enter image description here

昨天，幫客戶介紹 .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檔案所在位置:
enter image description here

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

最後，請執行:

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

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

簡單吧~

張貼者： 於 沒有留言:

2022年5月26日 星期四

迭代、敏捷 與 滾動式調整

enter image description here

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

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

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

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

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

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

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

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

答案是 : 『不能』。

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

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

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

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

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

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

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

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

張貼者： 於 沒有留言:

2022年5月21日 星期六

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

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

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

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

要在Azure DevOps的pipeline當中進行FTP部署相當容易，你可以透過FTP Upload這個內建的task，即可完成上傳動作:
enter image description here
當你把該task加入job中之後，會看到底下設定：
enter image description here
上圖A的部分，是站台的身分驗證方式，你可以選擇為此站台建立一個connection或是直接輸入身帳號密碼，上圖中，我們選擇直接輸入帳密。

而上圖B、C、D三個欄位則是FTP伺服器的URL以及帳號密碼，這應沒什麽疑義。但需要注意的是上圖E，這個欄位需要輸入的是FTP來源檔案位置，也就是Pipeline當中，先前build好的artifacts所在的位置。這個位置從何而來? 由於目前我們展示的是CI Pipeline，因此該位置你應當參考前面Publish Task的結果：
enter image description here
參考上圖A，Buld好的結果預設的輸出位置使用了系統變數『＄(build.artifactstagingdirectory)』，因此，我們在FTP Upload的Task中，Root Folder就是設定為『＄(build.artifactstagingdirectory)』：
enter image description here
另外，請特別留意Publish Task中的『Zip published projects』選項，它預設是勾選的，你會發現我們將其取消了。原因是，勾選該項目，會讓publish task將發佈的成品壓縮成.zip檔案，但如此一來我們透過FTP送上站台的時候，反倒不能直接運行了。

因此，原本publish的zip選項必須取消。然後，我們再回頭看FTP Uploader task的Root foder，其設定就是先前Publish task的output位置:
enter image description here
最後，別忘了設定你上傳後這些檔案要放在遠端站台的哪一個路徑(上圖F)，這個位置可能因為你選擇(或設定)的Web Server的不同而不同，上圖site/wwwroot是因為我們選用的是azure web app，其預設路徑就是site/wwwroot這個位置。

當你運行該Pipeline，會發現FTP Uploader確實可把檔案上傳到伺服器端：
enter image description here
如此一來，就可以順利地透過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

張貼者： 於 沒有留言:

2022年5月16日 星期一

自動幫用戶開啟RichMenu與鍵盤or語音輸入

LINE在2022/5/13增加了postbackAction的屬性，讓發人員可以藉由送出一個含有postbackAction的訊息(類似底下這樣)，來幫用戶來開啟(或關閉)rich menu，甚至可以開啟輸入鍵盤和語音:
enter image description here

上圖 A 的部分，是一個 Buttons Template Message，其中有四個按鈕，其類型都是我們先前介紹過的 postbackAction。

在過去，當用戶點下postbackAction按鈕時，只會讓伺服器端的WebHook收到一則訊息，但LINE 2022/5/13 增加了此功能之後，postbackAction多了兩個重要的屬性，分別是inputOption與fillInText。

inputOption可以是底下的值:

  • closeRichMenu: 關閉 rich menu
  • openRichMenu: 開啟 rich menu
  • openKeyboard: 開啟輸入鍵盤
  • openVoice: 開啟語音輸入

而 fillInText 則是當inputOption為openKeyboard時，開啟的文字輸入鍵盤中的預設文字。

例如，當建立 postbackAction 的程式碼如下:

Actions.Add(new  isRock.LineBot.PostbackAction() 
{
label  =  "開鍵盤",
data  =  "openKeyboard",
displayText  =  "開鍵盤",
fillInText  =  "預設文字",
inputOption  =  "openKeyboard"
});

則用戶點選該選單後，結果如下:
enter image description here

當您建立 postbackAction 的程式碼如下:

Actions.Add(new  isRock.LineBot.PostbackAction() 
{
label  =  "開選單",
data  =  "openRichMenu",
displayText  =  "開選單",
inputOption  =  "openRichMenu"
});

則用戶點選該PostbackAction選項，結果如下:
enter image description here

你還可以透過底下指令，來開啟語音輸入:

Actions.Add(new  isRock.LineBot.PostbackAction() 
{
label  =  "開語音輸入",
data  =  "openVoice",
displayText  =  "開語音輸入",
inputOption  =  "openVoice"
});

執行結果如下:
enter image description here

很有趣吧，這功能可以讓你的LINE Bot與用戶的互動更加的便捷， .net core 的範例程式碼在底下:
https://github.com/isdaviddong/ExLineRichMenuautomaticOpeningAndClosing

你只需要將 LineBotSDK 升級到 2.5.33-beta 以上的版本即可。

張貼者： 於 1 則留言:

2022年5月13日 星期五

Azure DevOps 中的 Release Gate

enter image description here
在使用自動化上版的過程當中，你大概或多或少會想要使用簽核(Approval)的功能。簽核功能讓你可以自動佈署到特定站台(例如正式機)之前，形成一個 “把關” 的功能。

雖然感覺用起來很酷，但坦白說，我們對於上新版程式前的Approval行為，在態度上是不鼓勵的。因為多年下來，並沒有案例顯示，上版前的簽核真能夠減少什麼風險或是降低問題發生的機率。反倒是常常因為Approver卡住流程，造成自動化效率的降低。

如果企業是為了要有人負責，才配置這個Approver，那我們就更不鼓勵了。因為大部分的Approver其實無法在上版前真的做什麼檢查，常常有簽核權限的PM只是回頭問問工程師 : 『可以上正式機了嗎? 可以? 那我就按"同意"了唷』。這樣的橡皮圖章其實讓人很心酸。

事實上，大部分能做該做的檢查，根本早就在(也應該要在)自動化流程中被完成，而非靠人工的檢核。

更好用的機制 - Release Gate

比起Approvals的設定，Release Gate其實是配合自動化部署更好的選擇。

設定的方式類似 Approvals，只需要先將選項設為 Enabled即可啟動(下圖A)，接下來就是設定要作為Gate的機制(下圖B)：
enter image description here

按下Add之後，你可以選擇要作為Gate的機制：

enter image description here

系統已經內建不少的Gate類型可供選擇，其中比較常用的大概是『Invoke REST API』和『Query work items』。另外『SonarCloud Quality Gate』則是外掛的套件，配合SonarCloud軟體品質掃描用的。

當你設定了Release Gate這個機制，它將會每隔幾分鐘(最少五分鐘)檢查一次你設定的條件，當該條件成立的時候，才會允許Pipeline繼續往下進行。

這個功能可以幫助我們，在自動化的過程中減少不需要的人力介入或簽核，即可自動檢查特定條件是否成立。你也可以撰寫Azure Function，或是使用Invoke REST API方法來呼叫特定API，取得回傳值，以判斷是否可以讓Release Pipeline繼續往下運行。

在高強度(一天數次或一周數次)的頻繁交付過程中，Release Gate比起人工簽核(Approval)更是合作上版前的自動化關卡檢查機制。

來，以後試著放棄橡皮圖章吧。

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

張貼者： 於 沒有留言:
訂閱： 文章 (Atom)

熱門文章

  • 使用C#開發LineBot(6) - 不用申請Bot也能發訊息的Line Notify
    前面 我們討論到了很多跟Line Bot有關的機制，但有朋友提了一個問題，如果我單單只是要透過程式碼發訊息給用戶，一定要申請並建立一個Line Bot嗎? 其實不用。 一直以來，有一個比較不被重視的機制，叫做LINE Notify，其實它已經誕生很久， IFTTT 的Line...
  • VS Code的字體大小
    身為.net developer，這年頭是什麼code都得要會寫的年代。 而雖然我的NB還沒從Windows淪陷為Mac OS，但寫Node.js和Python免不了要用VS Code，這是一種愛的表現。 但歲月不饒人，盡管微臣非常熱於配合，但VS Code預設字體的大小在我還沒...
  • 使用C#開發LineBot (1) - 用c#建立一個LineBot
    注意，本篇部分內容已過時，新版Line bot申請流程，請參考 這篇 。 前面 說過，不知道發生了什麼事情，全球幾個大廠幾乎在同一個時間announce各家的機器人技術或介面，包含Microsoft 的bot API，還有FB、Line…到最近的Google，總之突然間，原本封...
  • 使用C#開發LineBot(3) - 使用LineBotSDK發送Line訊息
    新版的Line Messaging API，要主動發送訊息給用戶不是很困難，主要是透過Push API，可以參考底下的官方說明 : https://devdocs.line.me/en/#push-message 另外，如果你想申請一個Line Bot，可參考: 關於LineB...
  • Let it be
    每當寫程式或文稿累了的時候，我會到河堤騎車。 最近這幾年，台北鄰靠基隆河的兩岸，都有了挺不錯的自行車道，幾乎沒甚麼難騎的上下坡，很適合以悠哉閒逛的心情慢慢騎吹吹風… 一天，忙了一整個下午，趁夜幕微微垂下，趕在日落前，我租了YoiuBike在河堤邊緩緩騎乘。岸邊隨風飄來青草的...
  • 一次搞懂OAuth與SSO在幹什麼?
    最近的 Line Notify 、 Line Login ，以及前一陣子的 Microsoft Graph API ，全都使用到了OAuth作為用戶身分驗證以及資源存取的基礎。但很多讀者會卡在OAuth的運作流程上，根本的原因是不理解OAuth到底是幹嘛的?其存在的目的為何?以及...
  • [隨手筆記]C#字串中的Right方法
    改用C#好一段時間了，但是以前寫VB的習慣總是如影隨形的跟著。這沒什麼好或不好，以前說過，這年頭沒有雙語能力是不行的。 只是有時候我就是不很明白，為何VB有些簡單的字串方法C#怎麼也不肯加進來。不過，人家有人家的道理，我們則只能在變通當中找個繞路的方式。 我最近在C#程式...
  • 使用C#開發LineBot(17) – 使用新版Line Login v2.1
    Line在去年以OAuth規格推出了Line Login機制，試圖與各家大廠一起角逐身分驗證與單一登入SSO(Single-Sign-On)的一席之地，相關的概念與使用方式我們在06年底曾經 介紹過 。 而關於SSO與OAuth相關的技術與概念，我們也曾經在 這邊 有過分享。 今...
  • 使用IoC與DI(Dependency Injection)有何意義? (一) 它到底是甚麼?
    其實我們在好幾年前，就已經談過DI(Dependency Injection)這個主題。當時這類議題被視為進階的開發概念，但如果你最近開始使用 .net core，大概已經發現DI如今已變成.net core中的基本要求。 事實上，從事教育訓練這麼多年的觀察下來，不難發現其實還是...
  • 讓解析度低於1024x768的小平板(或觸控小筆電)可以運行Windows 8 Metro Apps
    Windows 8, 一幅蓄勢待發的姿態。 在最近一兩個月，微軟全省跑透透，辦了多場介紹Windows 8的研討會，也陸續的在網路上大方的提供了Windows 8先前的Developer Preview以及最近的Consumer Preview版本讓大家免費下載。 過去段...