IBM Cloud Docs
自动化变更管理

自动化变更管理

变更管理自动化是 DevSecOps 管道参考实施的重要组成部分。 开发者,核准人和审计员可以监视部署的合规性方面。 每个部署都必须遵循组织的变更管理策略。

变更管理自动化可通过以下流程图直观体现。 下面的流程图说明了标准变更管理自动化、紧急变更管理、手动变更请求流程以及涉及内联回滚时的变更管理自动化流程。

变更管理自动化
变更管理自动化

准备工作

确保熟悉流程和术语。 有关更多信息,请参阅 自动化变更管理

为部署创建变更请求

使用库存中为促销拉取请求提供的拉取请求模板来填充变更请求字段。 由于无法自动填充这些字段,因此必须手动填充这些字段以提升更改。 通过手动填充这些字段,可以触发部署并继续自动收集其余变更请求的数据。

促销拉取请求
图 1。 提升拉取请求

促销拉取请求模板包含以下字段:

  • 优先级 必需。 更改的优先级。 有效值为: criticalhighmoderatelowplanning
  • 变更请求受让人 必需。 将变更请求分配给的人员的电子邮件地址。
  • 其他描述 描述变更过程。 来自自动化过程的额外内容将追加到此处。
  • 用途/目标 描述更改的用途。
  • 影响说明 描述更改的可能影响。
  • 客户影响 必需。 描述更改对客户的影响。 有效值为: criticalhighmoderatelowno_impact
  • 部署影响 是必需的。 描述更改对部署更改的影响。 有效值为: smalllarge
  • 回退计划 描述回滚或回退计划。

除了这些字段外,还必须从环境属性设置两个其他字段:

  • target-environment-purpose (必需) 有效值为: productionpre_prod。任何非生产部署都将符合 pre_prod 的条件。
  • target-environment-detail (必需) 一个字符串,用于描述在其中部署更改的 target-environment

有关变更请求数据的更多信息,请参阅 变更请求中包含的数据

更改类型

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

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

为需要计划停机时间的变更创建变更请求

持续部署管道根据以下条件自动核准变更请求:

  • 实施更改不会导致任何停机时间 (中断持续时间为零)。
  • 部署就绪状态为 true

DevSecOps参考实施中的变更管理自动化假定所有变更都是在无计划停机的情况下实施的。 如果您的更改需要计划的停机时间,那么必须手动创建变更请求并将其发送以进行核准。 核准后,您可以通过提供变更请求标识来启动部署。 管道向前移动以检查其核准,然后运行部署。 有关更多信息,请参阅 手动核准变更请求

根据在持续集成和持续部署阶段收集的证据计算部署就绪情况。 如果任何收集的证据表明存在偏差,或者与已部署的工件集相关的检查,扫描或测试失败,那么“部署就绪”将设置为 false,并且不会自动核准“变更请求”。 部署将停止,并阻止进一步的步骤,直到核准变更请求为止。

您可以从管道日志中读取创建的变更请求标识,等待核准,然后使用相同的变更请求标识再次启动部署。 管道向前移动以检查其核准,然后继续部署。

如果变更类型为 emergency,那么必须以追溯方式复审并核准变更请求。

使用现有变更请求标识重新运行失败的部署

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

  • 最新自动创建的变更请求未准备好进行部署,并且未自动核准该变更请求。 您已获得变更请求的核准,必须使用该变更请求再次启动部署。
  • 部署需要停机时间。 您创建了变更请求,核准了该变更请求,并且遵循了组织的变更管理策略中所需的步骤。
  • 未更改代码或配置。 您创建了更改请求,说明了更改的内容 (如果更改不在应用程序代码中),接收了核准,并使用核准的更改请求启动了部署。

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

预先核准的变更请求
图 2。 预先核准的变更请求

如果设置了 change-request-id 属性,那么管道将跳过更改请求的数据收集并前进以检查更改请求的核准状态。 如果缺省情况下 change-request-id 设置为 notAvailable,那么连续部署管道将自动创建变更请求。