部署前準備評估

在建立變更請求之前，管道會計算部署就緒度，並將 DEPLOYMENT_READY 標誌設定為 true 或 false。 此旗標源自於 CI 和 CD 階段所收集的證據。 如果任何證據檢查顯示偏差，或與已部署的工件集相關的檢查、掃描或測試遺失或不成功，DEPLOYMENT_READY 設為 false。

變更請求的下列欄位來源於最後一次合併到目標分支的 Promotion PR：

• risk
• impact
• priority
• assignee
• description
• purpose
• customer impact
• deployment impact
• backout plan

變更請求建立

根據 DEPLOYMENT_READY，準備好的變更請求會以兩種初始狀態之一提交：

變更管理系統也會在實施過程中不會造成任何停機時間（停機時間為零），且 DEPLOYMENT_READY 是 true，以及部署風險在可接受範圍內時，自動批准變更請求。

如果您的變更需要計劃的關閉時間，您必須手動建立變更要求，並傳送它以取得核准。 在核准之後，您可以透過提供變更要求 ID 來開始部署。 管道會檢查其核准狀態，然後執行部署。 如需相關資訊，請參閱 手動核准變更要求。

部署前附件

變更請求建立後，管道會立即將下列工件附加到 CR 記錄：

• 部署 BOM- 列出部署中包含的所有元件
• Delta 摘要- 參與部署的所有元件的證據狀況
• 證據檢查組態檔案- 僅在管道中配置了所需的證據檢查基於閘門時附加
• SCC 設定檔- 僅在設定安全與合規設定時附加

批准閘門

如果變更請求是以未核准的方式建立，則會置入未核准狀態，並傳送給人工審核。 在獲得批准之前，不會進行部署。

您可以從管道日誌讀取已建立的變更請求 ID，等待核准，然後使用相同的變更請求 ID 重新啟動部署。 管道會檢查核准狀態，並繼續部署。

部署與驗收測試

當 CR 處於 Implement 狀態時，管道會執行：

• CD 部署- 將程式碼推廣至目標環境
• 驗收測試- 驗證部署結果

這兩個是使用者驅動的執行階段。

部署後 CR 關閉

當部署和驗收測試通過時，管道會附加關閉工件並關閉變更請求：

• 結帳摘要- 目標委託層級所有庫存項目證據的摘要。
• 合併的 SBOM- 庫存中所有元件的部署後軟體物料清單。

然後，CR 會根據 DEPLOYMENT_READY 在關閉時以 close_category 關閉：

變更類型

「變更要求管理」支援兩種類型的變更: 緊急 或 一般。

如果現行變更是緊急變更，請將 emergency 標籤新增至促銷活動取回要求。

CI 管道側沒有緊急流量。 但是，將 CI pipeline/trigger 屬性 skip-inventory-update-on-failure 設定為空值或 0，即使在 CI pipeline 執行中偵測到問題，也可以更新庫存儲存庫。 有了這個更新的庫存，就可以啟動緊急變更。

選擇復原路徑

路徑 1：使用專用的捲回監聽器進行完全捲回

如果存在最後確認良好的組態，也就是先前部署的狀態已確認穩定，那麼服務恢復的最快途徑就是完全回滾。 這會使用專用的回滾監聽器，該監聽器專為此情況而設計，不需要重新建立或升級。

如需逐步說明和要設定的參數，請參閱 使用專用回滾監聽器進行全面回滾。

路徑 2：Fix-forward 作為緊急變更

如果不存在可行的回滾目標，或調查已產生修補程式，則可將修補程式作為緊急變更部署。 此路徑短路了標準的證據閘門邏輯：管道允許變更立即執行，而變更請求則需在事件解決後進行追溯審查與核准。

使用此途徑意味著接受部署到生產的程式碼仍可能包含未解決的弱點或開放的證據缺口。 服務恢復被視為較優先的事項，而未完成的合規項目必須在事件結束後處理。

這兩條路並不互相排斥。 實際上，團隊可能會先啟動全面回退以立即恢復服務，然後在修補程式準備就緒並通過驗證後，再跟進修復轉送。 排序由操作員根據手頭情況判斷。

固定前移程序

若要在 CIE 期間部署修復作為緊急變更，請遵循下列步驟：

1. 重建受影響的元件。 執行 CI 管道，以建立包含修正的新工件版本。 如果 CI 證據檢查因事故狀況而失敗，請將管道或觸發屬性 skip-inventory-update-on-failure 設為空值或 0，允許在失敗的情況下仍更新清單，以便進行緊急變更。

2. 透過環境促進修復。 從最低的環境開始建立升級拉取請求，並向上提升至生產環境。 如果時間允許，在進一步推廣之前，先驗證每個階段的修復效果。 如果情況危急，請直接升級至生產，並在服務恢復後調和較低的環境。

3. 貼上緊急標籤。 在以生產為目標的 promotion pull request 上，新增 emergency 標籤。 這會向管道發出信號，表示應該繞過標準證據閘門，並將變更視為緊急部署。

4. 部署至生產。 執行 CD 管道。 管道會偵測到緊急標籤，跳過核准等待，立即進行部署和驗收測試。 變更請求以 close_category = successful with issues 建立並關閉，反映出該變更是在緊急情況下部署的。

5. 調和較低的環境。 在生產事故解決後，將相同的緊急修復元件部署到較低的環境 - 暫存、預產等 - 以便所有環境都與生產環境處於一致的狀態。 如果在推廣到生產環境之前已驗證了較低層的環境，請確認所有層級都有相同的工件版本。

CIE 後的義務

緊急部署會產生合規義務，這些義務必須在事件結束後處理：

• 變更請求必須經過追溯審查，並由適當的核准人員核准。
• 在緊急情況下接受的任何證據缺口 - 未解決的弱點、不完整的掃描或失敗的檢查 - 都必須加以補救，並在標準條件下重新執行管道。
• 應進行根本原因分析 (RCA)，並將其記錄在案。

變更請求記錄（包括管道所附加的 Delta 摘要、結束摘要和合併 SBOM）可作為 CIE 後審查的主要稽核記錄。

啟用緊急流程

緊急流程由使用者啟動：

1. 使用者執行管道時，會將 emergency 標籤套用在 promotion pull request 上。
2. 管道會偵測到緊急指定，並立即進行部署和驗收測試，無須等待標準核准。
3. 該公司註冊處的結束註釋為 successful with issues。

如果目前的變更是緊急變更，請在執行管道之前，將 emergency 標籤加入 promotion pull request。

緊急事件後的部署

緊急流程完成部署和測試後，會在部署後階段重新加入標準流程：

• 結案摘要和合併的 SBOM 隨附於 CR。
• CR 的關閉遵循與標準流程相同的 DEPLOYMENT_READY-based close_category 邏輯。

如果 CR 種類為 emergency，則變更請求必須在部署後進行追溯審查與核准。

觸發條件

當部署或驗收測試未通過時，會進入內線回溯流程。 然後，管道會評估是否啟用內線回滾：

• Inline-Rollback 未啟用：CR 會以 close_category = unsuccessful 開啟，且管道會退出。 不會嘗試自動恢復。
• 啟用回滾：執行捲回指令碼以回復目標環境，並收集捲回工件附加到 CR。

內聯回滾執行

啟用 Inline-rollback 時，管道：

1. 如果 CD 管道中的部署或驗收測試失敗，則執行內線回滾腳本。
2. 收集下列藝術品：
   • 回滾日誌- 執行回滾腳本的輸出
   • 結束摘要- 反映回滾結果
   • 合併的 SBOM- 回滾後的軟體物料清單
3. 將所有三個工件附加到開啟的 CR 記錄。

回滾後 CR 關閉

inline-rollback 和藝術品附加之後，CR 會以 close_category = unsuccessful 開啟。 這會向變更管理發出信號，表示已嘗試部署，但失敗，並已自動還原。

close_category = unsuccessful 的 CR 是反向部署時預期的正確結果 - 而不是流程失敗的跡象。 作業團隊應使用所附的回滾記錄來調查根本原因。

使用預先核准的變更請求執行管道

您可以使用預先核准的變更請求 (CR) 進行部署。 有兩種可能的情況：

當 CD 管道識別到 CR 是由先前的 CD 管道執行所建立時，它會透過快速路徑進行部署：

• 重複使用從CR證據中預先計算的增量與證據摘要。
• 跳過同儕審查與簽名驗證步驟。
• 部署預先計算的增量。

當 CD 管道無法判斷 CR 是否由較早的 CD 管道執行建立，或所提供的 CR 與目前執行的部署目標不匹配時：

• 它不會重複使用任何預先計算的增量或證據摘要。
• 它不會跳過同行審查或人工簽名驗證。
• 它會從頭開始重新計算 delta 和摘要。
• 它不會建立新的 CR，因為已經提供了一個。

針對失敗的部署重新執行管道

如果您不想要使用自動化變更管理，則可以改為提供先前建立並核准的變更要求。 在下列實務範例中重新執行失敗的部署:

• 最新自動建立的變更請求尚未準備好部署，也未經自動核准。 您已獲得核准，必須使用相同的變更請求重新啟動部署。
• 部署需要關閉時間。 您建立了變更請求，它已獲得核准，而且您遵循了組織的變更管理政策。
• 未變更任何程式碼或配置。 您建立變更請求、解釋變更的內容、獲得核准，並使用核准的變更請求開始部署。

CD 管道完成後，變更請求 (CR) 仍然開啟。

您可以啟動DevSecOps透過使用預先批准的變更請求並輸入變更請求 ID 來引用持續部署管道更改請求 ID 財產。

如果設定了變更 -請求-id 屬性，管道會跳過變更請求的資料收集，繼續檢查核准狀態。 如果 change-request-id 預設設定為 notAvailable，管道會自動建立變更請求。