技術專欄
.svg){kind=logo}
在快速的開發循環中，持續驗證開發結果，以求盡快開發出符合需求的產出，或依據產出修正。而這些驗證及修正的程序需要持續且重複進行，如果透過自動化工具來執行，就可以增加整體的效率，這個自動化流程就是 CI/CD。
AWS提供許多 CI/CD Pipeline的開發者工具，CodepiPeline是其中之一，它可以使用AWS CodeCommit或另一個外部來源，將原始碼部署在AWS，並觸發Pipeline 的執行。
AWS CodeBuild能執行代碼，構建應用程式，並進行任何你在Pipeline中需要做的事情。在Pipeline 進行的過程裡，你隨時都可以觸發Lambda函數運作，擴大Pipeline的可用性。有許多部署服務可以與CodePipeline協作，如CodeDeploy、Elastic Beanstalk、ECS和Fargate。CodePipeline提供大量整合能力．確保你能完成任何你所需要的場景。Codepipeline依據使用的 Pipeline數量收費，不包括使用CodeBuild的任何處理時間或S3。
每個單獨的CodePipeline Instance本身被稱為Pipeline。它包含了該Pipeline的所有設定選項，以及每個Pipeline裡至少2到10個步驟。一個Pipeline能夠在每個動作和階段之間傳遞前一個步驟的狀態。無論是你的原始碼、Pipeline狀態、文件，或是構建應用程式的二進位檔案，它們都被儲存在S3 Bucket。這是你的流程在CodePipeline中相互作用的主要方式。
任何輸入或輸出的Artifacts都是在流程動作本身中定義的，並由一個獨特的標誌名稱來區分。如果你想輸入由前一個動作輸出的某個Artifact，只需要把它作為一個輸入的Artifact名稱來引用，CodePipeline就能從Pipeline的S3 bucket中取得。
Pipeline需要一個名稱來識別自己，而且在你的AWS帳戶同一區域內是獨有的命名。每個Pipeline都需要一個服務角色，如此一來，它就能存取Lambda、S3、CodeCommit和其他與CodePipeline互動的大量資源。你需要建立或指定一個S3 bucket，以儲存Pipeline使用和建立的輸入/輸出Artifacts。你也可以為S3 bucket中的Artifacts指定你自己的KMS加密密鑰，或是使用AWS的預設加密密鑰。除了這些設定選項，每個Pipeline還會包含其他階段（stage）的資訊。
一個階段是一個動作的集合。你可以根據你想要的任何標準來組織和隔離不同類型的動作。舉例來說：
各個階段都可以用來構建你想要的Pipeline。唯一必須遵循的要求是，第一階段必須包含一個或多個源碼動作，除此之外沒有其他要求。每個階段至少要有一個動作，最多可有50個動作。集結了不同的動作，而每個動作都執行特定類型的功能。
來源動作(Source Action Type)
這個動作類型只能出現在Pipeline 的第一個階段，從Source Control 如Jenkins/AWS CodeCommit拉入原始碼。下一個動作類型是Build Type，它可以在支援的環境中執行原始碼，這些支援環境包括你要構建應用程式或編譯原始碼的地方。如有需要，你也可以讓任何原始碼在CodeBuild作業上運作。
測試動作(Test Action Type)
自動化部署的一個重要環節是自動化測試。測試動作類型中可以採用許多不同的平台，包括各種協力廠商工具，也可以使用AWS CodeBuild來執行你的測試。
部署動作 (Deploy Action Type)
你可以使用Deploy Action Type來部署原始碼。有許多不同的AWS服務都可以用於部署你的應用程式，包括ECS、ElasticBeanstalk或CodeDeploy。
還有兩個動作類型，也有助於CI/CD 流程。第一個是核准動作類型（Approval Action Type)，它允許你在Pipeline中插入一個手動核准步驟。當你部署到線上環境的Pipeline，並希望有人在新版本實際上線前做一個快速的手動煙霧測試時（smoke test），也可以使用 CodePipeline來執行。
