程式碼部署 code-deployment
了解如何部署您的程式碼以及部署時 Cloud Manager 中會發生什麼情況。
使用 Cloud Manager 部署程式碼 deploying-code-with-cloud-manager
在配置生產管道(包括必要的存放庫和環境)後,您就可以部署計畫碼。
-
從 Cloud Manager 按一下 部署,即可開始部署流程。
-
會顯示 管道執行 畫面。按一下 建置,即可開始流程。
建置流程會啟動程式碼部署流程,包括以下步驟:
- 中繼部署
- 中繼測試
- 生產部署
您可以透過檢視紀錄或檢閱測試標準的結果來檢閱各種部署流程的步驟。
部署步驟 deployment-steps
在部署的每個步驟中都會發生許多動作,本節將對此進行說明。 如需有關如何在幕後部署程式碼本身的技術細節,請參閱部署程式詳細資料。
中繼部署步驟 stage-deployment
此 中繼部署 步驟包括下列操作:
中繼測試步驟 stage-testing
此 中繼測試 步驟包括下列操作:
生產部署步驟 production-deployment
生產部署 步驟包括下列動作:
-
申請核准
- 設定管道時會啟用此選項。
- 使用此選項,您可以進行生產部署的排程或按一下 現在,以立即執行生產部署。
-
生產部署排程
-
設定管道時會啟用此選項。
-
排程的日期和時間會根據使用者的時區指定。
-
-
CSE 支援 (如啟用)
-
部署至生產環境
部署完成後,您的程式碼將在其目標環境中,而且您可以檢視紀錄。
逾時 timeouts
如果等候使用者回饋意見,則以下步驟會逾時:
部署流程詳細資訊 deployment-process
Cloud Manager 會將建置流程產生的所有 target/*.zip 檔案上傳到儲存位置。這些成品是在管道的部署階段從該位置擷取的。
當 Cloud Manager 部署到非生產拓撲時,目標是盡快完成部署,因此會將成品同時部署到所有節點,如下所示:
-
Cloud Manager會決定每個成品是AEM或Dispatcher套件。
-
Cloud Manager 會從負載平衡器中移除所有 Dispatcher,以在部署期間隔離環境。
- 除非另有設定,否則您可在開發和測試部署中略過負載平衡器變更。 也就是說,對於開發環境,在兩個非生產管道中分離和附加步驟,而對於中繼環境,則為生產管道。
note note NOTE 預計1-1-1客戶將會使用此功能。 -
每個 AEM 成品都會透過封裝管理員 API (加上決定部署順序的套件相依性) 部署到每個 AEM 執行個體,。
- 瞭解如何使用套件安裝新功能、在執行個體之間傳輸內容及備份存放庫內容的詳細資訊。 請參閱封裝管理員。
note note NOTE 所有 AEM 成品都會部署給作者和發佈者。當需要節點特定的設定時,應利用運行模式。若要瞭解執行模式如何讓您針對特定目的調整AEM執行個體的詳細資訊,請參閱檔案「部署到AEM as a Cloud Service」🔗的「執行模式」一節。 -
Dispatcher成品會依照下列方式部署到每個Dispatcher:
- 會將目前設定備份並複製到暫時的位置。
- 除不可變檔案外,所有設定都將遭到刪除。如需詳細資訊,請參閱Dispatcher設定。 此方法會清除目錄,以確保沒有留下孤立的檔案。
- 成品會被擷取至
httpd
目錄。不可變檔案並不會被覆寫。在部署時,您對Git存放庫中不可變檔案所做的任何變更都將被忽略。 這些檔案是AMS Dispatcher架構的核心,且無法變更。 - Apache 會執行設定測試。如果未發現錯誤,則會重新載入服務。如果發生錯誤,則從備份中還原設定,重新載入服務,並將錯誤回報 Cloud Manager。
- 管道設定中指定的每個路徑都會失效或從Dispatcher快取中排清。
note note NOTE Cloud Manager期望Dispatcher成品包含完整的檔案集。 所有Dispatcher設定檔案都必須存在於Git存放庫中。 缺少檔案或資料夾會導致部署失敗。 -
成功將所有AEM和Dispatcher套件部署到所有節點後,Dispatcher會新增回負載平衡器並完成部署。
note note NOTE 您可以在開發和測試部署中略過負載平衡器變更。 也就是說,對於開發環境,在兩個非生產管道中分離和附加步驟,而對於中繼環境,則為生產管道。
部署至生產階段 deployment-production-phase
部署到生產拓撲的流程會略有不同,以將對AEM網站訪客的影響降至最低。
生產部署通常會遵循和上述相同的步驟,但採用滾動方式:
- 將 AEM 套件部署給作者。
- 將 Dispatcher1 和負載平衡器分離。
- 將AEM套件部署到Publish1並同時將Dispatcher套件部署到Dispatcher1,排清Dispatcher快取。
- 將 Dispatcher1 放回負載平衡器中。
- 一旦 Dispatcher1 重新投入使用,即會將 Dispatcher2 和負載平衡器分離。
- 將AEM套件部署到Publish2並同時將Dispatcher套件部署到Dispatcher2,排清Dispatcher快取。
- 將 Dispatcher2 放回負載平衡器中。
本流程會一直持續到部署已經觸及拓撲中的所有發佈者和 Dispatcher 為止。
緊急管道執行模式 emergency-pipeline
在危急情況下,AdobeManaged Services客戶可能需要立即將程式碼變更部署到他們的中繼和生產環境。 此功能可讓他們略過完整的Cloud Manager測試週期。
為了解決這些情況,可在緊急模式下執行 Cloud Manager 生產管道。使用此模式時,不執行安全性和效能測試步驟。所有其他步驟 (包括任何已設定的核准步驟) 都會按照正常管道執行模式執行。
使用緊急管道執行模式 using-emergency-pipeline
當您啟動生產管道執行時,您可以從對話方塊中選擇正常模式或緊急模式。 如果為方案啟動緊急管道執行模式功能,則此選項可用。 此功能啟用後,即可使用此選項。
以緊急模式檢視管道執行詳細資訊頁面以進行執行時,畫面最上方的階層連結會顯示指示器,表示管道正以緊急模式執行。
以緊急模式執行管道也能透過 Cloud Manager API 或 CLI 完成。若要以緊急模式開始執行,請使用查詢參數 ?pipelineExecutionMode=EMERGENCY
向管道的執行端點提交 PUT
請求,或者在使用 CLI 時:
$ aio cloudmanager:pipeline:create-execution PIPELINE_ID --emergency
重新執行生產部署 reexecute-deployment
在極少數情況下,生產部署步驟可能會因暫時原因而失敗。在這些情況下,只要生產部署步驟已完成,您就可以重新執行生產部署步驟,無論該步驟是成功、取消還是失敗。 使用包含以下三個步驟的同一管道支援重新執行:
- 驗證步驟 — 與正常管道執行期間發生的驗證相同。
- 建置步驟 - 在重新執行的內容中,建置步驟會複製成品,而且實際上並非執行新的建置程序。
- 生產部署步驟 — 使用與正常管道執行中的生產部署步驟相同的設定和選項。
在可以重新執行的情況下,生產管道狀態頁會提供「重新執行」選項 (在一般「下載建置記錄」選項旁)。
限制 limitations
- 重新執行生產部署步驟僅適用於最後執行。
- 重新執行不適用於復原執行或「推送更新」執行。
- 如果最後執行在生產部署步驟之前的任何時候失敗,則無法重新執行。
重新執行 API reexecute-api
除了可在UI中使用之外,您還可以使用Cloud Manager API來觸發重新執行,並識別觸發為重新執行的執行。
觸發重新執行 triggering
若要觸發重新執行,需要向生產部署步驟狀態的 HAL 連結 http://ns.adobe.com/adobecloud/rel/pipeline/reExecute
發出 PUT
請求。
- 如果此連結存在,則可以從該步驟重新開始執行。
- 如果不存在,則無法從該步驟重新開始執行。
此連結僅適用於生產部署步驟。
{
"_links": {
"http://ns.adobe.com/adobecloud/rel/pipeline/logs": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/logs",
"templated": false
},
"http://ns.adobe.com/adobecloud/rel/pipeline/reExecute": {
"href": "/api/program/4/pipeline/1/execution?stepId=2983530",
"templated": false
},
"http://ns.adobe.com/adobecloud/rel/pipeline/metrics": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/metrics",
"templated": false
},
"self": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530",
"templated": false
}
},
"id": "6187842",
"stepId": "2983530",
"phaseId": "1575676",
"action": "deploy",
"environment": "weretail-global-b75-prod",
"environmentType": "prod",
"environmentId": "59254",
"startedAt": "2022-01-20T14:47:41.247+0000",
"finishedAt": "2022-01-20T15:06:19.885+0000",
"updatedAt": "2022-01-20T15:06:20.803+0000",
"details": {
},
"status": "FINISHED"
HAL 連結 href
值的語法只是一個範例,實際值應隨時從 HAL 連結讀取而不是由產生取得。
將PUT
要求提交至此端點會導致201
回應(如果成功)。 回應主體是新執行的表示方式。 此功能類似於透過API開始定期執行。
識別重新執行的執行 identifying
系統會依據觸發程式欄位中的值RE_EXECUTE
識別重新執行的執行。