the DevOps journey - 在VSTS CI(Continuous Integration)中發送Line通知

作者： -

需求很簡單，我們希望在VSTS的程式碼Code Check In(Code pushed)、Build Success/Fail、或是Work item發生了改變時，透過Line發送通知給特定人員(專案成員、PM…etc.)

會有這個需求很單純，我們希望通知(notification)更加即時，每當任何團隊成員簽入程式碼，或伺服器端的建置(Build)完成有結果之後，相關人員都能夠立即得到通知。過去，我們是用email，隨著各種IM肆無忌憚的入侵我們的生活，現在用推送訊息來通知也是很合理的…

在台灣，你不可能不用Line，幾乎沒有人能跟朋友說自己沒有Line帳號，因此，在VSTS CI (Continuous Integration)當中整入Line通知也是理所當然的。

怎麼做呢?

首先你可以在VSTS的Team Project的管理畫面中，找到Service Hooks，這是一個好用的功能，他可以幫你在該專案特定事件發生時，連結到外部系統並觸發某個動作：

如果你按下上圖的新增鈕，會發現其實已經很多外部系統可以連結了，例如大家很熟悉的Slack、Trello…，很不幸的，我們要發訊息的Line不在裡面:

但不要緊，你會發現我們可以透過Web Hook觸發一個http post，我們只要在該http post裡面來發送Line訊息即可。因此，我們在上圖中的畫面選擇Web Hook，接著按下Next，會出現下圖中的畫面，在該畫面上你可以選定Trigger，也就是，當哪一個事件發生時，要觸發http post來發送通知:

你會看到，選項中有Code Checked in(支援git版控的專案則會出現code pushed)，以及Build completed、WorkItem Created/Updated/Deleted…等觸發事件，請選擇你要的。

然後按下Next，接下來出現的Action畫面，你只需要輸入 URL即可，也就是您選定的事件發生時，要以Http post通知哪一個URL?

你可以自行設計一個可接受http post的WebAPI，並在其中發送Line訊息。如果你還不知道該怎麼設計，我們特別幫你做了一個，讓你可以嘗嘗鮮玩一玩。(其實是我們團隊自己要用的啦…)

請先保留上面這個畫面，別關閉。然後開啟另一個瀏覽器，輸入底下網址:
http://isbaas.azurewebsites.net/VSTSWebHook/default.aspx
將會出現底下畫面，這是一個VSTS WebHook URL產生器:

請依照上圖中的步驟，填妥上面該WebHook URL的用途，按下產生鈕，接著會看到上面產生出一串GUID(WebHook URL)，產生出GUID之後，請接著按下上圖(3)的按鈕，將會出現底下的Line登入畫面(這是Line的網頁，而非我們開發的網頁):

如果你還記得，我們前面曾介紹過的Line Notify機制，大概就知道我們準備在該WebHook中透過Line Notify來發訊息(而非用Line Bot)，上面的這個登入畫面，就是Line的OAuth機制，用來取得可透過Line Notify發訊息給用戶的Token。

請用您想要接收到訊息的Line帳號登入，按下Login之後會出現底下畫面，讓你確定你要用哪一個帳號(或群組)來接收通知:

請選定後按下Agree and connect，如果一切順利，接著會出現底下畫面:

請牢記上圖中藍色的URL，並將其複製到剛才我們做到一半的WebHook URL輸入畫面中貼上:

按下Finish之後就大功告成囉，你會發現，未來當您的Team Project剛才選定的Trigger發生時，你的Line就會收到來自Line Notify的通知:

你可以把剛才上面的藍色URL貼到多個WebHook Trigger中，這樣當相對的Trigger被觸發時，你剛才綁定的Line帳號都會以Line Notify收到VSTS傳來的通知。

如果除了你自己以外，你也想讓其他團隊成員也收到這些通知，你也可以把剛才的藍色URL分享給團隊成員，請他將該URL貼到瀏覽器上，會出現底下畫面，同樣的按下『訂閱上述WebHook』，並且綁定Line帳號，即可讓您的team member和您一樣，在事件觸發時收到Line Notify的通知訊息:

透過這個簡單的設定，你的VSTS CI Build/Check In(或WorkItem更新)都會即時的以Line通知您，如果有興趣的話就玩玩看囉。以後找時間，我再來介紹這是怎麼實現的…

免責聲明: 以上VSTS WebHook服務網址是我們為內部團隊自用所開發的服務，我們不對此服務進行任何瑕疵擔保。您的VSTS Action JSON資料將會經過此WebHook以及微軟Azure Web App雲端服務，並透過Line Notify機制傳送給予綁定該WebHook的Line帳號，但我們並不會收集和使用您的Action JSON資料。

留言

張貼留言

這個網誌中的熱門文章

原來使用 .net 寫個 MCP Server 如此簡單

作者： -
圖片
MCP 的重要性與意義 MCP 的重要性在於它建立了一個標準化的架構，讓開發者能夠快速建構出給 AI Agent 呼叫的各種功能。 舉例來說，假設我們希望實現一個 可以透過自然語言對談的請假功能 ，傳統上我們必須建立一個前端 Chat Bot 作為 UI、還得撰寫後端 API、資料驗證邏輯、資料庫存取介面…等，另外還要設計 Chat Bot 的對話邏輯，才能把請假功能整合到Chat Bot的對談訊息中。 但在 MCP 的架構下，這樣的流程可以大幅簡化。 開發者只需要實作幾個「請假功能」的介面（Tool Interface），接著定義好運行這個功能需要輸入哪些參數（例如請假人、開始時間、代理人、事由…etc.），並透過 JSON 來描述這些參數的格式與驗證邏輯。接著，AI Agent 便可以在對話過程中，自動根據對談前後文理解使用者意圖，挑選出適合的Tool來運行，主動發出呼叫的請求。如此一來，大幅簡化了AI Agent開發的難度。(本質上就是 Function Calling 的概念) 而 .net 又把這個難度降低到人人可以開發的程度，底下是一個使用 .net 開發的 請假功能 MCP Server，並且使用 GitHub Copilot來呼叫的例子： 其實我之前用 Semantic Kernel做個類似的範例，只是如今 .net 讓它變得更簡單，而且輕易地可以透過MCP架構讓不同的 MCP Client端呼叫使用。 如何用 .NET 撰寫 MCP Server 要使用 .NET 撰寫 MCP Server 非常簡單，受益於 Microsoft.Extensions.Hosting 和 ModelContextProtocol 套件，我們可以在幾分鐘內輕鬆地實作 MCP Tool 和 MCP Server 。 以下是MCP Server的完整程式碼： using Microsoft . Extensions . DependencyInjection ; using Microsoft . Extensions . Hosting ; using Microsoft . Extensions . Logging ; using ModelContextProtocol . Server ; using System ...
Read more »

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

在VS Code當中使用 Azure DevOps MCP Server

作者： -
圖片
來看看這張圖發生了什麼事情? 沒錯，我們正在VS Code當中，使用 GitHub Copilot Agent Mode，透過自然語言的方式，查詢Azure DevOps中的工作項(WorkItems)。 其實，不僅僅可以查詢，也可以檢視細節、甚至新增、修改。範圍也不只有 WorkItems ，還包含 Pipeline 的觸發、PR的建立或PR Comment的新增…等，全部都可以透過自然語言來進行。 而這些，全都拜MCP所賜。 關於MCP 你大概聽說過 MCP，它是 Anthropic 提出的一套開放式標準協議（Model Context Protocol） ，旨在讓大型語言模型（LLMs）可以安全、模組化、可擴充地存取外部工具和資料來源。 簡單來說，你可以把 MCP 想像成 AI 世界中自然語言對談機器人對外的接口，像是我們寫程式的時候，可以透過 API 來串接外部系統， MCP 就是大語言模型對外「運行指令與資料交換」的標準協議 。 不同的是，傳統 API 是設計給 開發者 來用的，強調結構化資料、明確定義與嚴謹的格式；但 MCP 是設計 給大語言模型用 的，它理解自然語言、懂語意、會參考上下文。MCP 的設計讓模型能夠和用戶在以「對話的方式」溝通時，依照用戶的命令與外部系統互動，但底層其實還是透過 function calling 的概念與結構化的 JSON 交換資料，只是這一切都被封裝得更自然、更貼近人類使用者的自然語言。 如同上面你看到的，大語言模型透過 MCP，可以自動呼叫 Azure DevOps 系統的API，查詢資料、比對欄位、下指令修改狀態，整個流程就像是你請了一位懂 DevOps、又能聽懂人話的數位助理。 底下是新增一個 bug 單的例子： 這正是 MCP 的魔力： 讓大語言模型從資訊生成者，進化為任務執行者 。這背後不只是一個協議，而 是未來開發體驗的轉變 。未來開發者不再只寫程式，而是設計如何與 AI 協作；工作流程不再只是「使用工具」，而是「 與工具對話 」。 如何實現? 作法比想像的簡單超級多，由於最新版的 VS Code 和 GitHub Copilot 已經支援 MCP，所以你只需要確認你是在 Agent Mode(下圖一)，然後在專案工作區的 .vscode 資料夾中，置入一個 mcp.json 檔案...
Read more »

原來使用 .net 寫個 MCP Client 也如此簡單

作者： -
圖片
之前我發了一篇文章，標題是「原來使用 .NET 寫一個 MCP Server 如此簡單」。結果有不少朋友留言敲碗，說：「只有 Server，沒有 Client，這怎麼行？」 呃…我只能說，這個要求顯然 很有道理 。🙄 所以今天趁上課的空檔，補一篇文，來介紹如何撰寫 MCP Client ，把整個架構補齊。 你會發現，其實，開發 MCP Client 也非常簡單耶。 MCP 架構的本質 不過，在開始之前，有一個觀念需要釐清：無論是 MCP Server 或 MCP Client，其實都與 LLM（大型語言模型）沒有 直接關聯 ，這和很多人理解的不同。 MCP 架構的本質，只是為了讓 AI Agent（或 Chat Bot）更容易知道怎麼呼叫外部的服務提供者(就叫做MCP Server)，並且能方便地列舉出這些服務所提供的功能(就叫做MCP Server Tool)，以及清楚了解每個功能呼叫時所需的參數。某種程度上，它的角色有點類似早期 Web Service 時代的 WSDL/SOAP ，或是現代 REST API 架構中的 Swagger/OpenAPI 👉👉 都是用來提供一種 標準化的服務描述與呼叫方式 ，使服務整合變得更一致、更具可預測性。 至於， 什麼時候該呼叫哪一個功能 、呼叫時所要填入的具體參數 值 是什麼，這些判斷與決策的工作，才是由 AI(LLM) 來處理的。而真正去執行這些呼叫動作的，則是 AI Agent(或者稱之為，MCP Host)。 簡單的說就是，對談機器人(或AI Agent)可以藉由 LLM 來呼叫遠端的服務，而 MCP 架構則讓對談機器人可以得知有哪些服務可供呼叫，並且在呼叫時應該要傳入哪些參數。 因此，要開發一個能夠呼叫 MCP Server 服務的 Client 端，自然也需要建立一個具備決策與執行能力的 AI Agent。 這部分，我們待會會採用 Semantic Kernel 作為實作的基礎框架。 之前我們 早已介紹過 Semantic Kernel ，它不僅可以介接各種 大語言模型（像是 OpenAI 或 Azure OpenAI），還能彈性地設計與掛上各種 skills 與 plugins ，非常適合用來打造具備「對談 → 意圖理解 → 功能選擇 → 發出呼叫」這一整套流程的AI Agen...
Read more »