IBM Cloud Docs
了解 DevSecOps 管道

了解 DevSecOps 管道

参考持续集成和持续部署工具链中提供的各种管道基于对 Tekton Pipelines 的 Continuous Delivery 支持。 要了解有关 Tekton 管道的更多信息,请参阅 使用 Tekton 管道

您无需是 Tekton 专家即可使用参考管道。 参考管道是使用基本结构预定义的,该结构包含用于步骤 (例如,构建,自动化测试和部署) 的定制脚本的占位符。 用户可以为自己的管道声明其定制脚本,并为特定管道的各种环境属性设置值。

管道状态类型

了解参考管道在某些位置的错误或故障情况很重要。 从概念上讲,在合规性管道中运行的任务会产生两种不同类型的状态:

  • 合规性状态: some 检查或一组检查的通过或失败状态。
  • 管道状态: 任务执行本身的成功或失败状态。

如果测试,扫描或检查失败,那么不会导致管道本身失败或停止; 运行测试的任务将标记为绿色。

从合规性角度来看,单元测试的结果不会影响部署。 您可以部署具有失败检查的工件,但该过程会保留有关该活动的证据。 发生中断时,合规性流不会阻止您发布修订。 例如,针对发现测试失败的单元测试任务的绿色运行表示 The task ran successfully and found the following issues

如果任务失败且状态为红色,那么会发生此情况,因为管道无法或不应继续。 失败的示例条件包括:

  • 任务或管道中存在错误。
  • 发生了一些事情,这意味着继续运行管道是没有意义的。

例如,如果工件构建在持续集成中失败,那么会破坏持续集成过程本身的目的。

为了使最终管道状态与合规性结果保持同步,管道末尾的任务将检查合规性结果,并将管道运行状态设置为 redgreen

拉取请求管道

拉取请求管道对指定应用程序 (应用程序) 存储库 (存储库) 的拉取请求运行预先设置的一致性状态检查。 如果检查失败,那么这些状态检查可能会阻止您将拉取请求合并到缺省活动分支 (通常为 master) 中。 针对缺省活动分支打开或更新拉取请求以触发拉取请求管道运行。 用户可以在定制阶段中针对管道和测试运行自己的设置。 有关拉取请求管道的更多信息,请参阅 拉取请求管道

持续集成管道

持续集成管道从应用程序 (app) 存储库 (repos) 构建可部署工件。 在构建工件之前,管道会以处理拉取请求的相同方式检查代码是否已扫描和测试。 在 库存 中将已构建的工件标记为可供发布和部署之前,还会在管道中扫描这些工件以查找漏洞并对其进行签名。 与拉取请求管道不同,持续集成管道在构建的每个阶段 (例如测试,扫描和签名) 上收集证据和结果工件。 此数据与构建的工件相关,可通过部署过程和变更管理进行跟踪。 有关持续集成管道的更多信息,请参阅 持续集成管道

持续部署管道

持续部署管道将生成所有证据和变更请求摘要内容。 管道将构建工件部署到特定环境 (例如登台或生产),然后收集,创建所有现有日志文件,证据和工件并将其上载到证据锁定程序。 有关持续部署管道的更多信息,请参阅 持续部署管道

持续合规性管道

自工件部署在生产环境中以来,持续合规性管道会定期扫描已部署的工件及其源存储库以查找更新的漏洞。 管道还有助于自动跟踪到期日期的偏差,并在 IBM Cloud Security and Compliance Center中提供应用程序感知。 有关更多信息,请参阅 持续合规性管道

与 Security and Compliance Center 集成

请参阅 将 IBM Cloud® Security and Compliance Center 与 DevSecOps 工具链配合使用

库存工作流程

请参阅 证据(Evidence)

请参阅 库存(Inventory)

连续集成写入库存

库存包含多个分支,包括缺省分支。 这些分支可以表示部署阶段,环境或区域,也可以表示这些选项的组合,具体取决于设置和使用情况。

缺省分支由连续集成构建填充。 目标中的最后一个落实 (例如 staging) 具有一个标记,该标记显示它是最后完成的部署。

如果将库存的缺省分支切换到其他分支,那么必须将先前缺省分支中的落实重定基底到新的缺省分支,以使 Git 落实历史记录具有线性关系。

促销

要提升到目标分支,请创建拉取请求。 拉取请求内容将填充变更请求字段。 复审后,您可以合并促销拉取请求。

增量和部署

合并提升拉取请求后,可以启动部署管道。 部署增量是上次完成的部署的内容与当前部署的内容之间的差异。 部署增量列出了要部署的库存项。

结论

当部署完成时,将向前移动 latest 标记。

在 dev-mode 触发器期间,不会高级标记,dev-mode 触发器的目的仅用于测试 CD 管道,建议不要在生产环境中使用。

升级到更多环境

可以从任何分支到另一个分支进行提升和部署。

库存情况

当前已部署状态保存要部署到环境的内容。 目标分支中的每个提升的落实都包含相关管道运行标识和变更请求标识作为标记。 某些落实可以具有多个标记,例如再次运行失败的部署时。 “库存”存储用于重放部署的每条信息。

库存格局
图 1。 库存格局

使用标记

  • latest: 标记分支上库存的当前,成功部署和结束状态。
  • pipeline run id: 使用管道运行标识或实际部署的构建号来标记分支中的最新库存状态。 您可以使用此信息来引用分支历史记录中的实际库存点散列,以便在触发并行部署时避免库存内容重叠。
  • change request id: 可选。 标记当前状态。 变更请求标识在历史记录中表示并在库存中进行跟踪。

单目标-多区域设置

单一目标-多区域设置是在此模型上的迭代,其中引入了单一目标环境的多个 latest 标记。 此模型允许多个连续管道在不同用例类型的同一目标上工作。

例如,您可以将同一目标环境用于生产目标环境和库存分支中的多个区域 (例如 us-southeu-de)。

要通过持续部署管道指定部署区域,请使用 region 参数。 有关此参数的更多信息,请参阅 Continuous deployment Pipeline 参数

团队不需要为每个区域 (例如 us-south-prodeu-de-prod) 设置不同的分支,并以冗余方式运行促销。 请改为为同一库存分支指定这些附加目标,然后将其用作 Git 标记。

在此设置中,生产分支在同一分支 (例如 us-south_prod_latesteu-de_prod_latest) 上具有多个 latest 标记,负责每个区域的每个持续部署管道都可以使用这些标记进行部署。

单目标-多区域设置
图 2。 单个目标-多区域设置

示例场景

可以最终在任何地方部署的一组更改,可能会先发布到单个区域。 然后,您可以使用以这些区域为目标的持续部署管道将这组更改逐步部署到其他区域。