CodeBuild

• 屬於 CI 層級，基本流程為拉取原始碼、建置、測試，透過這些流程不斷持續整合成可交付的程式碼

• CodeBuild 皆使用 Container 來建置虛擬環境， OS 支援自家的 Amazon Linux2 和 Ubuntu 兩種，更詳細規格可參考 這裡

• 若想要使用自訂的 Container 也是可以的，可參考 這裡

• 比較進階的玩法是 batch build，支援 Graph、List、Matrix 三種，Graph、List 可以指定不同的資源等級 (comput-type)、image 來運行依序或並發的 CodeBuild，而 Matrix 則更靈活的設定固定條件和動態條件來並發 CodeBuild，詳細可參考 官方文件

附註：CodeBuild 中要做 Deploy 動作也是沒有問題的，只是需要下指令自行達成，並且相關的 IAM Policy 要設定好，若已經用 AWS CodeDeploy 來做部署的話，建議直接用 CodePipeline 來做就好，因為內建已支援，會省很多工

CodePipeline

• 屬於 CI + CD 層級，CodePipeline 可整合 CodeBuild，最基本的流程分為幾個階段 (Stage)，分別為 Source Stage、Build Stage、Test Stage (Staging Stage)、Deploy Stage

• CD 分為兩種，Continues Delivery (持續交付) 和 Continues Deployment (持續部署)，兩者最主要的差異，前者是在原始碼可部署狀態時，交付給如 QA Team，或其他團隊，等待部署(手動)，而後者直接部署上線，交付對象為最終使用者，AWS CodePipeline 支援在 Deployment stage 前，能有 Manual Approve 的流程，可供如 QA 團隊來審核後，再進行部署

• Build Stage 不一定要用 AWS CodeBuild, 也可以自訂 Action 來整合地端的 Build Tools，如 Jenkins，可靈活運整合現有環境的工具

• 每個 Stage 可包含多種 Action，預設支援的 Action 如下

  • Source
  • Build
  • Test
  • Deploy
  • Approval
  • Invoke (如 lambda)

知道有哪幾種類型 Action ，就能設計組合各種客製化的 CodePipeline

使用上的差異與心得

• CodeBuild 的 Source Provider 以 GitHub 為例，是使用 WebHook 來觸發 CodeBuild，可以設定和過濾各種觸發條件，如 Push、PR、Commit message 等，例如只設定 PR 再觸發 CodeBuild，過濾某一個 Branch Name 不執行 CodeBuild (下一篇實作上會演示)

• CodePipeline 的 Source Stage，是以 CodestarConnection 的方式來連接到 Repo Source (例如 GitHub)，但只能設定觸發 單一 Branch，無法像 CodeBuild 可以設定觸發多種 event type，以我目前的理解，CodePipline 是設計給軟體包含 CI/CD 的整條流水線，既然包含部署，所以一般只是單一 branch 來觸發就夠用了

• CodeBuild 可單獨執行，也可以掛在 CodePipeline 中的 Build Stage 中，有這兩種模式，但 CodeBuild 只有單獨執行時，才有內建支援 Build badge、同步 GitHub commit status 這兩個功能，換言之，掛在 CodePipeline 中的 CodeBuild 時，build badge、同步 GitHub commit status 這兩個功能必需要自己實作，這部分可參考使用我寫的 cdk-codepipeline-status CDK Construct

• 一般環境會區分 dev、staging、production 的環境，至少也會區分 dev 和 production，所以會需要思考 CodeBuild 和 CodePipeline 本身 Infra 的部署，目前經驗上只需要一個 CodeBuild 當作所有環境的 CI 流程，而 CodePipeline 則每個環境都需要一個，因為跟部署有關，整合 AWS CodeDeploy 上會比較方便

最後來看一張示意圖