本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# CodePipeline 概念
如果您了解 中使用的概念和術語，模型化和設定自動發行程序會更輕鬆 AWS CodePipeline。以下是使用 CodePipeline 時需要了解的一些概念。
如需 DevOps 管道的範例，請參閱 [DevOps 管道範例](concepts-devops-example.md)。
下列術語用於 CodePipeline：
**Topics**
+ [管道](#concepts-pipelines)
+ [管道執行](#concepts-executions)
+ [階段操作](#concepts-stage-executions)
+ [動作執行](#concepts-action-executions)
+ [執行類型](#concepts-execution-types)
+ [動作類型](#concepts-action-types)
+ [成品](#concepts-artifacts)
+ [來源修訂](#concepts-source-revisions)
+ [觸發](#concepts-triggers)
+ [Variables](#concepts-variables)
+ [條件](#concepts-conditions)
+ [Rules](#concepts-rules)
## 管道
「管道」**是一個工作流程建構，說明軟體變更如何進行發行程序。每個管道由一系列的*階段*組成。
### 階段
階段是一種邏輯單元，可用來隔離環境，並限制該環境中並行變更的數目。每個階段都包含對應用程式[成品](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts)執行的動作。原始程式碼就是成品的例子。階段可能是建置原始程式碼和執行測試的建置階段。也可能是程式碼部署到執行時間環境的部署階段。每個階段由一系列的序列或平行*動作*組成。
### 轉換
*轉換*是管道執行在管道中移至下一個階段的點。您可以停用階段的進入轉換，以防止執行進入該階段，然後啟用轉換以允許執行繼續。當一個以上的執行到達停用的轉換時，只有最新的執行會在啟用轉換時繼續到下一個階段。這表示在停用轉換時，較新的執行會繼續取代等待的執行，然後在啟用轉換之後，繼續的執行就是取而代之的執行。
![\[管道包含階段 (階段包含動作)，由可停用和啟用的轉換所區隔。\]](http://docs.aws.amazon.com/zh_tw/codepipeline/latest/userguide/images/pipeline-elements-workflow.png)
### 動作
*動作*是一組對應用程式程式碼執行的操作，並設定為在管道中的指定點執行動作。其中可能包括來自程式碼變更的來源動作、將應用程式部署到執行個體的動作等等。例如，部署階段可能包含部署動作，可將程式碼部署到 Amazon EC2 或 等運算服務 AWS Lambda。
有效的 CodePipeline 動作類型為 `source`、`build`、`test`、`deploy`、 `approval`和 `invoke`。如需動作提供者的清單，請參閱[CodePipeline 中的有效動作提供者](actions-valid-providers.md)。
動作可以串聯或平行執行。如需階段中序列和平行動作的相關資訊，請參閱[動作結構需求](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-pipeline-structure.html#action-requirements)中`runOrder`的資訊。
## 管道執行
*執行*是一組由管道發行的變更。每個管道執行都是唯一的，並且有自己的 ID。一個執行對應於一組變更，例如合併遞交或手動發行最新遞交。兩個執行可以在不同時間發行同一組變更。
一個管道可以同時處理多個執行，但管道階段一次只處理一個執行。為了這樣做，在階段處理執行時會鎖定階段。兩個管道執行不能同時佔據同一階段。等待進入佔用階段的執行稱為*傳入執行*。傳入執行仍然可能會失敗、被取代或手動停止。如需傳入執行如何運作的詳細資訊，請參閱 [傳入執行的運作方式](concepts-how-it-works.md#how-it-works-inbound-executions)。
管道執行按順序周遊管道階段。管道的有效狀態為 `InProgress`, `Stopping`、`Stopped`、`Succeeded`、`Superseded` 和 `Failed`。
如需詳細資訊，請參閱 [PipelineExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineExecution.html)。
### 已停止的執行
您可以手動停止管道執行，讓進行中的管線執行不會透過管道繼續執行。如果手動停止，管道執行會在完全停止前顯示 `Stopping` 狀態。然後會顯示 `Stopped` 狀態。您可以重試 `Stopped` 管道執行。
有兩種方式可以停止管道執行：
+ **停止並等待**
+ **停止並捨棄**
如需停止執行的使用案例和這些選項的順序詳細資訊，請參閱 [管道執行的停止方式](concepts-how-it-works.md#concepts-how-it-works-stopping)。
### 失敗的執行
如果執行失敗，則會停止且不會完全周遊管道。狀態為 `FAILED`，且階段會解除鎖定。最近的執行可以趕上，並進入未鎖定的階段來鎖定它。除非失敗的執行已被取代或無法重試，否則您可以重試失敗的執行。您可以將失敗的階段復原至先前的成功執行。
### 執行模式
若要透過管道傳遞一組最新的變更，較新的執行會通過並取代管道中較早以前的執行。發生這種情況時，較新的執行會取代較舊的執行。一個執行可以由較新的執行在某個點取代，即階段之間的點。SUPERSEDED 是預設執行模式。
在 SUPERSEDED 模式中，如果執行正在等待進入鎖定階段，較新的執行可能會追上並取代它。較新的執行現在會等待階段解除鎖定，而被取代的執行會停止並處於 `SUPERSEDED` 狀態。當管道執行被取代時，執行會停止，且不會完全周遊管道。在此階段換掉被取代的執行之後，您就無法再重試被取代的執行。其他可用的執行模式為 PARALLEL 或 QUEUED 模式。
如需執行模式和鎖定階段的詳細資訊，請參閱 [如何在 SUPERSEDEDED 模式下處理執行](concepts-how-it-works.md#concepts-how-it-works-executions)。
## 階段操作
當管道執行執行階段時，該階段正在完成其中的所有動作。如需階段操作運作方式的相關資訊，以及鎖定階段的相關資訊，請參閱 [如何在 SUPERSEDEDED 模式下處理執行](concepts-how-it-works.md#concepts-how-it-works-executions)。
階段的有效狀態為 `InProgress`、`Stopping`、`Succeeded`、 `Stopped`和 `Failed`。除非無法重試失敗的階段，否則您可以重試失敗的階段。如需詳細資訊，請參閱 [StageExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageExecution.html)。您可以將階段復原至先前成功的指定執行。階段可設定為在失敗時自動復原，如 中所述[設定階段復原](stage-rollback.md)。如需詳細資訊，請參閱 [RollbackStage](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RollbackStage.html)。
## 動作執行
「動作執行」**是已設定的動作在指定[成品](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts)上完成運作的過程。可能是輸入成品、輸出成品，或兩者都是。例如，建置動作可能在輸入成品上執行建置命令，例如編譯應用程式原始程式碼。動作執行詳細資訊包括動作執行 ID、相關的管道執行來源觸發，以及動作的輸入和輸出成品。
動作的有效狀態為 `InProgress`、`Succeeded`、 `Abandoned`或 `Failed`。如需詳細資訊，請參閱 [ActionExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionExecution.html)。
## 執行類型
管道或階段執行可以是標準或復原執行。
對於標準類型，執行具有唯一的 ID，並且是完整的管道執行。管道轉返具有要轉返的階段，以及階段的成功執行作為要轉返的目標執行。目標管道執行用於擷取要重新執行階段的來源修訂和變數。
## 動作類型
*動作類型*是預先設定的動作，可在 CodePipeline 中選擇。動作類型是由其擁有者、提供者、版本和類別所定義。動作類型提供自訂參數，用於完成管道中的動作任務。
如需您可以根據動作類型整合到管道 AWS 服務 的 和第三方產品和服務的相關資訊，請參閱 [與 CodePipeline 動作類型的整合](integrations-action-type.md)。
如需 CodePipeline 中動作類型支援之整合模型的相關資訊，請參閱 [整合模型參考](reference-integrations.md)。
如需有關第三方供應商如何在 CodePipeline 中設定和管理動作類型的資訊，請參閱 [使用動作類型](action-types.md)。
## 成品
*成品*是由管道動作處理的資料集合，例如應用程式原始程式碼、建置的應用程式、相依性、定義檔案、範本等。成品由某些動作產生，並由其他動作取用。在管道中，成品可能是動作處理的一組檔案 (*輸入成品*)，或已完成的動作所更新的輸出 (*輸出成品*)。
動作會將輸出傳遞至另一個動作，以便使用管道成品儲存貯體進一步處理。CodePipeline 會將成品複製到成品存放區，動作會在該存放區中收取成品。如需成品的詳細資訊，請參閱 [輸入和輸出成品](welcome-introducing-artifacts.md)。
## 來源修訂
進行原始程式碼變更時會建立新版本。*來源修訂*是觸發管道執行的來源變更版本。執行會處理來源修訂。對於 GitHub 和 CodeCommit 儲存庫，這是遞交。對於 S3 儲存貯體或動作，這是物件版本。
您可以使用您指定的來源修訂啟動管道執行，例如遞交。執行會處理指定的修訂，並覆寫用於執行的修訂。如需詳細資訊，請參閱[使用來源修訂覆寫啟動管道](pipelines-trigger-source-overrides.md)。
## 觸發
*觸發條件*是啟動管道的事件。有些觸發條件，例如手動啟動管道，可供管道中的所有來源動作提供者使用。某些觸發條件取決於管道的來源提供者。例如，CloudWatch 事件必須使用來自 Amazon CloudWatch 的事件資源進行設定，該資源已在事件規則中將管道 ARN 新增為目標。對於具有 CodeCommit 或 S3 來源動作的管道，Amazon CloudWatch Events 是自動變更偵測的建議觸發條件。Webhook 是針對第三方儲存庫事件設定的觸發類型。例如，WebhookV2 是一種觸發類型，允許使用 Git 標籤啟動具有第三方來源提供者的管道，例如 GitHub.com,GitHub Enterprise Server、GitLab.com,GitLab 自我管理或 Bitbucket Cloud。在管道組態中，您可以指定觸發條件的篩選條件，例如推送或提取請求。您可以在 Git 標籤、分支或檔案路徑上篩選程式碼推送事件。您可以篩選事件 （開啟、更新、關閉）、分支或檔案路徑的提取請求事件。
關於觸發條件的詳細資訊，請參閱 [在 CodePipeline 中啟動管道](pipelines-about-starting.md)。如需逐步引導您使用 Git 標籤做為管道觸發條件的教學課程，請參閱 [教學課程：使用 Git 標籤啟動您的管道](tutorials-github-tags.md)。
**重要**
處於非作用中狀態超過 30 天的管道會停用管道的輪詢。如需詳細資訊，請參閱管道結構參考中的[pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)。如需將管道從輪詢遷移至事件型變更偵測的步驟，請參閱[變更偵測方法](change-detection-methods.md)。
## Variables
*變數*是可用來在管道中動態設定動作的值。變數可以在管道層級宣告，或由管道中的動作發出。變數值會在管道執行時解析，並且可以在執行歷史記錄中檢視。對於在管道層級宣告的變數，您可以在管道組態中定義預設值，或針對指定的執行覆寫它們。對於 動作發出的變數，該值在動作成功完成後可用。如需詳細資訊，請參閱[變數參考](reference-variables.md)。
## 條件
*條件*包含一組已評估的規則。如果條件中的所有規則都成功，則符合條件。您可以設定條件，以便在不符合條件時，指定結果，例如階段失敗時，會進行互動。條件也稱為閘道，因為它們可讓您指定執行進入和執行階段的時間，或在執行階段之後結束階段。這類似於允許道路上的一行流量在關閉的大門收集，然後指定大門的開啟，以允許流量流入 區域。條件類型的結果包括階段失敗或復原階段。條件可協助您指定這些動作何時發生在管道階段。您可以在執行時間覆寫條件。
條件有三種類型。進入條件回答問題「如果符合條件的規則，則輸入階段。」 執行進入階段時會鎖定階段，然後執行規則。對於失敗條件，規則會在階段失敗時啟動，因為轉返失敗階段的結果。對於成功條件，規則會在階段成功時啟動，例如在繼續之前檢查警示是否成功執行。例如，如果 CloudWatchAlarm 規則發現部署環境中有警示，則 On Success 條件將導致復原成功階段。如需詳細資訊，請參閱[階段條件如何運作？](concepts-how-it-works-conditions.md)。
## Rules
條件使用一或多個預先設定的*規則*來執行和執行檢查，然後在不符合條件時，讓設定的 結果參與其中。例如，符合檢查警示狀態和部署時段時間的進入條件規則的所有規則，將在所有檢查通過後部署成功的階段。如需詳細資訊，請參閱[階段條件如何運作？](concepts-how-it-works-conditions.md)。