概覽

怎麼樣的 CI/CD pipeline 才算 production-ready，而不只是能跑而已？這個專案透過實際打造一套來回答這個問題——用 Jenkins、Docker、SonarQube、Ansible 建構，以 Java Maven 專案為實作範例，由 GitHub 觸發，搭配 Discord 通知與 k6 smoke test。目標是移除 build 和 deploy 過程中手動、容易出錯的步驟（像是手動 SSH 進去跑 jar），同時保留一道人工審核，確保 build 上 production 前有人看過。

Pipeline 分成兩條獨立線。CI 專注在程式碼品質——跑測試、產生報告，只有通過 quality gate 才會 build artifact。CD 專注在部署——把 CI 已經測過的 artifact，經過人工審核後部署到選定環境，若 deploy 或部署後的 smoke test 失敗就自動 rollback。兩條 pipeline 結束後都會發送結果通知。

CI 特點

• Build 跑在 ephemeral 的 Docker 環境裡——每次都乾淨、可重現
• JUnit 5 + JaCoCo 跑測試、產生 coverage report，供後續檢視追蹤
• SonarQube 同時扮演 quality gate 的角色——檢查程式碼品質與資安漏洞
• 只有通過 quality gate 才會 build artifact（mvn package -DskipTests）——不重新編譯，compile 在測試階段已經 cache 過
• 通過的 artifact 會發布到 Nexus，成為有版本號的 jar

CD 特點

• 部署前先選定環境（dev/staging/prod）
• Supervisor approval gate——正式上 production 前的人工審核點
• 部署的就是 CI 已經測過的那個 jar，CD 這邊不重新 build
• Ansible 負責找到指定的 target host 並部署上去
• Rollback 機制確保服務可用性

為什麼要有 approval gate

全自動部署聽起來很吸引人，直到一個爛的 build 直接上了 production。Approval gate 是刻意的 speed/safety trade-off：CI 維持全自動（build、test、scan 都不用人碰），但 CD 保留一道人工審核，卡在正式流量會受影響之前——這是為了避免一個沒人看過的 build 就這樣上線，成本很低的保險。

為什麼 rollback 比 happy path 更重要

這個 pipeline 大部分的工程時間都花在 failure path，不是 happy path——build、deploy、done 誰都寫得出來。Smoke test 失敗自動 rollback，代表一個爛的 deploy 在 k6 發現問題的當下就自我修復，不用等人發現 alert 再手動回滾。

為什麼要在 packaging 前先測試

Packaging 不是免費的，需要時間，CI 跑的次數越多，這個成本就累積得越多。Quality gate 放在 packaging 之前，代表沒過的 build 根本不會走到那一步——不會浪費時間跟資源去 build 一個註定要被丟掉的 artifact。

延伸

Java 也可以打包成 native image，Quarkus 是其中一種做法。目前這個 pipeline 還是用 jar artifact，因為現在的部署環境就是吃這個格式。

---

← 返回專案列表