Pipeline Architecture

Pipeline Architecture

管道是 GitLab 中 CI / CD 的基本构建块. 本页记录了一些与它们有关的重要概念.

构造管道的主要方法有三种，每种都有自己的优势. 如果需要，可以混合使用以下方法：

  • 有向无环图 ：适用于需要有效执行的大型，复杂项目.
  • ：适用于具有大量独立定义组件的 monorepos 和项目.

有关下面使用的任何关键字的更多详细信息，请查看我们的CI YAML 参考以获取详细信息.

这是 GitLab 中最简单的管道. 它会在构建阶段同时运行所有内容，一旦所有这些操作完成，它将以相同的方式在测试阶段运行所有内容，依此类推. 它不是最有效的，并且如果您有很多步骤，它可能会变得非常复杂，但更易于维护：

匹配该图的示例基本管道配置：

如果效率对您很重要，并且您希望所有内容尽快运行，则可以使用有向无 . 使用needs关键字定义作业之间的依赖关系. 当 GitLab 知道您的工作之间的关系时，它可以尽快运行所有内容，甚至在可能的情况下跳入后续阶段.

在下面的示例中，如果build_a和test_a的速度比build_b和test_b ，则即使仍在运行，GitLab 也会启动deploy_a .

使用 DAG build_a-> test_a-> deploy_a build_b-> test_b-> deploy_b 结束的图 LR 子图管道

在上面的示例中，很明显，我们可以独立构建两种类型的东西. 这是通过使用” 子/父管道”的理想情况. 它将配置分成多个文件，使事情变得非常简单. 您还可以将其与：

  • ：例如，仅在对该区域进行更改时才触发子管道.
  • 子管道内部的 ，实现了两者的好处.

graph LR subgraph Parent pipeline trigger_a -.-> build_a trigger_b -.-> build_b subgraph child pipeline B build_b —> test_b —> deploy_b end subgraph child pipeline A build_a —> test_a —> deploy_a end end

匹配该图的父管道的示例配置：

例如孩子a管道配置，位于/a/.gitlab-ci.yml ，利用的 DAG needs:关键字：

也可以将作业设置为在触发子管道之前或之后运行，例如，如果您具有通用的设置步骤或最后进行统一部署.