.NET Walker

今天上課的時候，跟同學聊到，最近很流行的一個詞彙 『滾動式修正』(或 滾動式調整)。 不知道你自己對這個詞的定義是什麼? 所謂的『滾動式調整』是不是走一步算一步? 是不是朝令夕改的美化版? 是不是先做再說，後面再看著辦? 儘管很多人不明所以，但『滾動式調整』這個詞彙這幾年仍被許多團隊理所當然地使用著。為何過去從沒聽過，這幾年卻如此盛行? 我自己覺得，和敏捷(Agile)似乎脫不了關係。 敏捷(Agile)存在的意義，是因為我們認知到並承認， 現今外在環境的變化實在太快了 ，快到我們再也沒法像過去一下，先妥善地做完計畫，然後再動手實行。如果堅持如此，將會錯失先機。 此外，更重要的是，倘若沒有先著手實施，試著得到外界真實的反饋，只在辦公室裡籌算，即便覺得計畫得再周密，一但拿到真實世界裡，很可能就會立刻破功。 這兩者都是同樣的前提 --> 這個世界變化得愈來愈快。 這也是敏捷之所以日趨主流的原因。 而敏捷的被認可，或多或少讓『滾動式修正』變得理所當然。然而，真的每一個組織，每一個單位，每一個計劃，都適合滾動式修正嗎? 今天上課談的是DevOps。 我問學員：『如今需求變化快速已不可避免。假設，持續交付 (所謂的持續交付，一般是指一天數次這樣的頻繁上版，最少也是一周數次，不會更低)是必須的，那什麼是持續交付的基礎?』『一家公司、一個團隊，一個專案，能夠毫無準備的就實施頻繁交付(CD-Continuous Delivery)嗎?』 答案是 : 『不能』。 因為， 沒有良好準備的頻繁交付，將會帶來災難 。 頻繁交付的前題是持續整合(CI-Continuous Integration)，持續(密集)到什麼程度? 最好應該是一天數次，至少是一周數次，將程式碼頻繁的簽入並且合併至主線(main)。同時在合併前進行程式碼品質掃描、安全性掃描、單元測試。如果這些都沒做到，那請容我這麼說，目前這個團隊(專案)恐怕還不到可以實施頻繁交付(CD-Continuous Delivery)的程度。 所以，持續交付(或謂 頻繁交付，不過這兩者其實有些許不同)的前提，是良好的基礎建設(這邊指的基礎建設是指 CI - Continuous Integration)。 同樣的，若企業想要執行『滾動式修正』，你的團隊和行政體系必須要有足夠良好的體質，這體質指的是 : 快速

除了採用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，其預設路徑就是

LINE在2022/5/13增加了postbackAction的屬性，讓發人員可以藉由送出一個含有postbackAction的訊息(類似底下這樣)，來幫用戶來開啟(或關閉)rich menu，甚至可以開啟輸入鍵盤和語音: 上圖 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" }); 則用戶點選該選單後，結果如下: 當您建立 postbackAction 的程式碼如下: Actions.Add(new isRock.LineBot.PostbackAction() { label = "開選單", data = "openRichMenu", displayText = "開選單", inputOption = "openRichMenu" }); 則

在使用自動化上版的過程當中，你大概或多或少會想要使用簽核(Approval)的功能。簽核功能讓你可以自動佈署到特定站台(例如正式機)之前，形成一個 “把關” 的功能。 雖然感覺用起來很酷，但坦白說，我們對於上新版程式前的Approval行為，在態度上是不鼓勵的。因為多年下來，並沒有案例顯示，上版前的簽核真能夠減少什麼風險或是降低問題發生的機率。反倒是常常因為Approver卡住流程，造成自動化效率的降低。 如果企業是為了要有人負責，才配置這個Approver，那我們就更不鼓勵了。因為大部分的Approver其實無法在上版前真的做什麼檢查，常常有簽核權限的PM只是回頭問問工程師 : 『可以上正式機了嗎? 可以? 那我就按"同意"了唷』。這樣的橡皮圖章其實讓人很心酸。 事實上，大部分能做該做的檢查，根本早就在(也應該要在)自動化流程中被完成，而非靠人工的檢核。 更好用的機制 - Release Gate 比起Approvals的設定，Release Gate其實是配合自動化部署更好的選擇。 設定的方式類似 Approvals，只需要先將選項設為 Enabled即可啟動(下圖A)，接下來就是設定要作為Gate的機制(下圖B)： 按下Add之後，你可以選擇要作為Gate的機制： 系統已經內建不少的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)更是合作上版前的自動化關卡檢查機制。 來，以後試著放棄橡皮圖章吧。 參考資料