促銷活動管線

促銷活動管線會將庫存項目從一個環境升級至另一個環境，並建立促銷活動取回/合併要求。

晉升過程中的職責分離

主要透過 Pull Request 工作流程所獲得的晉升
- → 建立推廣 PR（例如：從來源環境分支到目標環境分支）
- → 審閱／編輯 PR（包括檢查 PR 的驗證狀態）
- → 將拉取請求合併至目標環境分支
- → 執行 CD 部署管線（於提交、定時或手動觸發時）
- → 沖洗後，對下一個環境分支重複此步驟
- → 可擁有任意數量的環境分支
角色
- 開發人員：提交程式碼，導致 CI 管道更新主（非生產環境）庫存
- 推廣運作／發布經理：觸發推廣流程（主環境→測試環境及／或測試環境→生產環境），並建立包含狀態檢查以進行門控的拉取請求（透過工具鏈存取控制清單及庫存分支保護機制來強制執行）
- 生產運維／審核人員：審查並將升級的拉取請求合併至生產分支。執行生產環境管道。（透過庫存分支保護機制強制執行）
善用 針對測試環境與生產環境各自獨立的 CD 工具鏈 工作負載（不同的營運模式）
這表示開發人員可以準備一項變更，但如果分支保護機制要求必須由另一人審核，則無法單方面將該變更部署至生產環境。
此推廣公關文件將成為正式的變更核准紀錄，而合併歷史紀錄則可作為可稽核的證據，證明是誰在何時核准了此生產環境的推廣。

促銷活動管線步驟

取得促銷活動和促銷活動取回/合併要求的輸入。
將庫存項目從來源環境升級至目標環境。
建立促銷活動取回/合併要求。編輯取回/合併要求，以指出要執行哪些變更。監看選用及必要欄位。
選用。設定證明狀態，並將聚集證明摘要新增至促銷取回/合併要求。
合併取回/合併要求。
如果特性已開啟，則傳送 Slack 通知。

階段與任務

下表列出了在「推廣」管線中執行的任務。此外，該表格亦針對上述各階段提供了概覽：

任務或階段：此處指的是在 .pipeline-config.yaml 設定檔中定義的階段名稱。
簡要說明：此處簡要說明了在執行該階段時所進行的操作。
允許自訂 ：此選項表示使用者是否可透過在 .pipeline-config.yaml 檔案中插入自訂腳本，來修改或取代該階段的預設行為。
預設參考實作：此項指示 DevSecOps 管道是否針對該階段提供預先定義或預設的實作。值得注意的是，對於某些階段（例如 unit-tests 或 setup ），DevSecOps 流程並未提供任何開箱即用的實作方案。相反地，使用者必須提供根據其應用程式需求量身打造的自訂腳本或程式碼。
證據蒐集：此項用以表明該階段是否進行標準證據的蒐集。當 DevSecOps Pipeline 為某個階段提供參考實作時，系統會預先執行證據蒐集。然而，若使用者選擇修改或替換這些預先定義的階段，則必須確保其自訂實作包含適當的證據蒐集程序。對於 DevSecOps 處理流程未提供現成實作的階段，使用者同樣負有責任，必須自行進行證據蒐集。該欄位標示負責執行證據蒐集的實體（ 使用者／處理流程 ）。
允許跳過（適用於版本 >= v10 ）：此設定表示使用者是否可透過在 .pipeline-config.yaml`` 中將 skip 屬性設為 true，來選擇不執行此階段。然而，使用此功能時應謹慎，特別是針對旨在蒐集證據的階段。若跳過這些階段，可能會導致遺漏建置所需的關鍵證據。

晉升流程的各階段與任務
任務或階段	簡要說明	允許進行客製化的範圍為 `.pipeline-config.yaml`	預設參考實作	證據蒐集	可跳過
`inventory-promotion`	針對此次晉升，請建立拉取請求。	否	是	NA	否
`inventory-finish`	收集並上傳日誌檔案、相關資料及證據至證據儲存庫。	是	否	NA	否

如需進一步了解如何透過 .pipeline-config.yaml 檔案自訂階段，請參閱「自訂腳本」及「管線參數清單」。

執行促銷活動管線

使用手動促銷活動觸發程式來執行促銷活動管線。如果來源 (主要) 分支在目標 (prod) 分支之前，則管線會建立您可以檢閱及編輯的促銷取回/合併要求。如果來源分支落後目標，促銷活動管線會失敗，並出現 All changes have already been promoted 訊息。

若要修改調升取回/合併要求的預設值，或從替代來源調升至目標，使用者可以從「管線環境變數使用者介面」修改輸入。

在執行持續部署管線之前，請確定已合併升級取回/合併要求。您可以在管道日誌中找到拉取 URL /合併請求。

如需庫存和促銷程序的相關資訊，請參閱庫存促銷。

部分促銷庫存商品

部分促銷方法允許促銷管道促銷可用庫存的選定子集。

在此語境下，庫存條目指的是存於庫存儲存庫中的一個單一檔案（屬於庫存類型），該檔案將對應至本地檔案系統上的唯一檔案名稱

使用參數 inventory-include 和 inventory-exclude 啟用部分促銷方法。

使用時 inventory-include，該環境屬性中提供的模式/檔案名稱解析為其各自的條目並由管道提升。同樣，中提供的條目 inventory-exclude 被排除在晉升之外。

此格式使用 glob 模式（也支援完整路徑），類似於 CC 管道中遵循的格式。有關全域模式的更多信息，請參閱全域手動的。

部分促銷中所應用的過濾

部分升級應用兩級過濾 - 使用 .inventoryignore 檔案並根據給定的 glob 模式套用過濾 inventory-include 和 inventory-exclude

使用 .inventoryignore 文件

要預設為每個部分升級運行以及 CD 管道運行排除一組文件或資料夾，您可以將文件/資料夾列表新增至 .inventoryignore 文件以排除這些條目。

從清單中過濾掉條目後，可用條目清單（管道可以提升的條目）可用。.inventoryignore 文件。

管道搜尋 .inventoryignore 檔案位於儲存庫的根目錄。如果您希望為清單排除檔案使用不同的名稱，則可以透過設定來指定它 inventory-ignore-file key 作為管道中的環境屬性。確保該檔案位於庫存儲存庫的根目錄下。

使用 inventory-include 參數

過濾由提供的條目後要推廣的條目列表 inventory-include 和/或 inventory-exclude

如果兩者都 inventory-include 和 inventory-exclude 存在，inventory-include 優先，然後 inventory-exclude 從包含清單定義的子集中排除項目。

如果提供了這些變數之一，管道將嘗試解析 glob 模式的完整路徑或僅解析直接檔案名，並繼續進行部分升級。

管道僅提升兩個過濾等級之間的公共條目清單。

庫存包含和庫存排除參數的用法範例

本節展示了使用 glob 模式並將它們合併到 inventory-include 和 inventory-exclude 參數。以下是庫存儲存庫的範例目錄結構，其中包含微服務、（巢狀）設定檔和 helm 圖表。

cd-pipeline-deps
my-application-plugin-component-config
my-application-plugin-component-diagnostic-monitor
configuration # directory entry
configuration/my-staging-region # directory entry
configuration/my-staging-region/environment-1-cluster # directory entry
configuration/my-staging-region/environment-1-cluster/serviceA-component_config
configuration/my-staging-region/environment-1-cluster/serviceB-system_config
configuration/my-staging-region/environment-1-cluster/serviceC-params_config
configuration/serviceX-dashboard-setup_helm
configuration/serviceY-releases_helm
my-application-task-runner
my-application-dashboard
my-application-dashboard_deployment
my-application-module
my-application-module_deployment
.inventoryignore
global_deployment
README.md

選擇組件的所有子模組條目

inventory-include 設定 :*plugin-component*

選定的庫存條目：

    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor

選擇給定配置資料夾中的所有 helm 圖表

inventory-include 設定 :configuration/*helm

選定的庫存條目：

    configuration/serviceX-dashboard-setup_helm
    configuration/serviceY-releases_helm

選擇特定環境的所有設定檔

inventory-include 設定 :configuration/my-staging-region/environment-1-cluster/*_config

選定的庫存條目：

    configuration/my-staging-region/environment-1-cluster/serviceA-component_config
    configuration/my-staging-region/environment-1-cluster/serviceB-system_config
    configuration/my-staging-region/environment-1-cluster/serviceC-params_config

僅選擇一個組件

inventory-include 設定 :my-application-dashboard*

選定的庫存條目：

    my-application-dashboard
    my-application-dashboard_deployment

在清單包含中使用全域模式的組合

inventory-include 設定 :*plugin-component*,configuration/*helm

選定的庫存條目：

    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor
    configuration/serviceX-dashboard-setup_helm
    configuration/serviceY-releases_helm

在庫存排除中使用 glob 模式的組合

inventory-exclude 設定 :configuration/**, my-application-dashboard*

選定的庫存條目：

    cd-pipeline-deps
    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor
    my-application-task-runner
    my-application-module
    my-application-module_deployment
    .inventoryignore
    global_deployment

促銷活動取回/合併要求

促銷活動取回/合併要求內文中的資訊用來建立變更要求。促銷活動取回/合併要求所變更的檔案代表連續部署管線所部署的項目，例如映像檔。如果因為緊急狀況而進行變更，則會以緊急標籤來標示促銷取回/合併要求。由連續部署管線建立的變更要求也會標示為 emergency。

在連續整合管線中收集的證明會彙總並附加至連續部署管線中的變更要求。

促銷活動驗證管線

開啟促銷活動 PR 之後，您可以選擇性地在「促銷活動」驗證管道中執行證明聚集和摘要產生，並設定促銷活動取回/合併要求 (PR) 的證明狀態。採購申請可由「促銷」管線建立，或在庫存儲存庫中手動建立。

在採購申請合併至目標分支 (環境) 之前，管線可讓您提早驗證促銷採購申請。根據採購申請的狀態，使用者可以繼續進行促銷 (當所有證明狀態都是綠色時)，或選擇在持續整合管線中修正問題 (當證明狀態是紅色時)。

此外，驗證流程還會將清單中一個或多個應用的證據彙總摘要，以使用者友善的表格格式（如圖3所示）附加至提昇拉取/合併請求中作為註解。此表格提供實用連結，例如各應用程式的管線執行連結、應用程式儲存庫連結，以及為其建立的錯誤報告連結。

預設情況下 ，詳細證據狀態表中的每行資料對應於來源儲存庫所提供的應用程式上下文，該儲存庫用於建立清單條目中引用的工件。此應用程式的預設分組功能可依據群組值進行自訂，該值是透過對每個庫存條目檔案套用 JSON 篩選器（定義於屬性中 application-group-by-filter）所獲得。

當正在進行驗證時，會封鎖合併調升取回/合併要求。驗證管線完成之後，會在取回/合併要求上設定證明狀態。按一下狀態中的每一個項目會將使用者帶到對應 CI 管線執行中的特定階段。

階段與任務

下表列出了在「發佈驗證管線」中執行的任務。此外，該表格亦針對上述各階段提供了概覽：

任務或階段：此處指的是在 .pipeline-config.yaml 設定檔中定義的階段名稱。
簡要說明：此處簡要說明了在執行該階段時所進行的操作。
允許自訂 ：此選項表示使用者是否可透過在 .pipeline-config.yaml 檔案中插入自訂腳本，來修改或取代該階段的預設行為。
預設參考實作：此項指示 DevSecOps 管道是否針對該階段提供預先定義或預設的實作。值得注意的是，對於某些階段（例如 unit-tests 或 setup ），DevSecOps 流程並未提供任何開箱即用的實作方案。相反地，使用者必須提供根據其應用程式需求量身打造的自訂腳本或程式碼。
證據蒐集：此項用以表明該階段是否進行標準證據的蒐集。當 DevSecOps Pipeline 為某個階段提供參考實作時，系統會預先執行證據蒐集。然而，若使用者選擇修改或替換這些預先定義的階段，則必須確保其自訂實作包含適當的證據蒐集程序。對於 DevSecOps 處理流程未提供現成實作的階段，使用者同樣負有責任，必須自行進行證據蒐集。該欄位標示負責執行證據蒐集的實體（ 使用者／處理流程 ）。
允許跳過（適用於版本 >= v10 ）：此設定表示使用者是否可透過在 .pipeline-config.yaml`` 中將 skip 屬性設為 true，來選擇不執行此階段。然而，使用此功能時應謹慎，特別是針對旨在蒐集證據的階段。若跳過這些階段，可能會導致遺漏建置所需的關鍵證據。

促銷驗證流程的各階段與任務
任務或階段	簡要說明	允許進行客製化的範圍為 `.pipeline-config.yaml`	預設參考實作	證據蒐集	可跳過
`inventory-validation`	驗證為晉升所提出的拉取請求。	否	是	NA	否
`validation-finish`	收集並上傳日誌檔案、相關資料及證據至證據儲存庫。	是	否	NA	否

如需進一步了解如何透過 .pipeline-config.yaml 檔案自訂階段，請參閱「自訂腳本」及「管線參數清單」。

如何選擇加入促銷活動驗證?

Deprecated 先前用於在拉取請求上自動觸發推廣驗證流程的 opt-in-promotion-validation 選項，現已由 deprecated 取代，改為使用 Git Promotion Validation trigger``。如果您在環境設定中具有此內容，則會在管線日誌及 Slack 通知中看到淘汰通知。

如何啟用升級驗證？

對於所有新的 CD 工具鏈，系統會自動建立「Git 推廣驗證」觸發器，並將其設定為啟用狀態。

若要在現有管線上啟用 Git「升級驗證」觸發程式，您可以使用下列步驟。

移至您要將它新增至其中之 CD 管線的 觸發程式 頁面。
選取 新增> Git 儲存庫，以新增觸發程式。
輸入觸發程式所需的下列資訊:
- 提供觸發程式名稱。例如: Git Promotion Validation Trigger.
- 指定 promotion-validation-listener or promotion-validation-listener-gitlab 作為 EventListener。
- 針對 儲存庫 欄位，選取管線的對應庫存儲存庫。
- 選取分支的目標環境名稱。
- 勾選 開啟或更新取回要求時欄位的方框。
按一下新增。
將觸發程式設為開啟。

輸入

推廣通路投入
變數	說明	預設值	必要或選用
來源環境	促銷活動的來源庫存分支。	`master`	必要
目標環境	促銷活動的目標庫存分支。	`prod`	必要
優先順序	變更的優先順序。	`critical`、`high`、`moderate`、`low` 或 `planning`	選用
受託人	在「變更要求 IBM Cloud 組織」中，要指派變更要求之人員的功能 ID 或電子郵件。	`''`	選用
說明	附加至變更要求說明的變更說明。	`''`	選用
purpose	需要變更的原因。	`''`	選用
影響	更多關於此變更實作所影響的注意事項。	`''`	選用
庫存忽略文件	.inventoryignore 檔案的自訂檔案名，此檔案包含在每次部分升級執行時要忽略的檔案/資料夾清單。	`.inventoryignore`	選用
庫存包括	選擇性促銷（部分促銷）的庫存條目。	`''`	選用
庫存排除	在部分促銷中排除的庫存條目。	`''`	選用
取消計劃	說明如何在失敗中回復變更的計劃。	`''`	選用
松弛通知	開啟或關閉 Slack 整合的開關	0	選用
客戶影響	變更對客戶的影響。	`critical`、`high`、`moderate`、`low` 或 `no_impact`	選用

產出和效果

Slack 通知
促銷活動取回/合併要求

如果未提供選用參數，您必須編輯及修改取回/合併要求。

表格 2.Optional 參數
變數	說明	必要或選用
優先順序	下列其中一個值: `Critical`、`High`、`Moderate`、`Low`、`Planning`	必要
變更要求受託人	受託人的電子郵件 ID。	必要
其他說明	應用程式中變更的相關說明。	選用
目的	對應用程式進行變更的目的。	選用
影響說明	變更對應用程式行為或環境的影響。	選用
客戶影響	下列其中一個值: `Critical`、`High`、`Moderate`、`Low`、`No_Impact`	必要
部署影響	下列其中一個值: `Small`、`Large`	必要
取消計劃	部署失敗時要回復的步驟。	選用

當執行 (選用) 促銷活動 PR 驗證時，會在取回/合併要求上設定證明狀態。

證明的聚集證明摘要 (可能來自庫存中的多個應用程式) 會以表格格式顯示為 PR 中的註解。

在升級拉取和合併請求的評論中捕獲的可選聚合證據摘要 — 升級拉取和合併請求中的聚合證據摘要

推廣拉取請求的自動合併功能

當「推廣驗證管道」中的所有狀態檢查均成功通過時，自動合併功能會自動合併推廣拉取請求。此選用功能可簡化促銷工作流程，因為在驗證完成後，無需再進行手動合併操作。

必要條件

在啟用自動合併功能之前，請確保符合以下要求：

安全性分析：請考慮與您的安全團隊確認，他們是否能接受啟用自動核准功能，且不要求對提升版本的拉取請求進行同儕審查所帶來的風險。各組織應自行決定是否能接受此項安全風險。
推廣流程參數：請確認推廣流程參數已設定適當的預設值。
發布驗證流程：請確保已啟用「發布驗證流程」，並將其設定為在拉取請求事件發生時執行。

以下要求適用於 GitHub 清單儲存庫：

GitHub 儲存庫設定：在 GitHub 儲存庫層級啟用自動合併功能。如需更多資訊，請參閱《管理儲存庫中拉取請求的自動合併》。
分支保護規則：請為清點儲存庫的目標分支設定適當的分支保護規則，以支援自動合併。如需更多資訊，請參閱《自動合併拉取請求》。

啟用自動合併

若要為您的推廣流程啟用自動合併功能：

請在「IBM Cloud」控制台中，導航至您的 CD Promotion 流程。
按一下「環境屬性」以編輯管線或特定觸發器。
新增一個文字屬性，並設定以下值：
- 姓名：enable-auto-merge
- 值：true

若非「true」，其他任何值均會被忽略，且自動合併功能仍保持停用狀態。

自動合併的功能原理

當您在啟用自動合併功能的情況下執行「推廣」管線時，會發生以下工作流程：

「推廣」流程會在庫存儲存庫中建立一個推廣拉取請求。
當拉取請求建立時，晉升驗證流程會自動觸發。
此拉取請求已啟用自動合併功能，待驗證成功後即可生效。
「推廣驗證」流程會對拉取請求執行合規性檢查，並設定狀態檢查。
若所有合規檢查均通過，拉取請求將自動合併。
若任何合規檢查未通過，該拉取請求將保持開啟狀態，並需人工介入處理。

您可以在 GitHub, 的拉取請求頁面上監控自動合併流程的狀態，該頁面會顯示待處理的檢查項目以及自動合併的狀態。

使用自動合併功能時的重要注意事項

啟用自動合併功能以進行至 prod 的部署，表示不會有手動閘門機制來阻止變更從前一個環境流向 prod 環境。因此，必須建立一套流程，以防止在前一個環境尚未成功通過驗證之前，便將資料提升至 prod 環境。在啟用該機制之前，建議您不要在生產環境中啟用自動合併功能，而僅將其用於其他環境，例如 staging。

針對「Git Repos and Issue Tracking」（GRIT）及晉升驗證流程的特別考量

當「Git」的「Promotion Validation」觸發器設定為「Git Repos and Issue Tracking」（ GRIT)/GitLab ）庫存儲存庫時，其「事件觸發」功能需要進行特殊設定。當在某個合併請求上啟用自動合併功能時，系統會建立一個更新事件，該事件將（重新）觸發發布驗證流程。必須透過配置觸發器來防止此預設情況發生，方法是使用如下所示的 CEL 表達式，該表達式已設定為對來自「staging」分支的事件做出反應：

header['x-gitlab-event'] == 'Merge Request Hook' && body.object_attributes.target_branch.matchesGlob('staging')
 && (body.object_attributes.action == 'open' || body.object_attributes.action == 'update' || body.object_attributes.action == 'reopen')
&& (body.object_attributes.source_project_id == body.object_attributes.target_project_id) && !(body.object_attributes.action == 'update' && !body.changes.merge_when_pipeline_succeeds.previous && body.changes.merge_when_pipeline_succeeds.current)

必經步驟

停用從前一階段「Git」觸發的「prod」促銷活動。
建立一個手動管線觸發器，將前一階段的變更推送至 prod 環境，並將「enable-auto-merge」設定為「true」。

可選的實作方法

可以實施各種解決方案。以下是兩種建議的做法：

完成階段驗證：在之前的環境 CD 管道（例如預生產環境）中，請使用 prod-finish 階段來驗證 prod-change-request 或 prod-acceptance-tests （或兩者皆是）是否已成功完成。接著，請使用 Pipeline API 觸發「Promotion」管線，將資料傳送至 prod。
預生產環境證據蒐集：強制執行預生產環境證據蒐集，若在預生產環境證據中發現失敗情況（例如：驗收測試失敗），則將部署至 prod 的流程暫停。

下一步

在「促銷活動管線」順利完成之後，您可以繼續進行 CD 管線。