《面試官別再問》什麼是持續整合、持續發佈（Continuous Integration & Continous Delivery） ?

為什麼我們需要 CI / CD ?
在比較小且快速的循環中，持續驗證系統開發結果 ，小部分小部分地儘早確認，期望開發產出能符合原始需求，或依據產出進行快速修正。 簡單來說就是儘量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。

CI的目的
降低風險。
減少人工手動的繁複程序。
可隨時產生一版可部署的版本。
增加系統透明度。
建立團隊信心。
什麼是持續性整合(CI)呢？持續性整合的目的為：針對軟體系統每個變動，能持續且自動地進行驗證。此驗證可能包含了：

建置 (build)
測試 (test)
程式碼分析 (source code analysis)
其他相關工作 (自動部署)
驗證完成後，進一步可以整合自動化發佈或部署 (Continuous Delivery / Continuous Deployment) 。透過此流程可以確保軟體品質，不會因為一個錯誤變動而產生錯誤結果或崩潰(Crash)。此流程中的各類工具，也會產生一些回饋給開發者或其他角色，包含網頁/報表等等，用來追蹤並改善軟體潛藏的問題。

工具的選擇
Jenkins
談到 CI，最廣為人知且老牌的工具是 Jenkins。Jenkins的功能完整，也提供了上千個外掛 (Plugins) 來對應各種開發語言與工具。Jenkins目前已發展到了 2.x 版，新版本中對於 Pipeline 概念及容器 (Container) 整合也趨於完整，是一套可以自訂運用的系統。但也因為其功能強大、客製程度高，上手需要一些時間。然而一旦流程被定義，並整合好相關環境，它可以發揮持續性整合威力，大幅增加開發生產力

Git — 版本管理
GitHub — 程式碼託管、審查
CircleCI — 自動化建置、測試、部署
Docker — 可攜式、輕量級的執行環境(使用 Docker，統一開發者、測試人員、以及產品的執行環境。)
AWS Elastic Beanstalk — 雲端平台
Slack — 團隊溝通、日誌、通知
建立 CI / CD 流程雛形

我們結合了 Git Flow + Protected Branch Flow 的開發流程，流程如下：

開發者 (Developer) 先開立 (create) 一個功能分支 (feature branch)。
開發者提交一個 Pull Request， SCM 系統會自動觸發 Jenkins 進行建置以及測試。這個觸發通常是經由 Webhook 來實現。
在軟體建置完成後，在 Jenkins 增加一個步驟來送出原碼掃瞄 (Code Scan) 的請求給 Sonarqube 系統。Sonarqube 則在完成程式碼掃瞄後將結果寫回 SCM 系統。
由於我們在 SCM 上連結了 Slack，每個步驟完成（成功或失敗）的通知便可以送到 Slack 群組。
原碼審核者 (Reviewer) 可以到 SCM 上查看這個Pull Request的相關訊息，搭配 Code Scan的結果決定是否將這個分支合併 (merge) 回主線(develop/master branch)。
分支合併可以觸發另一個 CI 工作，使 Jenkins 將主線建置後部署到測試環境提供給其他人員進行測試。

1. 流程中的關鍵環節補充

Plaintext

[ Feature Branch Commit ]
          │
          ▼
    [ Pull Request ] ──────────┐
          │ (Webhook)          │
          ▼                    ▼
   ┌──────────────┐     ┌──────────────┐
   │ Jenkins/CI   │     │  Sonarqube   │
   │ Build & Test │     │ Code Scan    │
   └──────┬───────┘     └──────┬───────┘
          │ Pass               │ Report
          └──────────┬─────────┘
                     ▼
          [ SCM Status Checks ]
                     │ (All Pass)
                     ▼
          [ Code Review & Merge ]
                     │
                     ▼
    [ Trigger Staging Deployment ]
                     │
                     ▼
             [ Slack Notification ]

① 機器驗證優先於人工 Review

在你的流程中，開發者發 PR 後先由 Jenkins + Sonarqube 自動跑單元測試與原碼掃描，只有所有自動化檢查 PASS 之後，審核者（Reviewer）才介入。這能極大化減少 Reviewer 的時間成本，避免人工花時間幫忙挑出「語法錯誤」或「測試沒過」的問題。

② 結合 Protection Rules (分支保護規則)

在 GitHub / GitLab 等 SCM 系統上，建議設定 Protected Branch：

• Status Checks Required：強制規定 Jenkins 測試與 Sonarqube 掃描結果必須為 SUCCESS，否則「Merge」按鈕為灰色、無法強制合併。
  
  
• Review Count：規定至少需要 1~2 位 Peer 開發者 Approve。
  
  

2. 工具鏈搭配的優缺點分析

你列出的工具組合（Jenkins + CircleCI + Docker + AWS + Slack + Sonarqube）是企業級非常成熟的架構，各工具定位明確：

工具 / 環節	角色與優勢	實務考量與注意事項
Jenkins	彈性極高、外掛豐富，適合複雜的在地化或混合雲環境	維護成本較高，需定期更新 Jenkins 主機與 Plugin 避免資安漏洞（或改用 Jenkins Pipeline as Code / Jenkinsfile）。
Docker	解決「在我電腦可以執行，線上不行」的環境一致性問題	CI 流程中可善用 Docker Cache，縮短 build image 與安裝套件的時間。
Sonarqube	針對 Code Smells, Bugs, Security Hotspots 設定 Quality Gate	建議為 PR 設定明確的阻斷標準（例如：新增程式碼覆蓋率 < 80% 或存在 High 級別資安漏洞時禁止 Merge）。
Slack Integration	建立可觀測性，團隊即時捕捉 Build 失敗狀況	避免過度通知（Notification Fatigue）。成功通知可導向專屬紀錄頻道或僅顯示摘要，失敗通知再 @提及 該 PR 提交者。

3. 漸進式演進建議

若未來想進一步強化這套 CI/CD 流程，可以考慮導入以下維度：

1. 環境變數與 Secrets 管理：確保 CI 工具在建置時，敏感資訊（AWS Keys, DB Passwords）從安全的機密管理工具（如 AWS Secrets Manager, Vault, 或 CI 原生 Secrets）注入，絕不寫死在 repo 中。
   
   
2. 資料庫 Migration 相容性策略：在自動部署到測試環境時，Migration 應設計為向後相容（Backward Compatible），確保系統在部署瞬間或需要 Rollback 時不會因 schema 異動而掛掉。
   
   
3. 動態測試環境（Preview Environments）：在 CI 流程中，有些團隊會在發 PR 時自動運用 Docker/Kubernetes 動態開一個獨立的 Preview 環境，供 QA 或 PM 直接驗證該分支功能，PR Close 時自動銷毀。