【2022鐵人賽】多專案命名規則與變數範本
我們前面會將大部份的YAML設計都改成範本的主要原因就是為了大部份的內容可以重複使用，並且在需要調整需修改的時 … 閱讀全文
鳴人
【2022鐵人賽】進階版-建立CI Pipeline
這一篇的標題雖然和前面的「基本版-建立CI Pipeline(1)」有點像，但是並不是打算相同的內容再來一次， … 閱讀全文
【2022鐵人賽】使用Task與CLI的抉擇
透過CLI就是組Scripts來達成目的，所以彈性相對高很多。除了可以Build Source Code之外，要Pack Nuget Package也是同樣透過Sdk CLI就可以達成。但是如果是用Task的話，可能就會需要分成不同的Task。
【2022鐵人賽】不同.Net Docker Image共用Dockerfile
.Net的Docker Image裡面我們是使用dotnet指令加上要執行的DLL檔名去啟動，但是在多個不同的專案就會有不同的DLL檔名，原本在Dockerfile裡面是寫死固定的DLL檔名，這篇透過使用ARG和ENV的方式讓.Net使用的Dockerfile也只需要一份公版範本。
【2022鐵人賽】設計Stage範本
除了step和job可以改成範本設計之外，stage也能夠設計成範本。不過stage和job兩者設計成範本的差異並不大，主要在於stage預設是依序執行，並且在手動觸發Pipeline的畫面可以選擇哪些項目不執行，而Job要依序執行則需設定dependsOn屬性，並且無法從畫面選擇哪些不執行。
【2022鐵人賽】CloudRun環境變數檔與多個Git Repo
CloudRun的環境變數在gcloud sdk的指令中，除了可以直接在指令中設定之外，也可以讓它去讀取環境變數的檔案，就不會讓指令變得又臭又長。不僅如此，將YAML設計成範本提供給多個不同的專案使用，也可以切分出共用的環境變數與專案專用的環境變數，執行時再把內容合併成一個檔案。
【2022鐵人賽】拆解BuildImage Job成為job範本
前面BuildCode的Job中規中矩的拆解成了job template，這一篇繼續來拆解BuildImage的Job。不過在這篇拆解的過程中，使用到了條件判斷與函數，透過傳入的參數值不同而有不同的執行步驟與結果，讓範本更能夠因應不同的使用情境有所彈性。
【2022鐵人賽】BuildCode YAML拆解task為step範本
前一篇「初探YAML的範本(Template)設計」，我們快速的將原本CI Pipeline中的BuildCo … 閱讀全文
【2022鐵人賽】初探YAML的範本(Template)設計
要把現有的YAML內容改為template設定並不困難，概念上就是拆分不同的檔案內容，在主要的Pipeline中再透過template關鍵字進行範本的引用，透過@符號來決定引用的是在resources底下的哪一個repository。
【2022鐵人賽】認識Pipeline的參數(Parameters)與變數(Variables)
昨天的文章提到了運算式與函數，今天我們來看看另一個跟變數(variables)很像的東西：參數(paramet … 閱讀全文