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 以上的版本即可。

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

熱門文章