部署前准备状态评估

在创建变更请求之前，管道会计算部署就绪程度，并将 DEPLOYMENT_READY 标志设置为 true 或 false。 该标志来自于在传播和信息阶段以及 CD 阶段收集到的证据。 如果任何证据检查显示存在偏差，或与已部署的工件集相关的检查、扫描或测试缺失或不成功，DEPLOYMENT_READY 设置为 false。

变更请求中的以下字段来自最后一次合并到目标分支的“推广 PR”：

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

创建变更请求

准备好的变更申请是在两种初始状态之一提交的，具体取决于 DEPLOYMENT_READY：

当实施过程不会造成任何停机（停机时间为零），DEPLOYMENT_READY，true，且部署风险在可接受范围内时，变更管理系统也会自动批准变更请求。

如果您的更改需要计划的停机时间，那么必须手动创建变更请求并将其发送以进行核准。 核准后，您可以通过提供变更请求标识来启动部署。 管道会检查其批准状态，然后运行部署。 有关更多信息，请参阅 手动核准变更请求。

部署前附件

创建变更请求后，管道会立即将以下工件附加到 CR 记录：

• 部署 BOM- 列出部署中包含的所有组件
• Delta 总结- 参与部署的所有组件的证据态势
• 证据检查配置文件- 仅当管道中配置了所需的基于证据检查的门控时才附加
• SCC 配置文件- 仅在配置了安全与合规性配置时才附加

审批门

如果变更申请创建为“未批准”，则会处于未批准状态，并发送给人工审核。 在获得批准之前不会进行部署。

您可以从管道日志中读取已创建的变更请求 ID，等待批准，然后使用相同的变更请求 ID 重新启动部署。 管道会检查批准状态并继续部署。

部署和验收测试

当 CR 处于执行状态时，流水线开始执行：

• CD 部署- 将代码推广到目标环境
• 验收测试- 验证部署结果

这两个是用户驱动的运行阶段。

部署后 CR 关闭

当部署和验收测试通过后，管道会附加关闭工件并关闭变更请求：

• 结账摘要- 目标提交级别所有库存条目的证据摘要。
• 合并的 SBOM- 库存中所有组件的部署后软件物料清单。

然后，根据 DEPLOYMENT_READY 关闭时的 close_category 关闭 CR：

更改类型

变更请求管理支持两种类型的变更: 紧急 或 常规。

如果当前变更是紧急变更，请将 emergency 标签添加到提升拉取请求。

CI 管道一侧没有紧急流量。 不过，将 CI 管道/触发器属性 skip-inventory-update-on-failure 设置为空值或 0，即使在 CI 管道运行中检测到问题，也能更新清单存储库。 有了这些更新的清单，就可以启动紧急变更。

选择康复之路

路径 1：使用专用回滚监听器进行全面回滚

如果存在“最后已知良好配置”，即先前部署的状态已确认稳定，那么恢复服务的最快途径就是完全回滚。 这使用的是专门为这种情况设计的回滚监听器，不需要重新构建或升级。

有关分步说明和要配置的参数，请参阅 使用专用回滚监听器进行全面回滚。

路径 2：作为紧急变更的“固定-前移”方案

如果不存在可行的回滚目标，或者调查已经产生了补丁，则可将修复作为紧急变更部署。 这条路径短路了标准的证据把关逻辑：管道允许立即实施变更，而变更请求则要在事件解决后进行追溯审查和批准。

使用这种方法意味着接受部署到生产中的代码可能仍然包含未解决的漏洞或开放的证据缺口。 恢复服务被视为更优先的事项，未完成的合规项目必须在事件结束后处理。

这两条道路并不相互排斥。 在实践中，团队可能会首先启动全面回滚，以立即恢复服务，然后在补丁准备就绪并通过验证后，再跟进修复。 顺序由操作员根据当时的情况判断。

固定前移程序

要在 CIE 期间作为紧急变更部署修复程序，请按照以下步骤操作：

1. 重建受影响的组件。 运行 CI 管道，构建包含修复的新工件版本。 如果 CI 证据检查因事件条件而失败，可将管道或触发器属性 skip-inventory-update-on-failure 设置为空值或 0，以便在失败的情况下仍能更新清单，从而继续进行紧急更改。

2. 通过环境促进修复。 从最低环境开始创建推广拉动请求，并向上推广至生产环境。 如果时间允许，在进一步推广之前，核实每个阶段的修复情况。 如果情况危急，则直接提升至生产状态，并在服务恢复后调节较低的环境。

3. 贴上应急标签。 在以生产为目标的推广拉取请求中，添加 emergency 标签。 这就向管道发出信号，表明应绕过标准证据关卡，将变更视为紧急部署。

4. 部署到生产中。 运行 CD 管道。 管道会检测到紧急标签，跳过审批等待，立即进行部署和验收测试。 创建变更请求，并以 close_category = successful with issues 结 束，表明变更是在紧急情况下部署的。

5. 调节较低的环境。 生产事故解决后，将相同的紧急修复工件部署到下级环境--暂存、预生产等--以便所有环境都处于与生产一致的状态。 如果在推广到生产环境之前对较低级环境进行了验证，则应确认所有层级都有相同的工件版本。

国际教育大会后的义务

紧急部署会产生合规义务，必须在事件结束后加以解决：

• 变更申请必须由适当的审批人进行追溯审查和批准。
• 在紧急情况下接受的任何证据缺口--未解决的漏洞、未完成的扫描或未通过的检查--都必须进行补救，并在标准条件下重新运行管道。
• 应进行根本原因分析 (RCA)，并记录在案。

变更请求记录，包括管道所附的 Delta 摘要、关闭摘要和合并 SBOM，是 CIE 后审查的主要审计线索。

调用应急流程

应急流程由用户启动：

1. 用户运行管道时，会将 emergency 标签应用于推广拉取请求。
2. 管道会检测到紧急指定，并立即进行部署和验收测试，而无需等待标准批准。
3. 公约与建议委员会以 successful with issues 结案。

如果当前变更是紧急变更，请在运行管道前将 emergency 标签添加到推广拉取请求中。

紧急情况后的部署

一旦应急流程完成部署和测试，它就会在部署后阶段重新加入标准流程：

• 闭幕摘要和合并的 SBOM 附在公约与建议委员会之后。
• CR 按照与标准流程相同的 DEPLOYMENT_READY close_category 逻辑关闭。

如果 CR 类型为 emergency，则变更请求必须在部署后进行追溯审查和批准。

触发条件

当部署或验收测试未通过时，就会进入内联回滚流程。 然后，管道会评估是否启用了内联回滚：

• Inline-Rollback 未启用：CR 保留打开状态，close_category = unsuccessful，管道退出。 不会尝试自动恢复。
• 启用回滚：执行回滚脚本以还原目标环境，收集回滚工件并将其附加到 CR 中。

内联回滚执行

启用内联回滚时，管道

1. 如果 CD 管道中的部署或验收测试失败，则执行内联回滚脚本。
2. 收集以下文物
   • 回滚日志- 执行回滚脚本的输出结果
   • 结算摘要- 反映回滚结果
   • 合并的 SBOM- 回滚后软件物料清单
3. 将所有三个人工制品附加到开放的 CR 记录。

回滚后 CR 关闭

在内联回滚和工件附着之后，CR 将通过 close_category = unsuccessful 打开。 这就向变更管理部门发出信号，表明已尝试部署，但失败了，而且已自动恢复。

close_category = unsuccessful 的 CR 是逆转部署时预期的正确结果，而不是流程失败的迹象。 操作团队应使用所附的回滚日志调查根本原因。

使用预先批准的变更请求运行流水线

您可以使用预先批准的变更请求 (CR) 进行部署。 有两种可能的情况：

当 CD 管道识别出 CR 是由先前的 CD 管道运行创建的，它就会通过快速路径进行部署：

• 复用CR证据中预先计算的增量和证据摘要。
• 跳过同行评审和签名验证步骤。
• 部署预先计算的增量。

当 CD 管道无法确定 CR 是否由较早的 CD 管道运行创建，或所提供的 CR 与当前运行的部署目标不匹配时：

• 它不会复用任何预先计算的增量或证据摘要。
• 它不会跳过同行评审或人工签名验证。
• 它从头开始重新计算 delta 值和摘要。
• 它不会创建新的 CR，因为已经提供了一个。

针对失败的部署重新运行管道

如果您不想使用自动变更管理，那么可以改为提供先前创建并核准的变更请求。 在以下场景中重新运行失败的部署:

• 最新自动创建的变更请求尚未准备好部署，也未自动批准。 您已获得批准，必须使用相同的变更请求重新启动部署。
• 部署需要停机时间。 您创建了变更请求，它已获得批准，而且您遵循了组织的变更管理政策。
• 未更改代码或配置。 您创建了变更请求，解释了变更的内容，获得了批准，并开始使用已批准的变更请求进行部署。

CD 管道完成后，变更请求（CR）仍处于开放状态。

您可以使用预先批准的变更请求，并在 change-request-id 属性中输入变更请求 ID，从而启动 DevSecOps 引用持续部署管道。

如果设置了更改请求 -id 属性，管道就会跳过更改请求的数据收集，转而检查批准状态。 如果 change-request-id 默认设置为 notAvailable，管道会自动创建一个变更请求。