本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 管道執行的運作方式
<a name="concepts-how-it-works"></a>

本節概述 CodePipeline 處理一組變更的方式。CodePipeline 會追蹤管道手動啟動或變更原始程式碼時啟動的每個管道執行。CodePipeline 使用以下執行模式來處理每個執行在管道中的進度。如需詳細資訊，請參閱[設定或變更管道執行模式](execution-modes.md)。
+ SUPERSEDED 模式：較新的執行可能會覆寫較舊的執行。這是預設值。
+ QUEUED 模式：執行會依佇列順序逐一處理。這需要管道類型 V2。
+ PARALLEL 模式：在 PARALLEL 模式中，執行會同時且獨立執行。執行不會等待其他執行完成，再開始或完成。這需要管道類型 V2。
**重要**  
對於處於 PARALLEL 模式的管道，無法使用階段復原。同樣地，具有復原結果類型的失敗條件無法新增至 PARALLEL 模式管道。

## 管道執行的啟動方式
<a name="concepts-how-it-works-starting"></a>

您可以在變更原始程式碼或手動啟動管道時啟動執行。您也可以透過您排程的 Amazon CloudWatch Events 規則來觸發執行。例如，當原始程式碼變更推送到設定為管道來源動作的儲存庫時，管道會偵測變更並啟動執行。

**注意**  
如果管道包含多個來源動作，則會再次執行所有來源動作，即使只偵測到一個來源動作的變更也是一樣。

## 在管道執行中如何處理來源修訂
<a name="concepts-how-revisions-processed"></a>

對於以原始程式碼變更 （原始程式碼修訂） 開頭的每個管道執行，原始程式碼修訂會如下所示。
+ 對於具有 CodeCommit 來源的管道，在推送遞交時CodePipeline 會複製 HEAD。例如，會推送遞交，這會啟動執行 1 的管道。在推送第二個遞交時，這會啟動執行 2 的管道。
**注意**  
對於具有 CodeCommit 來源的 PARALLEL 模式管道，無論觸發管道執行的遞交為何，來源動作一律會在啟動時複製 HEAD。如需詳細資訊，請參閱[PARALLEL 模式中的 CodeCommit 或 S3 來源修訂可能與 EventBridge 事件不相符](troubleshooting.md#troubleshooting-revisions-parallel)。
+ 對於具有 S3 來源的管道，會使用 S3 儲存貯體更新的 EventBridge 事件。例如，當來源儲存貯體中的檔案更新時，即會產生事件，這會啟動執行 1 的管道。在進行第二個儲存貯體更新的事件時，這會啟動執行 2 的管道。
**注意**  
對於具有 S3 來源的 PARALLEL 模式管道，無論觸發執行的映像標籤為何，來源動作一律會以最新的映像標籤開始。如需詳細資訊，請參閱[PARALLEL 模式中的 CodeCommit 或 S3 來源修訂可能與 EventBridge 事件不相符](troubleshooting.md#troubleshooting-revisions-parallel)。
+ 對於具有 Bitbucket 等連線來源的管道，CodePipeline 會在推送遞交時複製 HEAD。例如，對於 PARALLEL 模式中的管道，會推送遞交，這會啟動執行 1 的管道，而第二個管道執行會使用第二個遞交。

## 來源覆寫如何使用 EventBridge 輸入轉換器
<a name="concepts-how-source-overrides-work"></a>

您可以使用覆寫來啟動具有您為管道執行提供的特定來源修訂 ID 的管道。例如，如果您想要啟動將處理 CodeCommit 來源中特定遞交 ID 的管道，您可以在啟動管道時新增遞交 ID 做為覆寫。

有四種類型的來源修訂`revisionType`：
+ `COMMIT_ID`
+ `IMAGE_DIGEST`
+ `S3_OBJECT_VERSION_ID`
+ `S3_OBJECT_KEY`

**注意**  
對於來源修訂的 `COMMIT_ID`和 `IMAGE_DIGEST`類型，來源修訂 ID 會套用至儲存庫中所有分支的所有內容。

**注意**  
對於來源修訂的 `S3_OBJECT_VERSION_ID`和 `S3_OBJECT_KEY` 類型，其中一種類型可以獨立使用，也可以一起使用，以特定 ObjectKey 和 VersionID 覆寫來源。對於 `S3_OBJECT_KEY`，組態參數`AllowOverrideForS3ObjectKey`需要設定為 `true`。如需 S3 來源組態參數的詳細資訊，請參閱 [組態參數](action-reference-S3.md#action-reference-S3-config)。

您可以使用 EventBridge 中的輸入轉換器來指定來源覆寫。使用輸入轉換器以下列其中一種方式傳遞資料：
+ 您可以使用輸入轉換器，將資料做為 JSON 參數傳遞。
+ 您可以使用輸入轉換器來傳遞管道變數。

如需以 JSON 參數形式傳遞資料的範例，請參閱 [Amazon ECR 來源動作和 EventBridge 資源](create-cwe-ecr-source.md)、[連線至使用 EventBridge 和 的 Amazon S3 來源動作 AWS CloudTrail](create-cloudtrail-S3-source.md)適用於 S3 的 和[CodeCommit 來源動作和 EventBridge](triggering.md)適用於 CodeCommit 的 。

## 管道執行的停止方式
<a name="concepts-how-it-works-stopping"></a>

若要使用主控台來停止管道執行，您可以在管道視覺化頁面、執行歷程記錄頁面或詳細歷程記錄頁面上選擇 **Stop execution (停止執行)**。若要使用 CLI 來停止管道執行，請使用 `stop-pipeline-execution` 命令。如需詳細資訊，請參閱[在 CodePipeline 中停止管道執行](pipelines-stop.md)。

有兩種方式可以停止管道執行：
+ **停止並等待：**允許所有進行中的動作執行完成，且不會啟動後續動作。管道執行不會繼續進行後續階段。您無法在已處於 `Stopping` 狀態的執行上使用此選項。
+ **停止並捨棄：**捨棄所有進行中的動作執行且不會完成，而且不會啟動後續動作。管道執行不會繼續進行後續階段。您可以在已處於 `Stopping` 狀態的執行上使用此選項。
**注意**  
此選項可能會導致工作失敗或工作失序。

每個選項都會產生不同的管道順序和動作執行階段，如下所示。

**選項 1：停止並等待**

當您選擇停止並等待時，選取的執行會繼續進行，直到進行中的動作完成為止。例如，下列管道執行已在建置動作正在進行時停止。

1. 在管道檢視中，會顯示成功訊息橫幅，且建置動作會繼續執行，直到完成為止。管道執行狀態為 **Stopping (停止中)**。

   在歷程記錄檢視中，進行中動作 (例如建置動作) 的狀態為 **In progress (進行中)**，直到建置動作完成為止。當動作正在進行時，管道執行狀態為 **Stopping (停止中)**。

1. 停止程序完成時，執行就會停止。如果成功完成建置動作，其狀態為 **Succeeded (成功)**，且管道執行會顯示 **Stopped (已停止)** 狀態。後續動作不會啟動。**Retry (重試)** 按鈕已啟用。

   在歷程記錄檢視中，執行中的動作完成後，執行狀態為 **Stopped (已停止)**。  
![\[顯示歷史記錄檢視的影像，其中執行狀態會在進行中動作完成後停止\]](http://docs.aws.amazon.com/zh_tw/codepipeline/latest/userguide/images/stop-exec-wait-hist-1.png)

**選項 2：停止並捨棄**

當您選擇停止並捨棄時，選取的執行不會等待進行中的動作完成。這些行動已被捨棄。例如，下列管道執行已在建置動作正在進行時停止並捨棄。

1. 在管道檢視中，會顯示成功橫幅訊息，建置動作會顯示 **In progress (進行中)** 狀態，而管道執行會顯示 **Stopping (停止中)** 狀態。

1. 管道執行停止後，建置動作會顯示 **Abandoned (已捨棄)** 狀態，而管道執行會顯示 **Stopped (已停止)** 狀態。後續動作不會啟動。**Retry (重試)** 按鈕已啟用。

1. 在歷程記錄檢視中，執行狀態為 **Stopped (已停止)**。  
![\[顯示停止執行狀態的歷史記錄檢視的影像\]](http://docs.aws.amazon.com/zh_tw/codepipeline/latest/userguide/images/stop-exec-abandon-hist-1.png)

**停止管道執行的使用案例**

我們建議您使用「停止並等待」選項來停止管道執行。此選項更加安全，因為其可避免管道中可能出現失敗或失序的工作。在 CodePipeline 中捨棄動作時，動作提供者會繼續與動作相關的任何任務。在 CloudFormation 動作的情況下，管道中的部署動作會遭到捨棄，但堆疊更新可能會繼續並導致更新失敗。

作為可能導致out-of-sequence任務的捨棄動作範例，如果您透過 S3 部署動作部署大型檔案 (1GB)，並且選擇在部署進行時停止和捨棄動作，則動作會在 CodePipeline 中捨棄，但會在 Amazon S3 中繼續。Amazon S3 不會遇到取消上傳的任何指示。接下來，如果您使用非常小型的檔案開始新的管道執行，現在有兩個部署正在進行中。由於新執行的檔案大小很小，因此新的部署會在舊的部署仍在上傳時完成。當舊的部署完成時，舊檔案會覆寫新檔案。

在有自訂動作的情況下，您可以使用「停止並捨棄」選項。例如，您可以使用不需要完成的工作來捨棄自訂動作，再啟動錯誤修正的新執行。

## 如何在 SUPERSEDEDED 模式下處理執行
<a name="concepts-how-it-works-executions"></a>

處理執行的預設模式是 SUPERSEDED 模式。執行是由該執行所取用和處理的一組變更組成。管道可同時處理多個執行。每個執行會分別通過管道。管道按順序處理每個執行，且可能以較晚的執行取代較早的執行。下列規則用於處理 SUPERSEDED 模式管道中的執行。

**規則 1：正在處理執行時會鎖定階段**

由於每個階段一次只能處理一個執行，因此階段在進行中會鎖定。當執行完成某個階段時，就會轉換至管道的下一個階段。

![\[顯示進行中階段鎖定的影像\]](http://docs.aws.amazon.com/zh_tw/codepipeline/latest/userguide/images/Promotion.png)


**規則 2：後續執行等待階段解除鎖定**

當階段鎖定時，等待中的執行會停留在鎖定的階段前面。必須先成功完成針對階段所設定的所有動作，再將階段視為完成。失敗會釋放階段的鎖定。當執行停止時，執行不會在階段中繼續進行，並已將階段解除鎖定。

**注意**  
在您停止執行之前，我們建議您停用階段前面的轉換。如此一來，當階段由於停止執行而解除鎖定時，階段就不會接受後續的管道執行。

![\[顯示當階段 2 鎖定時，等待執行如何在階段之間等待的影像\]](http://docs.aws.amazon.com/zh_tw/codepipeline/latest/userguide/images/Waiting.png)


**規則 3：等待中的執行由較新的執行取代**

只會取代階段之間的執行。鎖定的階段會將一個執行扣留在階段前面，以等待階段完成。較新的執行會趕上等待中的執行，並在階段解除鎖定後立即進入下一個階段。被取代的執行不會繼續。在此範例中，「執行 2」在等待鎖定的階段時已被「執行 3」取代。「執行 3」進入下一個階段。

![\[顯示等待執行如何由執行 3 取代的影像\]](http://docs.aws.amazon.com/zh_tw/codepipeline/latest/userguide/images/Batching.png)


如需檢視和切換執行模式之考量的詳細資訊，請參閱 [設定或變更管道執行模式](execution-modes.md)。如需使用執行模式配額的詳細資訊，請參閱 [AWS CodePipeline 中的配額](limits.md)。

## 如何在 QUEUED 模式下處理執行
<a name="concepts-how-it-works-executions-queued"></a>

對於處於 QUEUED 模式的管道，處理執行時會鎖定階段；不過，等待執行不會覆寫已啟動的執行。

等待執行會在進入點收集到鎖定階段，其順序為到達階段，形成等待執行的佇列。透過 QUEUED 模式，您可以在相同的管道中擁有多個佇列。當排入佇列的執行進入階段時，該階段會遭到鎖定，且無法進入其他執行。此行為仍與 SUPERSEDED 模式相同。當執行完成階段時，階段會變為解除鎖定，並準備好進行下一個執行。

下圖顯示 QUEUED 模式管道程序執行中的階段。例如，當來源階段處理執行 5 時，6 和 7 的執行會形成佇列 \$11，並在階段進入點等待。佇列中的下一個執行會在階段解除鎖定後處理。

![\[顯示 QUEUED 模式管道集中執行的圖表。\]](http://docs.aws.amazon.com/zh_tw/codepipeline/latest/userguide/images/Queued-Execution-Mode.png)


如需檢視和切換執行模式之考量的詳細資訊，請參閱 [設定或變更管道執行模式](execution-modes.md)。如需使用執行模式配額的詳細資訊，請參閱 [AWS CodePipeline 中的配額](limits.md)。

## 如何在 PARALLEL 模式下處理執行
<a name="concepts-how-it-works-executions-parallel"></a>

對於處於 PARALLEL 模式的管道，執行彼此獨立，而且在啟動之前不要等待其他執行完成。沒有佇列。若要檢視管道中的平行執行，請使用執行歷史記錄檢視。

在開發環境中使用 PARALLEL 模式，其中每個功能都有自己的功能分支，並部署到其他使用者未共用的目標。

如需檢視和切換執行模式之考量的詳細資訊，請參閱 [設定或變更管道執行模式](execution-modes.md)。如需使用執行模式配額的詳細資訊，請參閱 [AWS CodePipeline 中的配額](limits.md)。

## 管理管道流程
<a name="concepts-how-it-works-transitions-approvals"></a>



管道執行的流程可由以下方式控制：
+ *轉換*，控制執行進入階段的流程。可以啟用或停用轉換。停用轉換時，管道執行無法進入階段。等待進入停用轉換階段的管道執行稱為傳入執行。啟用轉換後，傳入執行會移至階段並鎖定。

  與等待鎖定階段的執行類似，在停用轉換時，等待進入階段的執行仍可由新的執行取代。當停用的轉換重新啟用時，最新的執行 (包括停用轉換時取代較舊執行的任何執行) 會進入階段。
+ *核准動作*，可防止管道轉換至下一個動作，直到授予許可為止 （例如，透過授權身分的手動核准）。例如，當您想要控制管道轉換到最終**生產**階段的時間，您可以使用核准動作。
**注意**  
具有核准動作的階段會鎖定，直到核准動作獲得核准或拒絕，或已逾時為止。逾時核准動作與失敗動作的處理方式相同。
+ *失敗*，當階段中的動作未成功完成時。修訂不會轉換到階段中的下一個動作，或管道中的下一個階段。可能會發生下列情況：
  + 您手動重試包含失敗動作的階段。這將恢復執行 (重試失敗的動作，如果成功，則在階段/管道中繼續)。
  + 另一個執行進入失敗的階段，並取代失敗的執行。此時，無法重試失敗的執行。

### 建議的管道結構
<a name="concepts-recommended-pipeline-method"></a>

決定程式碼變更如何流經管道時，最好將相關動作聚集在一個階段內，以便階段鎖定時，動作全部處理相同的執行。您可以為每個應用程式環境 AWS 區域或可用區域建立階段，以此類推。階段太多的管道 (也就是太細微) 可能允許太多並行變更，而在較大階段中有許多動作的管道 (太粗糙) 可能花太長時間來發行變更。

例如，在同一階段中，如果測試動作在部署動作之後，則保證可測試已部署的相同變更。在此範例中，變更已部署至「測試」環境而後經過測試，然後測試環境的最新變更會部署至「生產」環境。在建議的範例中，「測試」環境和「生產」環境是不同的階段。

![\[此圖顯示兩個類型的分階段動作分組，建議選項位於左側\]](http://docs.aws.amazon.com/zh_tw/codepipeline/latest/userguide/images/structure-example-recommended-notrecommended.png)


### 傳入執行的運作方式
<a name="how-it-works-inbound-executions"></a>

傳入執行是在向前移動之前等待無法使用階段、轉換或動作變成可用的執行。下一個階段、轉換或動作可能無法使用，因為：
+ 另一個執行已進入下一個階段並鎖定它。
+ 進入下一個階段的轉換已停用。

如果您想要控制目前執行是否有時間在後續階段完成，或是想要在特定時間點停止所有動作，您可以停用轉換以保留傳入執行。若要判斷您是否具有傳入執行，您可以在 主控台中檢視管道，或從 **get-pipeline-state**命令檢視輸出。

傳入執行的操作考量如下：
+ 一旦動作、轉換或鎖定的階段可用，進行中的傳入執行就會進入階段，並繼續進行管道。
+ 當傳入執行正在等待時，可以手動停止。傳入執行可以具有 `InProgress`、 `Stopped`或 `Failed` 狀態。
+ 當傳入執行停止或失敗時，無法重試，因為沒有失敗的動作可重試。當傳入執行停止且啟用轉換時，停止的傳入執行不會繼續進入階段。

您可以檢視或停止傳入執行。