哈囉，大家好！歡迎來到我們系列文的第三階段！

在過去的十天裡，我們已經徹底征服了 Kubernetes 的核心。從一個 Pod 開始，到部署 Deployment、建立 Service，再到管理設定 (ConfigMap/Secret)、儲存 (PVC)、流量 (Ingress)，最後還學會了用 Helm 將它們打包。

現在，我們已經擁有了一套手動在 K8s 中部署、管理、升級應用的完整能力。

但，你心中可能已經浮現出一個巨大的不滿足：「這個流程還是太『手動』了！」

今天，我們就要正式進入 DevOps 的世界，學習如何將這一切串連成一條自動化的生產線，認識現代軟體開發的標準配備 —— CI/CD。

Part 1：CI/CD 出現前的世界：人工部署的惡夢

在解釋 CI/CD 是什麼之前，我們先來想一下，如果沒有自動化，一個「發布新版本」的完整流程會是什麼樣子：

1. 開發者：在本機修改完程式碼，執行 git push 推送到 GitLab。
2. 人工拉取：維運人員（或開發者自己）需要 SSH 登入一台建置主機，git pull 最新的程式碼。
3. 人工測試：手動執行單元測試、整合測試，確保程式碼沒有問題。
4. 人工建置 Image：手動執行 docker build -t ota-backend:1.1 .。
5. 人工推送 Image：手動執行 docker push your-registry/ota-backend:1.1。
6. 人工修改 YAML：打開 deployment.yaml，手動將 image 的 tag 從 1.0 改成 1.1。
7. 人工部署：最後，手動執行 kubectl apply -f deployment.yaml。

這個流程不僅極度耗時，更充滿了人為失誤的風險：忘記跑測試、打錯 Image Tag、apply 到錯誤的環境... 每一個環節都可能導致生產環境的災難。

我們需要一個系統，來將這些重複、繁瑣、且容易出錯的步驟，全部自動化。這就是使用 CI/CD 的原因。

Part 2：什麼是 CI (Continuous Integration)？

CI (持續整合) 關注的是開發流程的前半段：從程式碼提交，到產出一個可部署的軟體成品。

它的核心思想是：讓開發者頻繁地、自動地將他們寫的程式碼，整合到一個共享的程式碼倉庫（例如 GitLab）的主分支上。

每當有新的程式碼被推送時，CI 伺服器就會自動觸發一連串的動作：

1. 自動化建置 (Automated Build)：自動拉取最新的程式碼，並嘗試將其編譯或建置成一個可執行的檔案。
2. 自動化測試 (Automated Test)：在建置成功後，自動執行所有預先寫好的測試案例（單元測試、整合測試等）。

CI 的最大好處是**「提早發現問題」**。如果有人提交的程式碼破壞了建置，或導致測試失敗，整個團隊會在幾分鐘內就收到通知，而不是等到幾天、甚至幾週後，才在整合階段發現一個難以追蹤的 Bug。

Part 3：什麼是 CD (Continuous Delivery/Deployment)？

CD 則是 CI 流程的延伸，它關注的是後半段：如何將通過測試的軟體成品，安全、快速地交付到使用者手中。

CD 又可以細分為兩個層次：

1. 持續交付 (Continuous Delivery)：
   • 流程：在 CI 成功產出一個可部署的成品（例如一個 Docker Image）後，自動將這個成品部署到一個類似生產的環境（例如 staging 或 UAT 環境）。
   • 關鍵點：部署到最終的生產環境那一步，是需要人工點擊一個按鈕來批准的。這提供了一個最後的、業務層面的決策機會。
2. 持續部署 (Continuous Deployment)：
   • 流程：這是自動化的最高境界。一旦程式碼通過了所有 CI 階段的自動化測試，它就會直接、自動地被部署到生產環境，完全沒有人工介入。
   • 關鍵點：這需要團隊對其自動化測試有極高的信心。

Part 4：我們的武器：GitLab CI/CD

市面上有許多 CI/CD 工具（例如 Jenkins, CircleCI），而在我們的系列文中，我們將聚焦於與 GitLab 深度整合的 GitLab CI/CD。

它的運作，主要圍繞著兩個核心元件：

1. .gitlab-ci.yml 檔案：
   • 這是 CI/CD 流程的**「劇本」或「設定藍圖」**。
   • 我們會在專案的根目錄下，建立一個名為 .gitlab-ci.yml 的檔案。
   • 在這個檔案中，我們會用 YAML 語法，宣告式地定義整個 CI/CD 的所有階段 (Stages) 和任務 (Jobs)。例如，「test 階段包含一個 unit-test 的任務」、「build 階段包含一個 build-image 的任務」。
2. GitLab Runner：
   • 如果說 .gitlab-ci.yml 是「劇本」，那麼 GitLab Runner 就是負責執行這個劇本的「工人」。
   • GitLab Runner 是一個獨立的應用程式，我們會將它安裝在某個地方（可以是 VM，也可以是我們的 K8s 叢集）。
   • 它會向 GitLab 主機註冊自己，然後不斷地輪詢：「嘿！有沒有新的任務要我做？」
   • 一旦有開發者推送程式碼，觸發了 CI/CD 流程，GitLab 主機就會從 .gitlab-ci.yml 中讀取任務，並將其分派給一個空閒的 GitLab Runner 來執行。

結論

今天，我們從「人工部署的惡夢」出發，理解了 CI/CD 為何能成為現代軟體開發的標準配備。

• CI (持續整合)：透過自動化建置與測試，讓我們能提早發現問題。
• CD (持續交付/部署)：將通過測試的成品，自動化地部署到各個環境，讓我們能更快地交付價值。
• GitLab CI/CD：透過一份 .gitlab-ci.yml 劇本，和一個或多個 GitLab Runner 工人，來實現這整套自動化流程。

在明天的文章中，我們就要在我們的 Kubernetes 叢集中，設定並註冊一個可以動態擴展的 GitLab Runner**！明天見！