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

Facebook LinkedIn Tweet

更新日期： 2025 年 6 月 9 日

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

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

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

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

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

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

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

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

工具	角色定位	常見用途
CodePipeline	流程控制中心	定義 CI/CD 的完整流程（來源、建置、測試、部署），控制每個階段的觸發與執行順序
CodeBuild	建置與測試引擎	在乾淨、安全的執行環境中進行程式碼建置、單元測試、靜態分析、打包 Artifact
CodeDeploy	自動部署引擎	將打包好的應用程式部署至目標環境，如 EC2、ECS、Lambda，並支援藍綠部署、漸進部署等策略

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

許多新手可能會好奇：「為什麼 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 流程中，以下三個階段是最基礎、也最常見的：

階段名稱	功能說明
Source Stage	負責「監控原始碼變更」並觸發整條流程，常見來源如 GitHub、CodeCommit、S3 等。當程式碼有 push、merge、上傳等事件時，自動啟動流水線。
Build Stage	負責「建置與測試」，通常會交由 CodeBuild 或 Jenkins 執行。這階段可能會執行 npm install、npm run build、單元測試或程式碼靜態分析等工作。
Deploy Stage	將建置完成的產物自動部署到執行環境中（如 EC2、ECS、Lambda）。這階段常透過 CodeDeploy 或 CloudFormation 來操作。

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

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

自訂階段	用途範例
Test Stage	執行自動化測試、UI 測試、API 測試、整合測試等。
Security Scan	使用工具（如 SonarQube、Checkmarx）進行程式碼弱點掃描。
Approval Stage	加入人工審核（需點擊批准按鈕）後才能進入下一階段，常見於正式環境前。
Notification	傳送 Slack、Email 通知或自訂 webhook。

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

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

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

階段類別	支援服務（可直接整合）
Source	CodeCommit、GitHub、GitHub Enterprise、Amazon S3
Build	CodeBuild、Jenkins、自訂 Lambda Function（或外部 webhook 搭配）
Deploy	CodeDeploy、CloudFormation、Elastic Beanstalk、ECS、Lambda

💡 進階技巧：

如果你使用的是非 AWS 的工具（如 GitLab CI、Bitbucket、DockerHub 等），也可以透過 webhook 或 AWS Lambda 進行整合。

想加入通知、報告、審核等功能，也能透過 Action Type: Invoke 搭配 Lambda 來實現。

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

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

Source Stage：監聽 GitHub 專案是否有 push（分支為 main）
Build Stage：使用 CodeBuild 執行 npm install → npm run build → 輸出到 build/
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 的常見功能與優勢

功能	說明
✅ 多語言支援	預設支援 Node.js、Python、Java、Go、Ruby、PHP 等常見語言
✅ 自訂執行環境（Docker）	可以使用你自訂的 Docker image 來建置，例如內建特殊套件或工具的環境
✅ 雲端建置，無需維護機器	完全免去設定 Jenkins Slave、CI Server 的麻煩，AWS 幫你建好執行環境
✅ 與 IAM 整合	可控權限範圍，安全建置；僅能存取你允許的資源（S3、ECR、Secrets Manager 等）
✅ 輸出 Artifact 上傳 S3	建置完成後可以自動把檔案上傳到指定的 S3 Bucket，供 CodeDeploy 或手動下載使用

常見實際應用情境

情境	CodeBuild 可做的事
建置 React / Vue 前端應用	自動執行 npm install、npm run build，輸出 dist/ 資料夾
建置 Java 專案（如 Maven）	自動編譯 .java 檔案、打包 .jar 或 .war，上傳到 S3 或 Elastic Beanstalk
執行自動化測試與 Linter	在 build 階段跑 ESLint、Jest、Pytest 等測試，失敗即終止流程
Docker Image 打包 + 上傳到 ECR	自訂 buildspec.yml，使用 CLI 打包 Docker 並推送到 Amazon Elastic Container Registry

除錯與日誌追蹤

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

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

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

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

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

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

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

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

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

環境類型	適用情境與說明
EC2	傳統的虛擬機部署，可指定一組 EC2 實例部署 Web App、後端服務等。支援滾動更新、分批部署。
ECS	適用於容器化服務部署，支援 Blue/Green（藍綠部署）策略，適合微服務架構與可用性要求高的系統。
Lambda	支援無伺服器架構，部署時會將新的 Lambda 版本導入，並更新別名指向最新版本。
On-Premises	可部署到企業內部伺服器，只要安裝 CodeDeploy agent 並註冊實例即可使用。

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

CodeDeploy 的工作原理

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

整體流程如下：

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

💡 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

🧩 結構說明：

區塊	說明
version	appspec 檔案格式，目前 EC2 使用 0.0，Lambda 則是 0.0 或 1.0
os	目標作業系統類型（linux 或 windows）
files	定義 artifact 中哪些檔案要複製到目標位置（可單檔、資料夾、多個目標）
hooks	定義在部署流程中的「哪個階段」要執行哪些腳本，可控制部署流程（如安裝、重啟、測試等）

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

階段名稱	說明
BeforeInstall	解壓縮與覆蓋檔案前執行，可用來停止服務或備份舊資料
AfterInstall	檔案複製完成後執行，可用來安裝依賴、搬移檔案等
ApplicationStart	部署結束後啟動應用程式、啟動伺服器等動作
ValidateService	驗證服務是否啟動成功（可設條件回報部署成功與否）

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

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

部署策略	說明
In-place 部署	直接在原本的實例上覆蓋舊版程式碼（適用 EC2、本地）
Blue/Green	同時維護兩組環境（舊版與新版），先將新版部署至閒置環境，再轉向流量（適用 ECS、Lambda）

這讓你可以實作：

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

CodeDeploy 與 CI/CD 流程的關係

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

接收 CodeBuild 輸出的 artifact（透過 S3 傳遞）
根據 appspec.yml 對目標實例進行部署
通知 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 成功 / 失敗]

實務小提醒

注意事項	解說
✅ 每一階段都可單獨執行	你可以只用 CodeBuild 或 CodeDeploy，不一定要全部串在 CodePipeline 中
✅ 資源傳遞使用 artifact 機制	CodeBuild 輸出的檔案稱為 artifact，CodePipeline 負責將它傳遞給下一個階段
✅ IAM 權限需正確設置	CodeBuild、CodeDeploy 都需要有權限去讀取 S3、部署資源、寫入 CloudWatch Logs 等
✅ 日誌可查、易追蹤	所有過程的成功或失敗訊息會記錄在每個服務的 Logs 與 CodePipeline 視覺化流程中

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

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

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

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