：發布單對接說明

什麼是發布單

基本概念

發布單是貫穿整個SAE的流程處理引擎。您在使用SAE營運您的應用時，必定會接觸到發布單相關的功能。當前SAE同一應用的發布單為應用層級的串列執行，即同一個應用的發布單尚未完結前，不允許再運行這個應用的另外一個發布單流程。

為什麼同一應用的發布單不支援並行

• 彈性情境

  在SAE應用的發布、擴縮容情境下需要禁用彈性規則，否則會出現一系列不可預期的問題。如果此時有多個發布單並行，就會出現A發布單禁用了彈性，在A發布單未完結之前，B發布單又啟動了彈性的情況。如果啟用彈性規則的期間，發生了擴縮容的動作，發布單本身的擴縮容會表現出與預期不符的現象。

• 發布和復原情境

  發布和復原情境都會產生一個版本的底層資源描述檔案。如果此時有多個發布單並行，可能會讓您部署的應用出現超過2個版本，不符合SAE預期最多隻出現2個版本的要求。

發布單介面調用情境說明

發布單介面調用主要針對需要通過API部署到SAE的情境。本文以發布情境為例，介紹如何確認發布單操作是否成功。發布情境是最複雜的發布單情境，如果您想確認其他情境的發布單是否操作成功，方法基本一致。

確認發布單操作是否成功

1. 調用CreateApplication或DeployApplication等介面，如果返回資料中Success參數值為true，Code參數值為200，則同時會返回ChangeOrderId參數。
2. 調用DescribeChangeOrder介面，傳入對應的ChangeOrderId參數，擷取返回資料。
3. 根據返回資料中的Status參數進行判斷，如果值為2（執行成功），則說明發布單操作成功。

需要復原的發布情境

• 單批發布

  單批發布失敗或者中止時，SAE不會進行自動復原。您可以按需自行調用RollbackApplication介面實現復原。當您調用DescribeChangeOrder介面，擷取的返回資料中Status參數值為3（執行失敗）或者10（系統異常執行失敗）時，則說明發布單執行失敗。

• 灰階或者分批發布

  發布單失敗，會觸發自動復原到上一個版本的操作。

  需要人工介入的情境如下：當發布單擷取的Status參數值為1（執行中）、SubStatus參數值為1（發布異常）時，您需要自行調用AbortAndRollbackChangeOrder介面去中止發布單。

操作灰階和分批發布

此情境僅適用於分批發布策略手動分批的情況。調用了灰階或者分批發布後，您需要等待多批發布的上一批完成後，才能進行下一批次的操作。

1. 調用DeployApplication介面，擷取ChangeOrderId。
2. 調用DescribeChangeOrder介面，傳入對應的ChangeOrderId，擷取返回資料。
3. 返回的Status參數值為8時（等待手工確認分批），可調用ConfirmPipelineBatch介面繼續發布。ConfirmPipelineBatch介面需要PipelineId參數（開始下一批次的參數）。DescribeChangeOrder介面的返回資料中，包含CurrentPipelineId和Pipelines兩個參數，其中Pipelines是一個集合。該步驟可進行迴圈，迴圈內的PipelineId和CurrentPipelineId相同的下一個PipelineId即ConfirmPipelineBatch所需的參數。

發布單流程設計邏輯

為什麼發布單失敗不能恢複彈性

• 發布和復原情境

  發布單的執行順序是先禁用彈性，等發布單執行成功時，再恢複彈性規則。如果發布單執行失敗，則SAE不會自動回復彈性規則。因為發布過程中存在多個版本，SAE無法判斷需要運行新版本還是舊版本。

• 擴縮容情境

  發布彈性規則可能會和您的擴縮容操作衝突。例如當前應用內有10個執行個體，您想手動縮容到5個，但是彈性規則檢測到此時需要擴容到15個，便會引起衝突。因此擴縮容情境需要禁用彈性規則。

為什麼多批發布失敗會自動復原

多批發布存在多個批次，如果一次發布成功了一部分，那麼此時便有兩個版本共存的執行個體了。如果此時發布單失敗，但是僅中止不復原的話，那麼下次再發布的時候，可能會存在三個版本的執行個體，會出現預期外的情況。因此SAE必須保證您的執行個體最多存在兩個版本。