發表文章

目前顯示的是 4月, 2021的文章

如何在CI CD Pipeline中發送LINE通知訊息?

圖片
『如何在CI/CD Pipeline中發送LINE通知訊息?』有次,Azure DevOps上課時學員問了這個問題。 我聽到之後忍不住說:『這位同學你問得太好了!!!』 耐不住心中竊喜,繼續說道:『本人剛好有 30秒可達成的全球最佳 解決方案。😁』 要知道,關於LINE和Azure DevOps這兩個主題,分開來討論時我也向來是不落人後的,現在這兩個主題合在一起,那我當然就更不客氣了。 開啟Pipeline,我說『請看,第一個步驟,在pipeline中,加入『Use .net core』task: 接著,第二步,上 LINE Notify官網 ,建立一個發訊息給你自己(或群組)的LINE Notify Token: 你會取得一個長得像底下這樣的token: 3QrpcH5XauJVoFCoSxbuWJH747TkC7yW5aXfsDk7RsM 然後,第三步驟,在Pipeline中,加入一個PowerShell Task,在inline script中填入底下指令: dotnet tool install --global line.cli line notify -n 3QrpcH5XauJVoFCoSxbuWJH747TxC7yW5aXfsDk7RsM -m "$(Build.BuildNumber) is done. 狀態: $(Agent.JobStatus)" 然後? 然後就完成了。 現在,你可以自由的在上面這段script中發送訊息給自己(或自己的群組),當然還可以帶入環境變數$(…)。如此一來,每當CI build完成之後,不管成功或失敗,你都可以即時地取得通知,例如: 這一招,我們採用的是跨平台的 .net core,因此,不管你的build agent是MAC、Linux、還是Windows通通都支援啦😎。 相關課程: 敏捷開發專案管理與Azure DevOps實戰 https://www.studyhost.tw/NewCourses/ALM LINE Bot與人工智慧實戰 https://www.studyhost.tw/NewCourses/LineBot

透過持續改善縮短你的cycle time

圖片
底下這張圖,看起來頗有學問… 圖片來自MS Azure DevOps AZ-400-1 我們在上DevOps的課程時,第一件事就問同學:在這個大企業林立、變化迅速的時代,新創或台灣的小公司在充滿資源的全球大企業輾壓下,要如何存活? John Boyd的OODA循環帶給我們一個契機,如果你有興趣,可以google一下OODA循環,在wiki百科中的描述如下: OODA循環的理論,來自於美國空軍在韓戰中的經驗。 在韓戰中擔任戰鬥機飛行員的空軍上校約翰·博伊德(John Boyd)認為,美國空軍過於注重速度,在越戰的早期空戰中,這一點就已凸顯出來。而與之形成鮮明對比的是,過時的蘇聯製米格戰鬥機卻在戰場上如魚得水,原因是因為米格機相對容易操作。 在對於競爭型戰鬥機進行了一番詳細分析之後,博伊德的結論是,飛機在空戰中最 關鍵的性能並非絕對速度,而是敏捷度 。在混戰中反應能力最強的戰鬥機能夠繞到敵人身後,隨時準備置敵於死地。 博伊德將其想法總結形成「OODA理論」。 在如今真實世界的挑戰中也是, 最關鍵的性能並非『絕對速度』,而是『敏捷度』 。這是新創和科技公司在最近這20年屢屢戰勝的核心原因。即便大公司擁有更多的資源,但面對挑戰總是輸在自身遲緩的反應上… 因此,DevOps的核心工作,其實是『持續改善,並竭盡所能的縮短你的循環時間(Shorten your cycle time)』。 這些cycle time包含…你修復一個Bug所需要的時間(改善一個錯誤的時間)、你增加一個新功能所需要的時間(在市場上提供新服務的時間)、學習並應用一們新的技術所需要的時間… 而這些縮短且省下的時間,就是你持續改善的所得到的『價值(Value)』,也是企業贏的關鍵。你的『持續改善』(持續縮小cycle time)最終停留在哪一點,你企業(或個人)的限制(瓶頸)就在哪一點出現。 圖片來自MS Azure DevOps AZ-400-1 因此,DevOps追求的是持續改善、持續整合,透過不斷合併與測試,盡早發現缺陷,盡早改善,就是DevOps中CI(continuous integration)做的事情。 面對縮短cycle time的挑戰… 你能多快修復一個bug? 你能多快上版(當然得同時兼顧安全性與品質)? 新功能能夠多快交付到用戶手上? 新構想能夠多