情境
最近在公司開發一支稱為 Linter 的小程式,負責檢查 Bitbucket PR 的異動內容,看看是否有符合公司規範 ,例如 : 加了 Config 後是否有確實在對應環境補上相關設定,盡量避免這種編譯檢查不出來但上線才壞掉的情況。
原本預想的架構圖如上圖,使用者發了 PR ,透過 Webhook 觸發 Jenkins Master ,由 Master 安排一台機器去執行檢查。
但面臨一個問題是,當 Linter 這支程式要更版時變得很麻煩,因為每台 Jenkins 都必須要更新這支程式,原本也有想說不如把 Linter 獨立一台機器寫成類似像 API 的服務好了,但未來勢必面臨太多 PR 導致瓶頸,之後在導入 ELB 加多台機器 …. 想著想著就覺得太麻煩了。
之後同事建議可以包成 dotnet tool 的工具,Linter 要更新時只是發佈新版 Nuget ,而不是去佈署每台 Jenkins Slave,而 Jenkins Slave 每次要執行檢查 PR 時,先檢查自己套件是否為最新版的再往下執行。
整個流程瞬間變得簡單乾淨許多,所以就動手開始將這套程式包成 dotnet tool
製作 dotnet tool
首先將要包成 dotnet tool 的專案檔 csproj 加上 PackAsTool 設定
1 | <Project Sdk="Microsoft.NET.Sdk"> |
將執行檔打包成 nupkg
1 | dotnet pack -c release -o nupkg -p:PackageVersion=1.0.0 src\Linter.csproj |
推上 Nuget Server
1 | nuget.exe push src\nupkg\Linter.1.0.0.nupkg <Nuget Key> -source <Nuget Server> |
執行 dotnet tool
Install
1 | dotnet tool install --add-source <Nuget Server> -g Linter |
Update
1 | dotnet tool update -g --no-cache Linter |
接著就看你原本怎麼封裝 Cli ,直接執行即可
1 | Linter check -n ....... |
結語
第一次使用 dotnet tool 有驚豔到,以前都只會傻傻的用 console application ,每次都覺得部屬超麻煩,以後透過 dotnet tool 真的是方便多了