管道執行的運作方式

本節提供 CodePipeline 處理一組變更的方式概觀。 CodePipeline追蹤手動啟動管線或對原始程式碼進行變更時啟動的每個管線執行。 CodePipeline 使用以下執行模式來處理每個執行在管道中進行的方式。

• SUPERSEDEDmode：更近的執行可能會超過較舊的執行。此為預設值。

• QUEUEDmode：執行按照排隊的順序逐個處理。這需要管線類型 V2。

• PARALLELmode：在PARALLEL模式下，執行同時運行，彼此獨立。在開始或完成之前，執行不會等待其他運行完成。這需要管線類型 V2。

管道執行的啟動方式

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

注意

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

管線執行中如何處理來源修訂

對於以原始程式碼變更 (來源修訂) 開始的每個管線執行，來源修訂的決定方式如下。

• 對於具有 CodeCommit 來源的HEAD管線，會 CodePipeline在推送提交時複製。例如，推送一個提交，這會啟動執行 1 的管道。在推送第二次提交時，這將啟動執行 2 的管道。

  注意

  對於具有 CodeCommit 源PARALLEL模式的管道，無論觸發管道執行的提交為何，源動作將始終在啟動時克隆。HEAD如需詳細資訊，請參閱CodeCommit 或PARALLEL模式下的 S3 來源修訂可能不符合 EventBridge 事件 。

• 對於具有 S3 來源的管道，會使用 S3 儲存貯體更新的 EventBridge 事件。例如，當來源值區中的檔案更新時，會產生事件，此值區會啟動管道以執行 1。在進行第二個值區更新的事件時，這會啟動執行 2 的管道。

  注意

  對於具有 S3 來源PARALLEL模式的管道，無論觸發執行的映像標記為何，來源動作都將始終以最新的映像標記開始。如需詳細資訊，請參閱CodeCommit 或PARALLEL模式下的 S3 來源修訂可能不符合 EventBridge 事件 。

• 對於具有連線來源的管線 (例如至 Bitbucket)，HEAD則會 CodePipeline 在推送提交時複製。例如，對於PARALLEL模式中的管道，會推送一個提交，這會啟動管道以執行 1，而第二個管線執行則使用第二次提交。

管道執行的停止方式

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

有兩種方式可以停止管道執行：

• 停止並等待：允許所有進行中的動作執行完成，且不會啟動後續動作。管道執行不會繼續進行後續階段。您無法在已處於 Stopping 狀態的執行上使用此選項。

• 停止並捨棄：捨棄所有進行中的動作執行且不會完成，而且不會啟動後續動作。管道執行不會繼續進行後續階段。您可以在已處於 Stopping 狀態的執行上使用此選項。

  注意

  此選項可能會導致工作失敗或工作失序。

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

選項 1：停止並等待

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

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

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

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

   在歷程記錄檢視中，執行中的動作完成後，執行狀態為 Stopped (已停止)。

   

選項 2：停止並捨棄

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

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

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

3. 在歷程記錄檢視中，執行狀態為 Stopped (已停止)。

   

停止管道執行的使用案例

我們建議您使用「停止並等待」選項來停止管道執行。此選項更安全，因為它可以避免可能的失敗或管道中的 out-of-sequence 任務。中放棄動作時 CodePipeline，動作提供者會繼續與動作相關的任何工作。在 AWS CloudFormation 動作的情況下，管線中的部署動作會放棄，但堆疊更新可能會繼續進行，並導致更新失敗。

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

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

如何在模式下SUPERSEDED處理執行

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

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

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

之前：Stage 1 is locked as Execution 1 enters. 之後： Stage 2 is locked as Execution 1 enters.

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

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

注意

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

之前： Stage 2 is locked as Execution 1 enters. 之後： Execution 2 exits Stage 1 and waits between stages.

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

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

之前：執行2 在階段之間等待，而執行 3 進入階段 1。 之後：執行 3 離開階段 1。執行 3 取代了執行 2。

如需檢視和切換執行模式之間的考量事項的詳細資訊，請參閱設定或變更配管執行模式。如需執行模式配額的詳細資訊，請參閱配額 AWS CodePipeline。

如何在模式下QUEUED處理執行

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

等待的執行按照它們到達階段的順序在入口點聚集到鎖定階段，形成了等待執行的隊列。使用QUEUED模式，您可以在同一管道中擁有多個佇列。當排入佇列的執行項目進入階段時，階段會被鎖定，且無法進入其他執行項目。此行為與SUPERSEDED模式保持相同。當執行完成階段時，階段會變成解除鎖定，並準備好進行下一次執行。

下圖顯示了如何在QUEUED模式管道過程執行階段。例如，當「來源」階段處理程序執行 5 時，6 和 7 的執行會形成佇列 #1，然後在階段進入點等候。階段解鎖後，將處理佇列中的下一個執行。

如需檢視和切換執行模式之間的考量事項的詳細資訊，請參閱設定或變更配管執行模式。如需執行模式配額的詳細資訊，請參閱配額 AWS CodePipeline。

如何在模式下PARALLEL處理執行

對於PARALLEL模式下的管道，執行是彼此獨立的，並且在開始之前不要等待其他執行完成。沒有佇列。若要檢視管線中的 parallel 執行，請使用執行歷史記錄檢視。

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

如需檢視和切換執行模式之間的考量事項的詳細資訊，請參閱設定或變更配管執行模式。如需執行模式配額的詳細資訊，請參閱配額 AWS CodePipeline。

管理配管流

管道執行的流程可由以下方式控制：

• 轉換，控制執行進入階段的流程。可以啟用或停用轉換。停用轉移時，管線執行將無法進入階段。等待進入禁用轉換的階段的管道執行稱為入站執行。啟用轉換之後，輸入執行會移至階段並鎖定它。

  與等待鎖定階段的執行類似，在停用轉換時，等待進入階段的執行仍可由新的執行取代。當停用的轉換重新啟用時，最新的執行 (包括停用轉換時取代較舊執行的任何執行) 會進入階段。

• 核准動作，可防止管線轉換至下一個動作，直到授與權限為止 (例如，透過授權身分的手動核准)。例如，當您想要控制管道轉換到最終生產階段的時間，您可以使用核准動作。

  注意

  具有核准動作的階段會鎖定，直到核准動作獲得核准或拒絕，或已逾時為止。逾時核准動作與失敗動作的處理方式相同。

• 失敗，當階段中的動作未成功完成時。修訂不會轉換到階段中的下一個動作，或管道中的下一個階段。可能會發生下列情況：

  • 您手動重試包含失敗動作的階段。這將恢復執行 (重試失敗的動作，如果成功，則在階段/管道中繼續)。

  • 另一個執行進入失敗的階段，並取代失敗的執行。此時，無法重試失敗的執行。

建議的管道結構

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

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

左邊：相關的測試、部署和核准動作組合在一起 (建議)。右邊：相關動作分屬不同階段 (不建議)。

入站執行的工作方式

輸入執行是等待無法使用的階段、轉移或動作在向前移動之前變成可用的執行。下一個階段、轉場或動作可能無法使用，因為：

• 另一個執行已經進入下一個階段並將其鎖定。

• 進入下一個階段的轉換已停用。

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

輸入執行作業時需考量下列事項：

• 一旦動作、轉移或鎖定階段可用，進行中的輸入執行就會進入階段，並透過管線繼續進行。

• 當入站執行正在等待時，可以手動停止。入站執行可以具有InProgressStopped、或Failed狀態。

• 當輸入執行已停止或失敗時，無法重試，因為沒有失敗的動作可重試。當輸入執行已停止並啟用轉換時，已停止的輸入執行不會繼續進入階段。

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