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

昨天我們介紹了本地開發的一個開源工具， Skaffold，如何透過 Skaffold 來提升本地開發的效率

根據我們一開始展現的 CI/CD 世界圖，我們已經探索完畢 Local Developement Environment 的相關議題

接下來我們要來探討 CI/CD Pipline 的設計，這部分牽扯到諸多議題，第一個最基本的問題就是, Pipeline 系統要選擇哪一套

目前開源軟體超級多，選擇上其實非常困難，譬如有 GitLab, Jenkins, CircleCI, TravisCI, TeamCity, GithubAction...等

所以今天這個章節，我們就來聊聊有哪些 Pipeline 系統可以使用，以及在選擇上有哪些點可以考慮

我認為在選擇上，有一些可以考慮

1. 服務的部署模式，是自架部署還是使用 SaaS 服務
2. 該系統有哪些吸引人的特色

接下來我們就來看看這幾點中有什麼細節可以討論

部署模式

部署模式上基本上就是兩大塊，自架服務或是SaaS服務，這兩種類型我認為他們的好壞優點有

自架服務

優點:

1. 彈性，擴展性佳，可以根據各種需求去修正，甚至有機會透過修改原始碼來滿足客製化需求
2. 使用上限制比較少

缺點:

1. 要自己維護伺服器，包含了運算資源，儲存資源，網路資源甚至可能連硬體都要處理。

2. 第三方整合不一定有，需要自己研究跟處理，甚至還要自己撰寫程式碼來完成

3. 發現問題時不一定有太多支援可以尋求，會變成要花更多時間在處理這些問題而非賺錢的商業邏輯

SaaS

優點:

1. 使用起來簡單，不用擔心底層基礎架設，譬如硬體資源，網路資源，儲存資源以及運算資源
2. 付費情況下會有比較好的支援服務可以尋求，發生問題時可以讓對方幫忙處理

缺點:

1. 限制多，需要花更多的錢來獲得更好的服務與使用條件
2. 支援的平台與支援的語言完全受限於廠商，沒有辦法擴充
3. 彈性與擴充性比較低，一切都依賴廠商去開發

大部分的 SaaS 都會提供免費版本的功能讓使用者使用，但是部分功能都會有所限制，想要解除這些限制就要付費，透過付錢來取得更好的使用品質，至些功能可能有

1. 可以有多少個並行的工作
2. 一段時間內可以跑多少時間的工作，譬如每個月只能跑 10 小時的工作
3. 每個 job 能夠支援的 Timeout 上限
4. 支援哪些平台與機器類型，譬如是否可以支援 Docker 或是 VM, 平台除了常見的 Linux 之外是否也支援 Winodws/OSX/iOS/Andorid 等平台。

此外，對於這些 Piepline 系統來說，自架跟 SaaS 並不是二擇一，很多情況下，這些系統除了提供 SaaS 的服務外，也有提供自架服務

這種情況下就可以讓使用者決定到底要使用自架服務或是 SaaS，譬如先透過 SaaS 去使用評估看看，覺得喜歡看考慮自架或是反過來

一開始先自架來用看看，如果喜歡但是覺得維護麻煩，覺得改用 SaaS 更可以省時省力。

特色

每個不同的 Piepline 系統都會有不同的特性，這些特性不一定每個環境都需要，所以選擇上還是根據自己的需求去選擇

我個人的經驗下，可能會有這些特性(包含但不侷限)

1. 通知系統。當工作成功或是失敗的時候，能不能把這些結果通知出去，讓管理員有辦法被動知道這些工作的結果

2. 專案的追蹤與問題管理，譬如是否該系統能夠把這些每個工作都跟一些 Issue Tracking 整合，譬如 Jira

3. 使用者權限整合，是否可以跟已知常用的系統整合，譬如 LDAP/Windows AD/Google Suite/Crowd/OpenID

4. 流水線的工作內容是否可以用程式碼的方式來保存，類似 Pipeline as a Code

5. 使用工具與閱覽工具有哪些，是否有好用的 UI 或是工具可以使用

6. 除錯與文件的完整性，使用上是否能夠找到詳細的文件來使用，發生問題時是否容易找到詢問的管道

7. Secret 這種機密資訊的管理與使用是否有支援，譬如 db password 等

要找到一套系統完全支持上述所有功能且都要好用穩定不會出錯其實不可能，最困難的還是去評估每個系統以及其特性，看看有哪些特性

是你們一定要有，哪些可以妥協不一定要有的

工具的選擇

就如同最上面所述的，市面上有非常多 Piepline 系統可以選擇，每個都有各自的優點與使用，接下來的文章為了讓整體操作簡單與順利，會採取使用 SaaS 服務的 Piepline 系統，並且基於免費版本來使用

這些選擇中有 CircieCI, TravisCI 甚至是 Github 本身的 Github Action.

由於我們的專案都很習慣放在 GitHub 上，我們就來使用 GitHub Action 作為後續的操作環境!