AWS CI/CD 核心三劍客：CodePipeline、CodeBuild、CodeDeploy 深入解析

當你想在 AWS 上實現一套自動化部署流程，CodePipeline、CodeBuild、CodeDeploy 是不可或缺的三大核心工具。

這三者分工明確，分別負責流程控制、建置執行與實際部署，能幫助你打造一條從程式碼變更到線上部署的全自動流水線。

本文將帶你深入理解它們的角色定位、執行流程與實作要點，並介紹常見的設定技巧與排錯方法，幫助你順利啟動 AWS 的 CI/CD 實務應用。

為什麼這三個服務是 CI/CD 的核心？

在 AWS 平台上實作 CI/CD（持續整合與持續部署），最常見的做法就是將整個流程拆成三個階段：控制流程 → 執行建置 → 完成部署。

而 AWS 提供的三大服務 —— CodePipeline、CodeBuild、CodeDeploy，正好對應這三個階段，構成一條標準、模組化的自動化部署流水線。

這三個服務彼此獨立，卻又能無縫整合，構成一個穩定、可擴充的自動化系統。

以下是它們各自的功能定位與常見用途：

為什麼不是只有一個工具就能完成？

許多新手可能會好奇：「為什麼 AWS 不把這三個功能做成一個工具就好？」

原因是 模組化設計可以提高彈性與可維護性。

你可以只用 CodeBuild 來執行單元測試，也可以單獨使用 CodeDeploy 搭配 GitHub Actions 完成部署。

這樣的架構讓開發者可以依照自己的專案需求，自由組裝、擴充或替換任一階段的服務。

串接示意圖

以下是這三個服務在實際 CI/CD 流程中的串接方式：

flowchart TD
    A[CodeCommit / GitHub] --> B[CodePipeline]
    B --> |控制整個流程，定義各階段| C[CodeBuild]
    C --> |執行建置與測試腳本，產出部署檔案| D[CodeDeploy]
    D --> |將產物部署至 EC2 / ECS / Lambda 等運行環境| E[運行環境]

CodePipeline 是什麼？負責什麼階段？

基本概念：CI/CD 的流程大總管

AWS CodePipeline 是一個「流程導向」的 CI/CD 管理服務，負責掌控整條自動化部署流程的每個步驟。

它就像一位導演，負責安排什麼階段該做什麼事、誰要來執行、做完要不要繼續下一個階段。

透過 CodePipeline，你可以：

• 設定當程式碼有異動時，自動觸發部署流程（例如 commit 到 GitHub）
• 定義每個階段的行為（建置、測試、部署等）
• 串接多個 AWS 服務或外部工具（如 Jenkins）
• 可視化整個流程，每個階段成功與否都能追蹤與除錯

📌 重點：CodePipeline 不負責實際建置或部署，它只負責安排流程。
實際執行建置的是 CodeBuild，負責部署的是 CodeDeploy。

流程架構：由多個 Stage（階段）與 Action（動作）組成

在 AWS CodePipeline 中，一條完整的部署流程會被切分為數個 Stage（階段），而每個 Stage 之下會包含一或多個 Action（動作）。

這樣的架構就像一條裝配線，從上游的程式碼變更開始，經過一連串處理之後，最終完成部署。

每個 Stage 都是流程中的一個「大步驟」，而 Stage 裡的 Action 則是具體執行「某件事」的小單位。

例如在建置階段中，可以包含兩個 Action：一個負責安裝套件，一個負責打包專案。

🧠 重點原則：

• 每個 Stage 的 Action 全部成功後，才會進入下一個 Stage。
• Stage 可以平行多 Action，但整個 Stage 是依序執行（上到下）。

🧩 常見的三個核心階段（Stage）

在大多數 CI/CD 流程中，以下三個階段是最基礎、也最常見的：

🧰 進階應用：自訂 Stage 與流程延伸

除了基本的 Source → Build → Deploy 三階段流程外，你也可以加入其他自定義的階段，以滿足更嚴謹的軟體交付需求：

這樣的彈性設計可以讓 CodePipeline 既適合敏捷開發中的快速迭代，也能支援大型企業對風險控管與品質保證的需求。

支援來源與目的地工具一覽：高度整合與彈性擴充

CodePipeline 最大的優勢之一，就是它具備良好的開放性 —— 能無縫整合 AWS 原生服務，也支援外部 DevOps 工具與自訂行為。你不需要被 AWS 限制，而是可以根據你的開發環境自由組合。

💡 進階技巧：

• 如果你使用的是非 AWS 的工具（如 GitLab CI、Bitbucket、DockerHub 等），也可以透過 webhook 或 AWS Lambda 進行整合。
• 想加入通知、報告、審核等功能，也能透過 Action Type: Invoke 搭配 Lambda 來實現。

實作小舉例：一條簡單的三階段 Pipeline

以「部署一個 React 網站到 S3」為例：

1. Source Stage：監聽 GitHub 專案是否有 push（分支為 main）
2. Build Stage：使用 CodeBuild 執行 npm install → npm run build → 輸出到 build/
3. Deploy Stage：把 build/ 內容部署到指定的 S3 靜態網站桶

整個流程都不需要手動操作，CodePipeline 會自動協調每一個階段，從檔案變動到完成部署，皆自動執行。

CodeBuild 是什麼？怎麼建構程式？

基本概念：CI/CD 流程中的建置與測試執行器

AWS CodeBuild 是一個由 AWS 提供的完全代管式建置服務（Build Service），專門負責在 CI/CD 流程中自動化完成以下工作：

• 安裝依賴套件（如 npm、pip、composer 等）
• 編譯程式碼（如 TypeScript → JavaScript、Java → Bytecode）
• 執行測試（單元測試、自動化測試）
• 打包並產出部署用的檔案（Artifact）
• 上傳成果至 S3 或交由後續階段（如 CodeDeploy）使用

你無需自行建立建置伺服器，也不需維護執行環境，只要提供一份設定檔，它就能在乾淨的容器中完成整個建置流程。

CodeBuild 的運作基礎：buildspec.yml

CodeBuild 的工作內容，來自於你在專案根目錄提供的 buildspec.yml 檔案。

這是一份 YAML 格式的指令腳本，定義了每一階段要執行的動作。

📌 重點是：你不需要在 CodeBuild 控制台逐行輸入命令，而是寫在 buildspec.yml 裡，讓 CodeBuild 自動讀取與執行。

buildspec.yml 範例與解析

以下是一個典型用於建置 React 網站的範例：

version: 0.2  # 目前版本建議使用 0.2

phases:
  install:
    runtime-versions:
      nodejs: 16
    commands:
      - echo Installing dependencies...
      - npm install

  build:
    commands:
      - echo Build started on `date`
      - npm run build

artifacts:
  files:
    - dist/**/*  # 將打包好的網站檔案輸出，供部署用

說明重點：

• phases: 定義各階段的動作，常見階段有 install、pre_build、build、post_build
• runtime-versions: 指定所需語言的版本（如 Node.js 16）
• commands: 實際要在每階段執行的命令
• artifacts: 定義要打包輸出的檔案（會上傳到指定位置供後續使用）

💡 可以想像 buildspec.yml 就像是在本地機執行一段 shell script，不過由 AWS 容器代勞，乾淨、快速、可追蹤。

CodeBuild 的常見功能與優勢

常見實際應用情境

除錯與日誌追蹤

CodeBuild 每次執行都會自動產生詳細的建置日誌，可在 AWS Console 的 Build history 中查閱。

你可以逐行檢查哪個指令失敗，甚至支援導出 CloudWatch Logs 以便進一步監控與警示。

CodeDeploy 是什麼？如何自動部署？

基本概念：部署流程的最後一哩路

AWS CodeDeploy 是一個由 AWS 提供的自動部署服務，主要負責將建置完成的應用程式「部署」到指定的執行環境中。

你可以把它想像成負責「把東西放上伺服器、啟動程式」的工具，是 CI/CD 流程中不可或缺的最後一環。

與 CodePipeline 和 CodeBuild 一樣，CodeDeploy 是一項全託管服務，不需要自己維護部署腳本執行器或遠端登入主機操作。

它可根據你定義的部署邏輯，穩定地將應用程式部署至雲端或本地環境。

支援的部署目標（環境類型）

✅ CodeDeploy 特別適合想要：可控部署節奏、支援多環境、流程自動化、具備回滾機制 的情境。

CodeDeploy 的工作原理

CodeDeploy 的部署邏輯是根據你提供的設定檔來執行 —— 也就是專案根目錄下的 appspec.yml。

整體流程如下：

1. CodePipeline 或其他流程工具將 artifact（應用程式檔案）交給 CodeDeploy
2. CodeDeploy 將 artifact 傳送至部署目標（如 EC2 實例）
3. 根據 appspec.yml 的內容，執行部署與腳本指令（如解壓縮、安裝、重啟）
4. 可追蹤每一個階段是否成功，如失敗可自動或手動中止或回滾

💡 CodeDeploy 並不會決定如何部署，而是執行你所定義的部署步驟。

appspec.yml 範例與解析（以 EC2 為例）

version: 0.0
os: linux

files:
  - source: /
    destination: /home/ec2-user/app

hooks:
  AfterInstall:
    - location: scripts/install.sh
      timeout: 300
      runas: ec2-user

🧩 結構說明：

📜 常見的 Hook 階段（以 EC2 為例）：

部署策略與版本控管（進階應用）

CodeDeploy 提供多種部署策略，讓你更靈活控制新版本上線節奏，降低風險：

這讓你可以實作：

• 分批部署（一批一批上）
• 手動審核（部署需通過審核才可推進）
• 自動回滾（失敗即還原至先前版本）

CodeDeploy 與 CI/CD 流程的關係

在一條完整的 AWS CI/CD Pipeline 中，CodeDeploy 負責：

1. 接收 CodeBuild 輸出的 artifact（透過 S3 傳遞）
2. 根據 appspec.yml 對目標實例進行部署
3. 通知 CodePipeline 是否成功完成部署階段

✅ CodeDeploy 不只整合 CodePipeline，也能單獨搭配 Jenkins、GitHub Actions、CLI 使用，具備高彈性與擴充性。

三者之間如何串接？

在實作 AWS CI/CD 流程時，CodePipeline、CodeBuild、CodeDeploy 三者並不是各自為政，而是能自然地串接起來，形成一條 從程式碼提交到自動部署完成的完整自動化流水線。

你可以這樣理解：

• CodePipeline 是「流程指揮官」，掌握每一個階段的執行順序
• CodeBuild 是「建置職人」，負責實際編譯、測試、打包應用程式
• CodeDeploy 是「部署工程師」，負責把產出的應用部署到真正的伺服器環境中

這三個角色環環相扣，缺一不可。

串接流程詳解（四大步驟）

以下是一條從原始碼提交開始，到部署完成的典型 AWS CI/CD 流程，每一步都由三劍客分工合作：

1️⃣ CodePipeline 啟動流程（通常由 Push 觸發）

當開發者在 GitHub 或 CodeCommit 進行 Push / Merge / PR 合併 等操作後，CodePipeline 會偵測到程式碼變更，並啟動整條流水線。

這個動作發生在 Source Stage，是整條 CI/CD 的起點。

來源可以是 GitHub、CodeCommit、S3 等支援的 Source Provider。

2️⃣ CodeBuild 執行建置腳本並產出 Artifact

進入 Build Stage 後，CodePipeline 會呼叫 CodeBuild，讓它依照 buildspec.yml 的指令來：

• 安裝依賴套件
• 編譯 / 打包應用程式
• 執行測試
• 輸出部署用的檔案（Artifact）

產出的 Artifact 會被暫存起來，作為下一階段部署的輸入物。你可以選擇上傳至 S3，或讓 CodePipeline 直接在記憶體內傳遞給 CodeDeploy。

3️⃣ 傳遞 Artifact 給 CodeDeploy

CodePipeline 將 CodeBuild 的輸出傳遞給 CodeDeploy，這時會進入 Deploy Stage。你可以：

• 設定目標為 EC2 / ECS / Lambda
• 指定 Artifact 存放位置（通常是某個 S3 Bucket）
• 搭配 appspec.yml 決定如何部署與是否執行腳本

📦 若你使用 EC2 部署，CodeDeploy agent 會將 Artifact 下載到本機，並依照 appspec.yml 內定義的階段（BeforeInstall、AfterInstall 等）依序執行部署流程。

4️⃣ CodeDeploy 執行部署與回報結果

最後一步，CodeDeploy 會依據你事先定義的流程：

• 解壓與安裝應用程式
• 執行腳本（啟動服務、遷移資料、驗證健康狀態…）
• 完成部署，並回報狀態給 CodePipeline

CodePipeline 可以根據回報結果決定是否將整條流程標示為成功或失敗，也可以觸發後續行為（如通知、回滾、人工審核等）。

串接示意圖（邏輯流程圖）

flowchart TD
    A[開發者 Push 程式碼至 GitHub / CodeCommit] --> B[CodePipeline 啟動流程控制]
    B --> C[CodeBuild 執行建置任務]
    C --> D[產出 Artifact → 上傳 S3 或直接傳遞]
    D --> E[CodeDeploy 根據設定自動部署到 EC2/ECS/Lambda]
    E --> F[部署完成，回報 CodePipeline 成功 / 失敗]

實務小提醒

結語：掌握 AWS CI/CD 三劍客，就能啟動自動化部署！

這篇文章深入介紹了 CodePipeline、CodeBuild、CodeDeploy 三大服務的角色與使用方式，從架構理解到設定檔撰寫，讓你對 AWS 的 CI/CD 實作流程有了明確的掌握。

若你已了解這些核心工具，下一步可以探索更多進階服務與整合：

• CodeCommit – Git 儲存庫整合
• CodeArtifact – 建置產物倉儲與套件管理
• IAM Role / CloudWatch – 安全與監控支援