AWS CI/CD：CodeCommit、CodeBuild、CodeDeploy 與 CodePipeline

AWS CI/CD pipeline 工具是 DVA-C02 Task Statement 3.4（「使用 AWS CI/CD 服務部署程式碼」）的核心考點。開發者助理認證候選人必須熟練描述：AWS CodePipeline 如何編排各個階段與動作、AWS CodeBuild 如何依 buildspec.yml 編譯產出 artifact、AWS CodeDeploy 如何透過 appspec.yml 生命週期 hook 將 artifact 推送至 Amazon EC2 機群、AWS Lambda 函式與 Amazon ECS 服務、Amazon ECR 如何儲存容器映像、Amazon CodeCatalyst 如何將整個工具鏈包裝成專案級工作流程，以及 AWS CodeStar Notifications 如何將 pipeline 事件串接至 Slack、Amazon SNS 和 AWS Chatbot。本指南逐一介紹 DVA-C02 考試所涵蓋的每個 AWS CI/CD pipeline 工具，並附上考試陷阱、callout 與 FAQ。

什麼是 AWS CI/CD Pipeline 工具？

AWS CI/CD pipeline 工具是 AWS 提供的受管服務家族，用來為在 AWS 上執行的軟體實作持續整合與持續部署（CI/CD）流程。持續整合代表每次原始碼變更都會自動完成建置與測試；持續部署代表每次通過建置的版本都能自動部署至目標環境。DVA-C02 考試將這些能力分為七個 AWS CI/CD pipeline 工具：

1. AWS CodePipeline — 編排器（orchestrator），定義階段、動作、流程轉換與 artifact 流向。
2. AWS CodeBuild — 建置器（builder），在短暫容器中執行 buildspec.yml 各階段並輸出 artifact。
3. AWS CodeDeploy — 部署器（deployer），使用 appspec.yml 生命週期 hook 將 artifact 推送至 EC2、Lambda 或 ECS。
4. AWS CodeCommit — 受管 Git 原始碼控制，內建觸發器可串接 Lambda 與 SNS。
5. AWS CodeArtifact — 私有套件倉庫，支援 npm、Maven、PyPI、NuGet 及通用格式。
6. Amazon ECR — 私有與公開容器映像倉庫，具備生命週期政策與弱點掃描。
7. Amazon CodeCatalyst — 統一 DevOps 平台，整合原始碼、工作流程、環境與問題追蹤。

圍繞這七個工具的是 AWS CodeStar Notifications，它是跨服務的通知規則層，將 pipeline、建置、部署事件推送至 Amazon SNS、AWS Chatbot 和 Slack。

DVA-C02 的正確答案幾乎總是指向上述七個 AWS CI/CD pipeline 工具之一。當考題出現「團隊想要建置一個 Java 專案、將 JAR 發布至內部倉庫，並在 CloudWatch 告警觸發時自動回滾至正式環境」這類情境，你應該立刻在腦海中勾勒出一張 CodePipeline 流程圖：CodeCommit → CodeBuild → CodeArtifact push → CodeDeploy（含告警回滾）。

白話文解釋 AWS CI/CD Pipeline 工具

要將 AWS CI/CD pipeline 工具牢牢記住，可以把每個服務對應到一個生活情境。

類比一 — 便當工廠的生產線（食品製造業類比）。 想像一座每天生產一萬個便當的中央廚房。AWS CodePipeline 是把托盤從一個工作站傳到下一個工作站的輸送帶，每個工作站是一個階段：備料（source）、烹飪（build）、擺盤（test）、出貨（deploy）。AWS CodeBuild 是烹飪工作站的烤箱——它接收原料（原始碼），按照食譜（buildspec.yml）操作，輸出熟食（artifact）。AWS CodeDeploy 是外送員，把完成的便當送到客人桌前（EC2 機群、Lambda alias 或 ECS 服務），並在每個交接步驟按照交接清單（appspec.yml hook）確認。Amazon ECR 是存放預先備好的容器映像的冷凍庫。AWS CodeArtifact 是每個工作站都能取用的食材儲藏室（npm、Maven、PyPI、NuGet）。Amazon CodeCatalyst 是廚房主管的工作板，在一個統一儀表板上追蹤所有訂單、食譜、烤箱與外送員。AWS CodeStar Notifications 是對講機系統，一旦某個便當燒焦或延誤就立刻在 Slack 上通知主管。

類比二 — 機場行李輸送系統（物流類比）。 你的原始碼 commit 是一個行李箱。AWS CodeCommit 是報到櫃台。AWS CodePipeline 是把行李箱依序送過 X 光機（build）、海關（test）最後送上飛機（deploy）的輸送帶。CodePipeline 的 Superseded 執行模式就像智慧輸送帶，能讓較新的行李箱在同一個等候區超越較舊的行李箱。Queued 代表所有行李箱嚴格按照先進先出的順序處理。Parallel 代表輸送帶可在不同軌道上同時處理多個行李箱。Amazon ECS 上的 CodeDeploy 藍綠部署，就像把一架全新的飛機推到登機口、讓乘客登上新飛機（測試監聽器），確認無誤後才把舊飛機拖走（終止舊 task set）。

類比三 — 開卷考試（開發者生產力類比）。 開發者助理的日常工作就像一場可以翻閱 AWS 文件的開卷考試。AWS CI/CD pipeline 工具負責自動批改。CodeCommit 是答案卷。CodeBuild 是執行單元測試的自動批改器。CodeDeploy 是公布成績的教務處。CodePipeline 是確保每個步驟依序完成、任何步驟失敗就暫停考試的監考官。手動審批動作就是監考官在發布成績前暫停，等待系主任簽核。整個系統受版本控制、可重現且在 CloudTrail 中留有稽核紀錄——這正是資深開發者在正式環境中應建立的架構。

三個類比的對應關係：CodePipeline 是輸送帶／監考官／工作板；CodeBuild 是烤箱／X 光機／自動批改器；CodeDeploy 是外送員／飛機拖車／教務處；CodeCommit、CodeArtifact、ECR 分別是原料、食材儲藏室與冷凍庫；CodeCatalyst 是統一的管理者；CodeStar Notifications 是對講機。所有關於 AWS CI/CD pipeline 工具的 DVA-C02 題目，都可化約為把情境對應到上述角色。

AWS CodePipeline — 編排器

AWS CodePipeline 是 AWS CI/CD pipeline 工具家族的編排層。一條 pipeline 由一串有向的 stages（階段） 組成；每個 stage 包含一或多個 actions（動作）；actions 取用並產出儲存在 S3 artifact bucket 中的 artifacts（特定整合情境下也可使用鄰近 AWS CodeArtifact 的儲存位置）。

CodePipeline 階段與動作

CodePipeline pipeline 一定以 Source 階段開始，通常以 Deploy 階段結束。中間可以任意組合 Build、Test、Approval 及 Invoke 階段。一條 pipeline 至少需要兩個階段，且第一個必須是 Source 階段。

AWS CodePipeline 支援的動作類別：

• Source — AWS CodeCommit、Amazon S3、Amazon ECR、GitHub（透過 AWS CodeStar Connections 或 CodeConnections）、GitHub Enterprise Server、GitLab、Bitbucket。
• Build — AWS CodeBuild、Jenkins、TeamCity。
• Test — AWS CodeBuild、AWS Device Farm、Ghost Inspector 及第三方測試提供者。
• Deploy — AWS CodeDeploy、AWS Elastic Beanstalk、AWS CloudFormation、Amazon ECS、Amazon ECS 藍綠（透過 CodeDeploy）、AWS AppConfig、AWS OpsWorks、Amazon S3、AWS Service Catalog。
• Approval — 由具備 IAM 授權的成員手動審批，可選擇性附加 Amazon SNS 通知與審閱 URL。
• Invoke — AWS Lambda 與 AWS Step Functions。

Artifacts 與 Artifact Store

每條 CodePipeline pipeline 都使用一個 artifact store，即一個 Amazon S3 bucket，用來存放各動作間交換的壓縮輸入輸出。每個動作以邏輯名稱宣告輸入 artifact 與輸出 artifact，CodePipeline 會自動在各階段間傳遞正確的 S3 物件參照。多 Region pipeline 可以為每個 Region 掛載一個 artifact store；CodePipeline 會在遠端 Region 執行動作前，先將 artifact 複製過去。

手動審批動作

手動審批動作（Manual Approval action） 會暫停 pipeline，直到授權的 IAM 身分點擊「核准」或「拒絕」為止。你可以附加一個 Amazon SNS topic，讓審閱者收到含直接審批 URL 的電子郵件。手動審批是 AWS CI/CD pipeline 工具建議的正式環境前最後一道防線，能防止高風險變更自動上線。

跨帳號與跨 Region Pipeline

AWS CodePipeline 支援 跨帳號動作，方式是假設目標帳號中的 IAM 角色。來源帳號的 pipeline 角色必須被授予目標帳號角色的 sts:AssumeRole 權限，且目標帳號角色必須具備執行該動作所需的權限（部署 stack、推送至 ECR 等）。常見模式是在「tools」帳號中建立集中式 pipeline，部署至隔離的 dev、staging 和 prod 帳號。

AWS CodePipeline 支援 跨 Region 動作，方式是為每個部署目標 Region 設定額外的 artifact store。Pipeline 本身位於一個 Region（「home Region」），但可透過名稱在其他 Region 中呼叫動作。CodePipeline 會在動作執行前，先將輸入 artifact 複製至遠端 Region。

Pipeline 觸發器、篩選器，以及輪詢 vs 事件

Pipeline 可透過三種機制在原始碼變更時自動啟動：

1. CloudWatch Events / Amazon EventBridge（建議）— 事件驅動、低延遲。CodeCommit 發出 referenceUpdated 事件後，EventBridge 規則立即啟動 pipeline。
2. Amazon S3 來源輪詢 — 針對 S3 來源，現代建議是使用 Object Created EventBridge 規則；舊版路徑是 CodePipeline 輪詢，速度較慢且 API 呼叫成本較高。
3. Webhook（適用透過 CodeConnections 接入的 GitHub / Bitbucket / GitLab） — Git 提供者將事件推送至 CodePipeline。

Pipeline 觸發器與篩選器 可讓你限制哪些原始碼變更會啟動 pipeline：依特定分支、tag、檔案路徑或 pull request 事件觸發。篩選器在觸發器層進行評估，無關的 push 永遠不會消耗 CodeBuild 分鐘數。這是每位 DVA-C02 候選人都應熟記名稱的 V2 pipeline 類型功能。

Pipeline 執行模式 — Queued、Parallel、Superseded

AWS CodePipeline V2 支援三種 執行模式（execution modes），用來控制當新的 pipeline 執行到達而另一個執行仍在進行中時的行為：

• Superseded（預設） — 較新的執行可以取代在階段間等待的較舊執行。當只需要最新的 commit 時使用（主線開發）。
• Queued — 執行以 FIFO 順序一次一個地進行，任何執行都無法超越前者。當嚴格順序很重要時使用（例如：依序執行的資料庫遷移）。
• Parallel — 執行在獨立流程上並行進行。當每個原始碼變更都是隔離的時使用（例如：每個服務使用各自分支的 monorepo）。

選擇正確的執行模式是 V2.1 時代的考試主題。當 DVA-C02 描述一個「只在乎最新變更」的團隊時，答案是 Superseded；當描述「每個 commit 都必須按順序部署」時，答案是 Queued；當提到「並行功能分支」時，答案是 Parallel。

CloudWatch Events 觸發器 vs 輪詢

舊版 CodePipeline pipeline 使用 輪詢——CodePipeline 會定期輪詢來源（CodeCommit、S3）以偵測變更。輪詢已被棄用，建議改用 CloudWatch Events / EventBridge 觸發器，因為輪詢速度較慢（可能延遲數分鐘）、成本較高（API 呼叫），且無法依檔案路徑篩選。現代 AWS CI/CD pipeline 工具模式一律使用 EventBridge 驅動的觸發器。若 DVA-C02 題目提到「降低 pipeline 啟動延遲」，正確答案是將輪詢改為 EventBridge 觸發器。

AWS CodeBuild — 建置器

AWS CodeBuild 是 AWS CI/CD pipeline 工具家族中的全受管建置服務。它在 AWS 管理的運算資源上執行短暫的建置容器，依 buildspec.yml 中定義的階段執行，並發布 artifact 與報告。

buildspec.yml 階段

buildspec.yml 是存放於原始碼根目錄的 YAML 檔案，定義 CodeBuild 的執行計畫。該檔案包含四個有序階段以及選用區段：

version: 0.2
env:
  variables:
    BUILD_ENV: "prod"
  parameter-store:
    DB_HOST: "/prod/db/host"
  secrets-manager:
    API_KEY: "prod/api:SecretString:key"
phases:
  install:
    runtime-versions:
      nodejs: 20
    commands:
      - npm ci
  pre_build:
    commands:
      - echo "Logging in to ECR"
      - aws ecr get-login-password | docker login --username AWS --password-stdin $REPO_URI
  build:
    commands:
      - npm run build
      - docker build -t $REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION .
  post_build:
    commands:
      - docker push $REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION
      - printf '[{"name":"app","imageUri":"%s"}]' $REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION > imagedefinitions.json
artifacts:
  files:
    - imagedefinitions.json
    - appspec.yml
    - taskdef.json
reports:
  jest-reports:
    files: [coverage/junit.xml]
    file-format: JUNITXML
cache:
  paths:
    - node_modules/**/*

四個階段說明：

1. install — 執行環境設定。使用 runtime-versions 固定 Node.js、Python、Java、Go、Ruby、.NET、PHP 或 Docker 版本。安裝不屬於應用程式快取的工具鏈相依性。
2. pre_build — 登入倉庫、執行 linter、取得機密，或任何必須在實際建置前成功完成的步驟。
3. build — 編譯、打包或封裝，產出主要 artifact。
4. post_build — 推送映像、加上 tag、為 Amazon ECS 輸出 imagedefinitions.json，或寫入 Lambda zip 輸出。

階段失敗會向後傳遞——若 install 失敗，後續階段將被跳過。post_build 的失敗即便 build 成功，整個建置仍會標記為失敗。

Artifacts 與報告

Artifacts 是 CodeBuild 發布至 S3（或作為輸出 artifact 回傳給 CodePipeline）的檔案。在 artifacts: 區塊中宣告。對於由 CodePipeline 驅動的建置，CodeBuild 會自動將 artifact 封裝至 pipeline 的 artifact store。

Reports 是 CodeBuild 用於測試結果與程式碼覆蓋率的獨立一級功能。一個 report group 保存同一測試套件的多次執行結果。支援的格式：JUnit XML、Cucumber JSON、TestNG XML、Visual Studio TRX、NUnit，以及 Cobertura / JaCoCo / Clover / SimpleCov（程式碼覆蓋率）。報告會在 CodeBuild 主控台以通過／失敗趨勢圖呈現——當 DVA-C02 問到「測試結果應在哪裡收集與視覺化？」時，Reports 是標準答案。

環境變數、Parameter Store 與 Secrets Manager

CodeBuild 提供三種建置時期組態注入機制：

• 純 variables — 非機密值，例如建置旗標與功能開關。
• parameter-store — 參照 AWS Systems Manager Parameter Store 參數，支援 SecureString（KMS 加密）參數。
• secrets-manager — 直接參照 AWS Secrets Manager 機密，用於需要輪換的憑證（資料庫密碼、API 金鑰）。

絕不可在 buildspec.yml 中硬編碼機密或將其提交至原始碼。DVA-C02 考試將從明文 variables 讀取機密的答案標記為錯誤。

運算類型、建置映像與自訂映像

CodeBuild 專案需指定：

• 運算類型（Compute type） — BUILD_GENERAL1_SMALL（3 GB / 2 vCPU）、BUILD_GENERAL1_MEDIUM（7 GB / 4 vCPU）、BUILD_GENERAL1_LARGE（15 GB / 8 vCPU）、BUILD_GENERAL1_2XLARGE（145 GB / 72 vCPU）。較大規格每分鐘費用較高。
• 建置映像（Build image） — 建置執行所在的容器映像。AWS 受管映像名稱如 aws/codebuild/standard:7.0、aws/codebuild/amazonlinux2-x86_64-standard:5.0 等，內含整理好的工具鏈（Docker、Node、Python、Java、Go、.NET）。
• 自訂映像（Custom image） — 從 Amazon ECR 或 Docker Hub 拉取的任意映像。當 AWS 受管映像缺少必要工具（特定編譯器版本、嵌入式建置系統）時使用。

較大的運算類型可縮短實際建置時間，但每分鐘費用較高。DVA-C02 對於「建置速度太慢」的解法通常是先啟用快取，再考慮提升運算類型。

使用 Docker 本地端建置

CodeBuild 透過 codebuild_build.sh 與 CodeBuild Agent Docker 映像提供 本地端建置支援。開發者在推送前，可在自己的電腦上完整重現 CodeBuild 建置環境，加速 buildspec.yml 的除錯。當 DVA-C02 問到「如何在不消耗 AWS 建置分鐘數的情況下，對只在 CodeBuild 內失敗的建置進行除錯？」時，這是正確答案。

快取 — S3 與本地端

CodeBuild 支援兩種快取類型：

• S3 快取 — 以 bucket 與 key 宣告，可跨建置主機共用。最適合不常變動的相依性（node_modules、Maven ~/.m2、pip wheels）。因為每次執行都需要下載，速度略慢於本地端快取。
• 本地端快取 — 快取於 CodeBuild 主機本身。三種模式：DOCKER_LAYER（docker build 的 Docker 層快取）、SOURCE（Git clone 快取）、CUSTOM（任意路徑）。比 S3 快取快，但只有在重複使用同一主機時才有效——全新主機就是快取未命中。

DVA-C02 考試將快取視為效能最佳化的解法。當情境描述「CodeBuild 每次執行都下載相同的 300 MB 相依性」時，解法是設定 S3 快取並在 paths: 中指向相依性資料夾。

批次建置

CodeBuild 批次建置（Batch builds） 讓單一專案在一次呼叫中執行多個相關建置——例如同一個版本的 x86、Arm64 與 Windows 變體。批次建置共用組態但在獨立主機上執行，可並行化。當 DVA-C02 描述「在單一 CodePipeline 動作中，對多種架構建置同一個應用程式」時，批次建置是正確答案。

Webhooks

當 CodeBuild 從 Git 來源直接觸發（CodePipeline 之外）時，你需要設定一個 webhook——Git 提供者在 push、pull_request、tag 或 release 時呼叫的回呼 URL。Webhook 篩選群組讓你限制哪些事件會啟動建置（特定分支、檔案路徑模式、行為者身分）。Webhook 是 DVA-C02 「不建置完整 pipeline，而在每個 pull request 時執行 CodeBuild」的解法。在 CodePipeline 內部，pipeline 觸發器與篩選器在 pipeline 層級處理相同的需求。

AWS CodeDeploy — 部署器

AWS CodeDeploy 是 AWS CI/CD pipeline 工具家族中的部署服務。它支援三種運算平台：EC2 / 本地端、AWS Lambda 與 Amazon ECS。每種平台有各自的 appspec.yml 結構、部署組態與生命週期 hook 集合。

appspec.yml 基礎

appspec.yml 是 CodeDeploy 讀取的部署宣告文件，用以了解部署什麼及如何部署。其結構依平台而異：

• 對於 EC2 / 本地端，appspec.yml 列出要複製的檔案、要設定的權限，以及在每個生命週期 hook 執行的腳本。
• 對於 Lambda，appspec.yml 指定函式名稱、alias、目前版本、目標版本，以及生命週期 hook Lambda 函式。
• 對於 ECS，appspec.yml 指定 task definition、容器、連接埠，以及 hook Lambda 函式。

CodeDeploy on EC2 / 本地端

對於 EC2 / 本地端部署，每個目標主機上必須安裝並執行 CodeDeploy agent。Agent 輪詢 CodeDeploy 以取得部署指令。目標被分組至 deployment group——一組由 Auto Scaling group 成員、EC2 tag 或本地端執行個體 tag 識別的執行個體集合。

EC2 / 本地端支援的部署組態：

• CodeDeployDefault.AllAtOnce — 同時部署至所有執行個體。速度最快，風險最高。
• CodeDeployDefault.HalfAtATime — 每次部署一半的執行個體，風險平衡。
• CodeDeployDefault.OneAtATime — 每次部署一個執行個體。速度最慢，風險最低。
• 自訂組態 — 以數量或百分比指定最低健康主機數。

EC2 生命週期 hook（原地部署時依序執行）：

1. ApplicationStop
2. DownloadBundle
3. BeforeInstall
4. Install
5. AfterInstall
6. ApplicationStart
7. ValidateService

在 EC2 藍綠部署期間，替換機群上還會觸發額外的 hook：BeforeBlockTraffic、BlockTraffic、AfterBlockTraffic、BeforeAllowTraffic、AllowTraffic、AfterAllowTraffic。Hook 的順序是 DVA-C02 的長青陷阱——請記住 BeforeInstall → Install → AfterInstall → ApplicationStart → ValidateService。

CodeDeploy on AWS Lambda

CodeDeploy on Lambda 在 alias 背後的兩個 Lambda 函式版本之間進行流量切換。你部署一個新版本，CodeDeploy 根據 部署組態 將流量從舊版本切換至新版本，並由生命週期 hook Lambda 函式驗證流量切換。

Lambda 部署組態：

• AllAtOnce — 立即切換 100% 流量（CodeDeployDefault.LambdaAllAtOnce）。
• Linear — 每 N 分鐘切換固定百分比。內建範例：LambdaLinear10PercentEvery1Minute、LambdaLinear10PercentEvery2Minutes、LambdaLinear10PercentEvery3Minutes、LambdaLinear10PercentEvery10Minutes。
• Canary — 立即切換一小部分流量，等待一段時間後再切換剩餘流量。內建範例：LambdaCanary10Percent5Minutes、LambdaCanary10Percent10Minutes、LambdaCanary10Percent15Minutes、LambdaCanary10Percent30Minutes。

Lambda 生命週期 hook：BeforeAllowTraffic（在任何流量切換前執行——適合對新版本執行冒煙測試）與 AfterAllowTraffic（在完整切換後執行——最終驗證）。每個 hook 是一個獨立的 Lambda 函式。

CodeDeploy on Amazon ECS（藍綠部署）

CodeDeploy on ECS 一律執行 藍綠部署。它在現有 task set（藍）旁建立一個新的 task set（綠），透過負載平衡器在兩者之間切換流量，最後終止藍色 task set。

使用兩個負載平衡器監聽器：

• 生產監聽器（Production listener） — 承載真實使用者流量，在切換前始終指向藍色。
• 測試監聽器（Test listener）（選用）— 讓綠色 task set 在生產流量切換前，先由內部冒煙測試驗證。通常監聽在非標準連接埠。

等待時間 組態在切換步驟之間增加暫停，讓你在終止舊環境前觀察綠色部署：

• 測試流量等待時間 — 綠色 task set 建立後，測試監聽器保持活躍的時間長度。
• 終止原始 task set 前的等待時間 — 生產流量完全切換至綠色後，藍色繼續運行的時間長度。若需要回滾，可在此視窗內將流量切回藍色——這是 AWS 上最快速的回滾方式。

ECS 生命週期 hook（均為 Lambda 函式）：BeforeInstall、AfterInstall、AfterAllowTestTraffic、BeforeAllowTraffic、AfterAllowTraffic。AfterAllowTestTraffic hook 是 DVA-C02 的經典考點——它透過測試監聽器驗證綠色 task set，然後才切換生產流量。

Deployment Groups

Deployment group 識別 CodeDeploy 部署的目標。對於 EC2 / 本地端，它是一組有標籤的執行個體或 Auto Scaling group；對於 Lambda，它是函式加上 alias；對於 ECS，它是 cluster 加上 service。一個 CodeDeploy 應用程式可以擁有多個 deployment group，這就是如何用一個應用程式定義建立 dev、staging 和 prod 模型的方式。

告警自動回滾

CodeDeploy 支援在兩種觸發條件下 自動回滾：

1. 部署失敗 — 任何 hook 失敗或健康檢查失敗都會觸發回滾至上一個已知良好的修訂版本。
2. CloudWatch 告警 — 若你將 CloudWatch 告警與 deployment group 關聯，當告警在部署期間進入 ALARM 狀態時，CodeDeploy 會自動回滾。這是 DVA-C02「當新版本導致錯誤率或延遲上升時如何回滾？」的標準答案。

回滾的方式是重新部署先前成功的修訂版本，而非恢復先前的運算資源——因此運算目標（執行個體、Lambda alias、ECS task set）會透過一次全新的部署接收舊程式碼。

AWS CodeCommit — 受管 Git

AWS CodeCommit 是 AWS CI/CD pipeline 工具家族中的受管 Git 服務。它託管私有 Git 儲存庫，支援 HTTPS 和 SSH 存取，並與 IAM 原生整合進行身分驗證。

DVA-C02 所需的 CodeCommit 重要功能：

• 基於 IAM 的身分驗證 — 無需獨立的憑證系統；能呼叫 AWS 服務的 IAM 使用者或角色，即可 clone CodeCommit 儲存庫。
• 跨帳號存取 — 帳號 A 中的角色可假設帳號 B 中的角色，並 clone 帳號 B 中的儲存庫。
• 觸發器（Triggers） — 當事件發生時執行 AWS Lambda 函式或發布 Amazon SNS 訊息：commit 推送、分支建立、分支刪除、tag 建立。觸發器是將 CodeCommit 串接至事件驅動 AWS CI/CD pipeline 工具工作流程的原生方式，無需輪詢。
• 審批規則範本（Approval rule templates） — 在合併前強制要求 pull request 審批。
• Pull requests — 以分支為基礎的程式碼審查，附有留言功能。
• 靜態加密 — 一律開啟，透過 AWS KMS（aws/codecommit 受管金鑰或客戶自管金鑰）。

在 DVA-C02 情境中，CodeCommit 是「完全受管的 Git 儲存庫，與 IAM 整合，並可在 commit 時觸發 Lambda 函式而無需第三方 webhook」的答案。CodeCommit 觸發器不同於 EventBridge 規則：觸發器在儲存庫上定義，從儲存庫同步觸發進入 Lambda 或 SNS；而 EventBridge 規則在帳號層級觀察 CodeCommit 事件，並可分派至任何 EventBridge 目標。

AWS CodeArtifact — 私有套件倉庫

AWS CodeArtifact 是 AWS CI/CD pipeline 工具家族中的 AWS 受管套件倉庫，提供以下套件格式的私有儲存庫：

• npm（Node.js）
• Maven（Java）
• PyPI（Python）
• NuGet（.NET）
• Generic（任意檔案；用於非特定語言生態系的發布套件與二進位檔）
• Swift（SwiftPM）、Ruby（Bundler）及其他格式持續新增中；請查看主控台以取得目前清單。

CodeArtifact 支援 上游儲存庫（upstream repositories）。私有儲存庫可以代理並快取公開上游來源，例如 npmjs.org、Maven Central、PyPI、NuGet Gallery。開發者第一次請求公開相依性時，CodeArtifact 從上游取得並快取它；後續的取用從 CodeArtifact 快取提供——降低外部相依性風險（供應鏈攻擊、上游中斷）並加速 CodeBuild 內的建置速度。

對 CodeArtifact 的身分驗證透過 IAM 範疇的 auth token 進行。開發者或 CodeBuild 容器執行 aws codeartifact get-authorization-token，並將 token 匯出至 npm、Maven、pip 或 dotnet CLI 組態中。

DVA-C02 將 CodeArtifact 作為「與 npm / Maven / pip / NuGet 相容的內部套件倉庫，具備 IAM 存取控制與公開上游快取」的答案。它不是容器倉庫——容器的答案是 Amazon ECR。

Amazon ECR — 容器映像倉庫

Amazon Elastic Container Registry（Amazon ECR）是 AWS CI/CD pipeline 工具家族中的容器映像倉庫，支援兩種倉庫類型：

• Amazon ECR 私有倉庫 — 每個帳號的私有儲存庫。映像由 Amazon ECS、Amazon EKS、AWS App Runner 和 AWS Lambda（容器映像 Lambda）拉取。IAM 管理推送與拉取權限。跨帳號拉取透過儲存庫政策設定。
• Amazon ECR 公開倉庫（Amazon ECR Public / public.ecr.aws） — 可公開拉取的映像。用於你希望網際網路存取的映像（開源發行版、範例應用程式）。

生命週期政策

ECR 生命週期政策 自動刪除舊映像以控制儲存成本。政策是包含一或多條規則的 JSON 文件：「刪除超過 30 天的映像」或「只保留最後 10 個標記為 release-* 的映像」。生命週期規則每日評估一次。DVA-C02 將生命週期政策作為「ECR 儲存持續成長；如何在不手動操作的情況下清理舊映像？」的答案。

映像掃描

ECR 提供兩種掃描模式：

• 基本掃描（Basic scanning） — 使用開源的 Clair CVE 資料庫。預設在推送時掃描；可手動重新排程。
• 增強掃描（Enhanced scanning） — 由 Amazon Inspector 提供支援。持續掃描作業系統套件和應用程式語言相依性（npm、Maven、PyPI、NuGet、Go、Ruby）。發現結果推送至 AWS Security Hub。

對於 DVA-C02「在容器映像進入生產環境前掃描 CVE」，答案是透過 Amazon Inspector 使用 ECR 增強掃描。

Pull-Through 快取規則

ECR 支援公開上游倉庫的 pull-through 快取規則（Docker Hub、Quay、Amazon ECR Public、GitHub Container Registry 和 Microsoft Container Registry）。第一次拉取從上游取得映像；後續拉取從 ECR 快取提供。這與 CodeArtifact 針對容器的上游行為相同。

Amazon CodeCatalyst — 統一 DevOps 平台

Amazon CodeCatalyst 是 AWS CI/CD pipeline 工具家族中的統一 DevOps 平台。CodeCatalyst 將原始碼控制、問題追蹤、工作流程（CI/CD）、開發環境和專案儀表板整合至單一專案級體驗。

CodeCatalyst 核心基本元素：

• Spaces — 計費與身分邊界，一個 Space 包含多個 Projects。
• Projects — 工作單位，每個 Project 有各自的原始碼儲存庫、工作流程、環境與問題追蹤。
• Workflows — 在 Project 內以 YAML 定義的 CI/CD pipeline。觸發條件包括 push、pull request、排程及手動執行。動作包括建置、測試、部署，以及與 AWS CodeBuild、AWS CodeDeploy、AWS Lambda、Amazon ECS、AWS CloudFormation、Terraform 和自訂動作的整合。
• Environments — 透過帳號連線（account connections）與 AWS 帳號連結的具名部署目標，工作流程部署至 Environments。
• Dev Environments — 與 IDE（Visual Studio Code、JetBrains、AWS Cloud9）整合的雲端開發機器，讓整個團隊使用一致的工具環境開發。
• Blueprints — 搭建完整 Project 的專案範本，內含最佳實踐工作流程與環境。
• Issues — 與 commit 和工作流程整合的輕量任務追蹤。

CodeCatalyst 與個別 AWS CI/CD pipeline 工具（CodePipeline、CodeBuild、CodeDeploy）的差異在於範疇——它是橫跨原始碼、CI/CD、環境與任務追蹤的統一體驗。舊有服務仍是一級公民，且通常是 CodeCatalyst 在許多動作背後呼叫的實際服務。當 DVA-C02 情境強調「跨專案、工作流程與環境的單一統一 DevOps 平台」，而非自行組裝個別服務時，CodeCatalyst 是正確答案。

AWS CodeStar Notifications — 通知層

AWS CodeStar Notifications 是 AWS CI/CD pipeline 工具家族的跨服務通知規則層。你建立 通知規則（notification rules），匹配來自 CodeCommit、CodeBuild、CodeDeploy 和 CodePipeline 的事件，並路由至三種目標類型：

• Amazon SNS topics — 用於電子郵件、SMS 或通用扇出。
• AWS Chatbot — 用於發布至 Slack 頻道或 Amazon Chime 聊天室。
• （間接）透過 SNS 扇出或 Lambda 訂閱的任何 EventBridge 目標。

通知規則以資源為單位——一條 CodePipeline pipeline 有各自的通知規則，指定哪些事件（pipeline 已啟動、pipeline 成功、pipeline 失敗、階段失敗、動作失敗、需要手動審批）觸發至哪些目標。對於 DVA-C02，CodeStar Notifications 是「當 pipeline 失敗時通知 Slack 頻道」的答案，而非自訂 EventBridge 規則加自訂 Lambda（雖然該替代方案也存在）。

AWS CodeStar 服務本身（2017 年推出的統一專案儀表板）已於 2024 年棄用，請勿與 AWS CodeStar Notifications 混淆——後者仍完全受支援，且是 AWS CI/CD pipeline 工具家族的一部分。

整合在一起 — 參考架構

典型的 DVA-C02 規模正式環境 AWS CI/CD pipeline 工具架構如下：

1. 開發者推送至 AWS CodeCommit 的 main 分支。
2. 一條 CodePipeline 觸發器 透過 Amazon EventBridge 規則在 referenceUpdated 時觸發。
3. CodePipeline Source 階段 讀取 commit 至 S3 artifact store。
4. CodePipeline Build 階段 呼叫 AWS CodeBuild，執行 buildspec.yml 各階段：安裝相依性（從 AWS CodeArtifact 上游快取）、建置 Docker 映像、推送至 Amazon ECR（生命週期政策會修剪舊 tag），並輸出 imagedefinitions.json、appspec.yml 和 taskdef.json 作為 artifact。
5. CodePipeline Test 階段 呼叫第二個 CodeBuild 專案進行整合測試，並發布 JUnit 報告。
6. CodePipeline Manual Approval 階段 暫停，透過 Amazon SNS topic 寄送電子郵件給審閱者。
7. CodePipeline Deploy 階段 呼叫 AWS CodeDeploy，使用 ECS 藍綠 deployment group。CodeDeploy 建立綠色 task set，對測試監聽器執行 AfterAllowTestTraffic hook，切換生產流量，並等待 30 分鐘後終止藍色 task set。
8. 若部署期間任何 CloudWatch 告警（錯誤率、p99 延遲、DLQ 深度）進入 ALARM 狀態，CodeDeploy 自動回滾。
9. AWS CodeStar Notifications 透過 AWS Chatbot 將 pipeline 成功／失敗事件推送至 Slack 頻道。
10. Amazon CodeCatalyst（選用）將整個架構包裝為包含問題追蹤、工作流程和開發環境的單一 Project。

此架構中的每個具名服務都是 AWS CI/CD pipeline 工具家族的一部分，且均在 DVA-C02 的考試範圍內。

關鍵數字與必記事實

• CodePipeline 每條 pipeline 的最少階段數：2 個，且第一個必須是 Source 階段。
• CodePipeline 執行模式：Superseded（預設）、Queued、Parallel。
• CodePipeline 類型：V1（舊版，輪詢）與 V2（執行模式、觸發器／篩選器）。
• CodeBuild buildspec 階段：install、pre_build、build、post_build。
• CodeBuild 運算類型：SMALL（3 GB）、MEDIUM（7 GB）、LARGE（15 GB）、2XLARGE（145 GB）。
• CodeBuild 快取類型：S3 與本地端（DOCKER_LAYER、SOURCE、CUSTOM）。
• CodeDeploy EC2 生命週期 hook（依序）：ApplicationStop、DownloadBundle、BeforeInstall、Install、AfterInstall、ApplicationStart、ValidateService。
• CodeDeploy Lambda hook：BeforeAllowTraffic、AfterAllowTraffic。
• CodeDeploy ECS hook：BeforeInstall、AfterInstall、AfterAllowTestTraffic、BeforeAllowTraffic、AfterAllowTraffic。
• CodeDeploy Lambda 部署組態：AllAtOnce、Linear（每 1/2/3/10 分鐘 10%）、Canary（10% 後等待 5/10/15/30 分鐘）。
• CodeDeploy EC2 部署組態：AllAtOnce、HalfAtATime、OneAtATime、Custom。
• ECR 掃描模式：Basic（Clair）與 Enhanced（Amazon Inspector）。
• CodeArtifact 格式：npm、Maven、PyPI、NuGet、generic（持續增加中）。
• CodeStar Notifications 目標：Amazon SNS 與 AWS Chatbot。

常見考試陷阱 — 必須記住的易錯點

陷阱一：「appspec.yml 和 buildspec.yml 可以互換」

錯誤。buildspec.yml 由 CodeBuild 讀取，定義建置階段與 artifact。appspec.yml 由 CodeDeploy 讀取，定義部署目標與生命週期 hook。把階段寫進 appspec 或把 hook 寫進 buildspec，在 DVA-C02 上是立即錯誤的答案。

陷阱二：「CodeDeploy ECS 部署可以是原地部署（in-place）」

錯誤。CodeDeploy on ECS 一律是藍綠部署。原地部署只適用於 EC2 / 本地端平台。若 DVA-C02 題目說「使用 CodeDeploy 對 ECS 進行原地部署」，答案即為錯誤。

陷阱三：「Lambda 部署的 Canary 和 Linear 是一樣的」

錯誤。Canary 立即切換一小部分流量，等待固定間隔後再一次切換剩餘流量，共兩個步驟。Linear 以固定百分比每 N 分鐘等量切換，共多個步驟。例如：Canary10Percent30Minutes 先切 10% 等 30 分鐘再切 90%；Linear10PercentEvery3Minutes 每 3 分鐘切 10%，共切十次，歷時 30 分鐘。

陷阱四：「輪詢是觸發 pipeline 的現代做法」

錯誤。輪詢已是舊版做法。現代 AWS CI/CD pipeline 工具使用 Amazon EventBridge 觸發器處理 CodeCommit 和 S3 來源。輪詢較慢、費用較高，且無法依路徑篩選。

陷阱五：「CodePipeline V1 支援執行模式」

錯誤。執行模式（Superseded、Queued、Parallel）是 僅限 V2 的功能。V1 pipeline 始終表現如同 Superseded。

陷阱六：「CodeArtifact 儲存容器映像」

錯誤。Amazon ECR 儲存容器映像。CodeArtifact 儲存語言套件（npm、Maven、PyPI、NuGet、generic）。搞混兩者答案即錯誤。

陷阱七：「CodeStar 和 CodeStar Notifications 是同一個東西」

錯誤。原始的 AWS CodeStar 專案儀表板服務已於 2024 年棄用。AWS CodeStar Notifications 是獨立且完全受支援的服務，將 CI/CD 事件路由至 SNS 和 AWS Chatbot。Amazon CodeCatalyst 是 CodeStar 專案儀表板角色的現代替代方案。

陷阱八：「CloudWatch 告警回滾只在部署開始前發生」

錯誤。CodeDeploy 在 整個部署視窗期間 持續監控設定的 CloudWatch 告警。若告警在任何時間點進入 ALARM 狀態，CodeDeploy 就會觸發回滾——這正是告警回滾的意義所在。

陷阱九：「CodePipeline 的手動審批需要自訂 Lambda」

錯誤。手動審批是內建的一級動作類別，具備 SNS 整合功能，無需 Lambda。

陷阱十：「Pipeline 觸發器和 Webhook 是同一回事」

部分正確。Webhook 是 Git 提供者對 CodeBuild 的回呼（在 CodePipeline 之外）。Pipeline 觸發器 是 CodePipeline V2 功能，可依分支／tag／路徑篩選來啟動 pipeline。它們在不同層級解決相似的問題。

AWS CI/CD Pipeline 工具 vs 類似概念

• AWS CodePipeline vs GitHub Actions — CodePipeline 是 AWS 原生編排，具備一級的 IAM、VPC 和跨帳號支援。GitHub Actions 是 GitHub 原生，擁有更大的第三方 action 目錄。DVA-C02 預期你以 AWS 服務作為答案；GitHub Actions 是干擾選項。
• AWS CodeBuild vs Jenkins — CodeBuild 完全受管、短暫且按分鐘計費。Jenkins 是自架或基於 EC2，需要你自行運行控制平面。DVA-C02「完全受管的建置服務，無需管理伺服器」一律對應 CodeBuild。
• AWS CodeDeploy vs Elastic Beanstalk — CodeDeploy 是具備細粒度生命週期 hook 的 EC2 / Lambda / ECS 部署引擎。Elastic Beanstalk 是擁有部署、運算佈建和自動擴展的受管平台抽象層。DVA-C02 提到「ECS 藍綠部署」對應 CodeDeploy，而非 Beanstalk。
• AWS CodeCommit vs GitHub / GitLab / Bitbucket — CodeCommit 是 AWS 原生受管 Git。GitHub 等服務透過 CodeConnections 整合至 CodePipeline。DVA-C02 將所有平台視為有效來源，但當情境強調「無需外部身分的 IAM 身分驗證」時，預期答案是 CodeCommit。
• Amazon CodeCatalyst vs 個別 Code 服務* — CodeCatalyst 是統一包裝器。個別服務仍可單獨使用，且通常是 CodeCatalyst 在許多動作背後實際呼叫的服務。

FAQ — AWS CI/CD Pipeline 工具高頻問題

Q1：buildspec.yml 和 appspec.yml 有什麼差異？ 答：buildspec.yml 由 AWS CodeBuild 使用，定義四個有序階段（install、pre_build、build、post_build）以及 artifact、報告、環境變數和快取。appspec.yml 由 AWS CodeDeploy 使用，定義部署目標加上生命週期 hook，hook 的確切集合依運算平台（EC2、Lambda 或 ECS）而異。混淆這兩個檔案是 DVA-C02 的高頻陷阱。

Q2：團隊只在意最新 commit 時，應選擇哪種 CodePipeline 執行模式？ 答：Superseded（預設值）。當新的執行到達而舊的執行仍在階段間等待時，新的執行會取代舊的執行。若需要嚴格的 FIFO 排序，請使用 Queued；若需要並行且相互獨立的流程，請使用 Parallel。

Q3：CloudWatch 告警觸發時，如何讓 CodeDeploy 部署自動回滾？ 答：將 CloudWatch 告警與 CodeDeploy deployment group 的回滾組態關聯。當告警在部署視窗期間進入 ALARM 狀態時，CodeDeploy 會觸發回滾至上一個已知良好的修訂版本。這是 AWS CI/CD pipeline 工具「依指標退化回滾」的標準答案，而非自訂 Lambda，也不是 Step Functions 狀態機。

Q4：CodeDeploy EC2 生命週期 hook 的正確順序為何？ 答：ApplicationStop → DownloadBundle → BeforeInstall → Install → AfterInstall → ApplicationStart → ValidateService。藍綠部署時，替換機群和原始機群上還會觸發圍繞流量封鎖與允許的額外 hook。

Q5：Lambda 部署的 Canary 和 Linear 組態有什麼差異？ 答：Canary 組態立即切換一小部分流量，等待固定間隔後一次切換剩餘流量——共兩個步驟。Linear 組態每 N 分鐘以固定百分比等量切換流量——共多個步驟。Canary 適合「希望快速初步驗證後再長時間浸泡觀察」的情境；Linear 適合「希望逐步均勻增加流量」的情境。

Q6：什麼時候應使用 Amazon ECR vs AWS CodeArtifact？ 答：Amazon ECR 儲存 ECS、EKS、App Runner 和 Lambda 容器映像的 容器映像。AWS CodeArtifact 儲存 npm、Maven、PyPI、NuGet 及通用二進位格式的 語言套件。Docker 映像絕不放入 CodeArtifact；npm 套件絕不放入 ECR。兩者都支援快取公開上游（ECR pull-through 快取規則；CodeArtifact 上游儲存庫）。

Q7：如何在每次 commit 推送至 AWS CodeCommit 儲存庫時觸發 AWS Lambda 函式？ 答：有兩種方式。(1) 在儲存庫上直接定義 CodeCommit 觸發器，在 referenceUpdated 時呼叫 Lambda。(2) 建立 Amazon EventBridge 規則，匹配 CodeCommit 的 referenceUpdated 事件並分派至 Lambda。若只有單一下游目標，CodeCommit 觸發器最為簡單；若需要多個目標、跨帳號路由，或觸發器能力以外的篩選邏輯，則偏好使用 EventBridge 規則。

Q8：什麼是 Amazon CodeCatalyst？什麼時候應選擇它而非自行組裝個別 Code 服務？* 答：Amazon CodeCatalyst 是統一 DevOps 平台，將原始碼控制、工作流程（CI/CD）、環境、雲端開發環境和問題追蹤整合至單一專案級體驗。當情境強調「跨專案、工作流程和環境的統一 DevOps 平台」，且團隊重視開箱即用的體驗而非自行組裝服務時，選擇 CodeCatalyst。當你需要最大控制權、服務層級 IAM 範疇，或需要與既有 AWS CI/CD pipeline 工具工作流程整合時，選擇個別服務（CodeCommit、CodeBuild、CodeDeploy、CodePipeline、ECR）。

Q9：如何在 CodePipeline pipeline 失敗時通知 Slack 頻道？ 答：在 pipeline 資源上建立 AWS CodeStar Notifications 規則，匹配 Pipeline execution failed 事件，並投遞至設定好目標 Slack 頻道的 AWS Chatbot 用戶端。無需自訂 Lambda。AWS Chatbot 也支援 Amazon Chime 和 Microsoft Teams 目標。

Q10：如何將機密注入 CodeBuild 建置流程？ 答：在 buildspec.yml 的 env.secrets-manager: 下參照 AWS Secrets Manager 的值，或在 env.parameter-store: 下參照 AWS Systems Manager Parameter Store 的 SecureString 值。絕不在 buildspec.yml 中硬編碼機密、絕不將其提交至原始碼、絕不透過純文字 variables: 項目公開機密。CodeBuild 服務角色必須對參照的資源具備 secretsmanager:GetSecretValue 或 ssm:GetParameters 權限。

延伸閱讀 — AWS 官方文件

• AWS CodePipeline 使用者指南：https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html
• AWS CodeBuild 使用者指南：https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html
• AWS CodeDeploy 使用者指南：https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html
• AWS CodeCommit 使用者指南：https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html
• AWS CodeArtifact 使用者指南：https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html
• Amazon ECR 使用者指南：https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html
• Amazon CodeCatalyst 使用者指南：https://docs.aws.amazon.com/codecatalyst/latest/userguide/welcome.html
• AWS CodeStar Notifications 使用者指南：https://docs.aws.amazon.com/codestar-notifications/latest/userguide/welcome.html
• CodeDeploy AppSpec 生命週期 Hook 參考：https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html
• CodeBuild buildspec 參考：https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html
• CodePipeline 執行模式：https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html
• AWS DVA-C02 考試指南 v2.1：https://d1.awsstatic.com/training-and-certification/docs-dev-associate/AWS-Certified-Developer-Associate_Exam-Guide.pdf

全面掌握 AWS CI/CD pipeline 工具是提升 DVA-C02 Domain 3 分數最有效率的方式。考試將每道 Task 3.4 題目化約為上述七個 AWS CI/CD pipeline 工具：CodePipeline 作為編排器、CodeBuild 作為建置器、CodeDeploy 作為部署器、CodeCommit 作為原始碼來源、CodeArtifact 與 Amazon ECR 作為套件與容器倉庫、Amazon CodeCatalyst 作為統一包裝器，加上 AWS CodeStar Notifications 作為通知層。記住執行模式、buildspec 各階段、各平台的 appspec.yml 生命週期 hook，以及 Canary 與 Linear 的差異，整個 AWS CI/CD pipeline 工具領域就能化約為一組小巧的決策樹。