促销管道
提升管道将库存条目从一个环境提升到另一个环境，并创建提升拉取/合并请求。
晋升过程中的职责分离
-
主要通过 Pull Request 工作流实现的晋升
- → 创建推广 PR（例如：从源环境分支到目标环境分支）
- → 审核/编辑拉取请求（包括检查拉取请求的验证状态）
- → 将 PR 合并到目标环境分支
- → 运行 CD 部署管道（在提交、定时或手动触发时）
- → 冲洗并重复此操作，以处理下一个环境分支
- → 可以拥有任意数量的环境分支
-
角色
- 开发人员：提交代码，从而触发持续集成（CI）管道更新主（非生产环境）库存
- 发布运营/发布经理：触发发布流程（主分支→预发布分支和/或预发布分支→生产分支），创建拉取请求并进行状态检查以控制发布门槛（通过工具链访问控制列表和代码库分支保护机制强制执行）
- 生产运维 / 审批人：审核并将发布拉取请求合并到生产分支。 运行生产管道。（通过库存分支保护强制执行）
-
利用 用于预发布环境和生产环境的独立 CD 工具链 工作负载（不同的运维流程）
-
这意味着开发人员可以准备一个变更，但如果分支保护机制要求必须由另一位审批人批准，则无法单方面将其部署到生产环境。
-
发布PR将成为正式的变更审批记录，而合并历史则提供了可审计的证据，证明是谁在何时批准了生产环境的发布。
促销管道步骤
- 获取促销和促销拉取/合并请求的输入。
- 将库存条目从源环境提升到目标环境。
- 创建提升拉取/合并请求。 编辑拉取/合并请求以指示要执行的更改。 监视可选字段和必填字段。
- 可选。 设置证据状态，并将聚集的证据摘要添加到提升拉取/合并请求。
- 合并拉取/合并请求。
- 如果功能部件已开启，请发送 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 |
为此次推广创建拉取请求。 | 否 | 是 | 不适用 | 否 |
inventory-finish |
收集并上传日志文件、相关资料和证据至证据库。 | 是 | 否 | 不适用 | 否 |
有关如何使用 .pipeline-config.yaml 文件自定义阶段的更多信息，请参阅 “自定义脚本”和“管道参数 列表”。
运行提升管道
使用手动促销触发器来运行促销管道。 如果源 (主) 分支位于目标 (生产) 分支之前，那么管道将创建您可以复审和编辑的提升拉取/合并请求。 如果源分支位于目标后面，那么提升管道将失败并显示 All changes have already been promoted 消息。
要修改提升拉取/合并请求的缺省值，或者要从备用源提升到目标，用户可以从管道环境变量 UI 修改 输入。
在运行持续部署管道之前，请确保已合并提升拉取/合并请求。 您可以在管道日志中找到拉取 URL /合并请求。
有关库存和促销过程的更多信息，请参阅 库存促销。
部分促销库存商品
部分促销方法允许促销渠道促销可用库存的选定子集。
在此语境下，一个库存条目指的是库存仓库中存在的单个文件（属于库存类型），该文件将映射到本地文件系统上的一个唯一文件名
使用参数 inventory-include 和 inventory-exclude 启用部分促销方法。
使用时 inventory-include，该环境属性中提供的模式/文件名解析为其各自的条目并由管道提升。 同样，在 inventory-exclude 被排除在促销之外。
该格式利用 glob 模式（也支持完整路径），类似于 CC-pipeline 中遵循的格式。 有关 glob 模式的更多信息，请参阅 全局手动的。
部分促销中应用的筛选
部分提升应用了两个级别的过滤 - 使用 .inventoryignore 文件并根据给定的 glob 模式应用过滤 inventory-include 和 inventory-exclude
使用 .inventoryignore 文件
若要在每次部分升级运行以及 CD 管道运行中默认排除一组文件或文件夹，您可以将文件/文件夹列表添加到 .inventoryignore 文件来排除这些条目。
从中筛选出条目后，即可获得可用条目列表（管道可以提升的条目）.inventoryignore 文件。
管道搜索 .inventoryignore 文件位于存储库的根目录。 如果您希望为库存排除文件指定不同的名称，您可以通过设置 inventory-ignore-file 作为管道内的环境属性的键。 确保此文件位于库存存储库的根目录。
使用 inventory-include 参数
筛选后可推广的条目列表 inventory-include 和/或 inventory-exclude
如果两者 inventory-include 和 inventory-exclude 存在，inventory-include 优先，然后 inventory-exclude 从包含列表定义的子集中排除项目。
如果提供了其中一个变量，管道将尝试解析 glob 模式的完整路径或仅直接文件名，并继续进行部分提升。
只有两个过滤级别之间的公共条目列表才会被管道提升。
inventory-include 和 inventory-exclude 参数的使用示例
本节展示了使用 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 Chart
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 中使用 glob 模式组合
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
在 inventory-exclude 中使用 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) 上设置证据状态。 PR 可以由促销管道创建，也可以在库存存储库中手动创建。
管道支持在将 PR 合并到目标分支 (环境) 之前对促销 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 |
验证为此次晋升提交的拉取请求。 | 否 | 是 | 不适用 | 否 |
validation-finish |
收集并上传日志文件、相关资料和证据至证据库。 | 是 | 否 | 不适用 | 否 |
有关如何使用 .pipeline-config.yaml 文件自定义阶段的更多信息，请参阅 “自定义脚本”和“管道参数 列表”。
如何选择性加入促销验证?
Deprecated 此前用于在拉取请求上自动触发推广验证管道的 opt-in-promotion-validation 选项已从 deprecated 更改为 Git Promotion Validation trigger。 如果您在环境设置中具有此属性，那么将在管道日志和 Slack 通知中看到废弃通知。
如何启用推广验证？
对于所有新的 CD 工具链，系统会自动创建“Git”推广验证触发器，并将其设置为启用状态。
要在现有管道上启用 Git 促销验证触发器，可以使用以下步骤。
- 转至要将其添加到的 CD 管道的 触发器 页面。
- 选择 添加> Git 存储库 以添加新触发器。
- 输入触发器所需的以下信息:
- 提供触发器名称。 例如: Git 促销验证触发器。
- 将
promotion-validation-listener or promotion-validation-listener-gitlab指定为EventListener。 - 为 存储库 字段的管道选择相应的库存存储库。
- 选择 分支的目标环境的名称。
- 选中 打开或更新拉取请求时字段的框。
- 单击添加。
- 将触发器设置为 On。
输入
| 变量 | 描述 | 缺省值 | 必需或可选 |
|---|---|---|---|
| 源环境 | 促销的源库存分支。 | master |
必需 |
| 目标环境 | 促销的目标库存分支。 | prod |
必需 |
| 优先级 | 更改的优先级。 | critical，high，moderate，low 或 planning |
可选 |
| 受托人 | 要在变更请求 IBM Cloud 组织中向其分配变更请求的人员的功能标识或电子邮件。 | '' |
可选 |
| 描述 | 附加到变更请求描述的变更的描述。 | '' |
可选 |
| 用途 | 需要更改的原因。 | '' |
可选 |
| 影响 | 有关此更改实现的影响的更多说明。 | '' |
可选 |
| 库存忽略文件 | .inventoryignore 文件的自定义文件名，该文件包含每次部分促销运行时要忽略的文件/文件夹列表。 | .inventoryignore |
可选 |
| 库存包括 | 有选择地推广（部分推广）的库存条目。 | '' |
可选 |
| 库存排除 | 部分促销中要排除的库存条目。 | '' |
可选 |
| 回退计划 | 描述如何在故障中回滚更改的计划。 | '' |
可选 |
| Slack-通知 | 用于打开或关闭 Slack 集成的开关 | 0 | 可选 |
| 客户影响 | 更改对客户的影响。 | critical，high，moderate，low 或 no_impact |
可选 |
产出和影响
- Slack 通知
- 提升拉取/合并请求
如果未提供可选参数，那么必须编辑和修改拉取/合并请求。
| 变量 | 描述 | 必需或可选 |
|---|---|---|
| 优先级 | 下列其中一个值: Critical，High，Moderate，Low 和 Planning |
必需 |
| 变更请求受让人 | 受让人的电子邮件标识。 | 必需 |
| 其他描述 | 有关应用程序中的更改的描述。 | 可选 |
| 用途 | 对应用程序进行的更改的用途。 | 可选 |
| 影响说明 | 更改对应用程序行为或环境的影响。 | 可选 |
| Customer Impact | 下列其中一个值: 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”推广验证触发器配置为使用 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)
必经步骤
- 禁用从上一阶段到“
prod”的“Git”触发器。 - 创建一个手动管道触发器，将上一阶段的更改推送到
prod环境，并将“enable-auto-merge”设置为“true”。
可选的实现方法
可以实施各种解决方案。 以下是两种推荐的方法：
-
完成阶段验证：在之前的环境 CD 管道（例如，预生产环境）中，使用
prod-finish阶段来验证prod-change-request或prod-acceptance-tests（或两者）是否已成功完成。 然后，使用管道 API 将“Promotion”管道触发到prod。 -
预生产环境证据收集：强制执行 预生产环境证据收集，若在预生产环境证据中发现失败情况（例如验收测试失败），则阻止向
prod进行部署。
下一步
在提升管道成功完成后，您可以 继续到 CD 管道。