本文將於賽後同步刊登於筆者部落格
有興趣學習更多 Kubernetes/DevOps/Linux 相關的資源的讀者，歡迎前往閱讀
更多相關科技的技術分享，歡迎追蹤 矽谷牛的耕田筆記

過去幾天我們探討了關於 Pipeline 的架構， CI 過程中 Kubernetes 的設計，以及 Yaml 相關的測試方式，今天這篇文章就來針對這些內容進行一些心得總結

一開始我們先用一張圖片來介紹可能的 pipeline 架構(此架構只是一個可能性，不是唯一，每個團隊需要運行的架構都不盡相同，沒有最好的架構只有最適合自己環境的架構)

這張架構中，我們首先要先選擇一套自己喜歡的 Pipeline 系統，這套系統可能是自架，也可能是 SaaS 服務，這中間的取捨條件非常多，

不論是成本考量，維護考量，擴充靈活性等，每個細項都需要團隊經過評估討論後決定

接下來於該 Pipeline 中我們會設定相關的 Job 來處理我們的工作，目前我們都只專注於 CI 方面的工作，因此上述的區塊都跟測試相關，

主要用來驗證與確保每次開發者的程式碼修正有通過團隊的一些測試要求。

這邊的架構其實非常多變，譬如 Git Repo 的設計，是否要將應用程式與 Yamls 放一起

1. 放一起的架構下，就變成整條 pipeine 的測試中要同時包含程式碼的測試，以及 Yaml 的測試，會比較類似上述的架構
2. 如果分開放，則有些測試就可以分開，譬如 Yaml Repo 就只需要針對 Yaml 進行測試，甚至配上一些整合測試確保部署後功能沒有問題。當然應用程式本身可以依靠程式語言的測試框架進行基本測試，接者搭配一些整合測試即可。

Yaml 測試方面前一天的文章有探討一些工具的使用與介紹，這些工具的用法與面向都不相同，甚至裡面要測試的檔案也不一定只有

Kubernetes 可以使用，所以多方測試總是會有幫助的

一切通過之後可以開始建置相關的 Container Image，並且準備將其送到測試用的 Kubernetes 叢集中，這邊要特別注意的環節就是

Image Tag 的處理。假設前述過程中產生的 Image Tag 是 5b1f94025b2，那後續測試的過程要有能力把這個 5b1f94025b2 給傳遞到

相關的 Yaml 裡面，這樣才可以確保 Kubernetes 內使用的是這個剛建置好的 Container Image.

如果使用的是 Helm 來部署的話，我們可以透過 --set image.tag=5b1f94025b2 之類的方式來修改 image tag，如果是使用原生的 Yaml 檔案，可能就要利用 sed 等指令來修改，這部分腳本的撰寫要特別小心。

當一切都測試完畢後就可以將最後的 Image Tag 給推上去成為一個經過測試認可的 Image。

那上述的流程有沒有哪些部分可以改善或是引入不同的工具來提升效率呢?

事實上是可以的，我們可以嘗試引入之前介紹過的本地開發工作 skaffold 來幫我們處理建置 Image 及將 Image 推到 Kubernetes 叢集內的這段過程，其架構如下。

於 Skaffold 的設定檔案中我們可以設定測試用的指令，將我們運行整合測試的指令整合進去，就可以把 Build Image 到測試這過程全部

讓 Skaffold 來搞定，同時藉由 Skaffold 的幫忙，我們就不需要自己去處理修改 Image Tag 的這個過程，一切讓 Skaffold 去修改對應的

image tag, 不論是 Helm, Kustomize 或是原生 Yaml 都能搞定。

結論來說，我認為現在一個簡單的 CI 流水線內其實會引入各式各樣的開源軟體來幫忙處理，每個軟體都有自己擅長與不擅長的地方，很

多時候就算找不到相關的開源軟體我們都可以秉持 給我一個 bash, 我給你全世界 的概念來自行處理。但是有時候要去思考一下到底現在

團隊最要緊的任務是什麼，哪個工作是公司最需要的，有時候架構上的完美不一定是商業上的完美，這部分的取捨往往需要一些溝通與協

調，來找到一個公司開心，工程師開心，大家開心的節奏。