diff options
Diffstat (limited to 'doc/ci/pipelines/pipeline_architectures.md')
| -rw-r--r-- | doc/ci/pipelines/pipeline_architectures.md | 43 |
1 files changed, 33 insertions, 10 deletions
diff --git a/doc/ci/pipelines/pipeline_architectures.md b/doc/ci/pipelines/pipeline_architectures.md index a02ac7ba067..e36eb24055f 100644 --- a/doc/ci/pipelines/pipeline_architectures.md +++ b/doc/ci/pipelines/pipeline_architectures.md @@ -1,7 +1,7 @@ --- stage: Verify group: Pipeline Execution -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments type: reference --- @@ -10,15 +10,21 @@ type: reference Pipelines are the fundamental building blocks for CI/CD in GitLab. This page documents some of the important concepts related to them. -There are three main ways to structure your pipelines, each with their +You can structure your pipelines with different methods, each with their own advantages. These methods can be mixed and matched if needed: - [Basic](#basic-pipelines): Good for straightforward projects where all the configuration is in one easy to find place. - [Directed Acyclic Graph](#directed-acyclic-graph-pipelines): Good for large, complex projects that need efficient execution. -- [Child/Parent Pipelines](#child--parent-pipelines): Good for monorepos and projects with lots of independently defined components. +- [Parent-child pipelines](#parent-child-pipelines): Good for monorepos and projects with lots of independently defined components. -For more details about -any of the keywords used below, check out our [CI YAML reference](../yaml/index.md) for details. + <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> + For an overview, see the [Parent-Child Pipelines feature demo](https://youtu.be/n8KpBSqZNbk). + +- [Multi-project pipelines](downstream_pipelines.md#multi-project-pipelines): Good for larger products that require cross-project interdependencies, + like those with a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/). + + <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> + For an overview, see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84). ## Basic Pipelines @@ -163,12 +169,29 @@ deploy_b: environment: production ``` -## Child / Parent Pipelines +## Parent-child pipelines + +As pipelines grow more complex, a few related problems start to emerge: + +- The staged structure, where all steps in a stage must complete before the first + job in next stage begins, causes waits that slow things down. +- Configuration for the single global pipeline becomes + hard to manage. +- Imports with [`include`](../yaml/index.md#include) increase the complexity of the configuration, and can cause + namespace collisions where jobs are unintentionally duplicated. +- Pipeline UX has too many jobs and stages to work with. + +Additionally, sometimes the behavior of a pipeline needs to be more dynamic. The ability +to choose to start sub-pipelines (or not) is a powerful ability, especially if the +YAML is dynamically generated. + + -In the examples above, it's clear we've got two types of things that could be built independently. -This is an ideal case for using [Child / Parent Pipelines](downstream_pipelines.md#parent-child-pipelines)) via -the [`trigger` keyword](../yaml/index.md#trigger). It separates out the configuration -into multiple files, keeping things very simple. You can also combine this with: +In the [basic pipeline](#basic-pipelines) and [directed acyclic graph](#directed-acyclic-graph-pipelines) +examples above, there are two packages that could be built independently. +These cases are ideal for using [parent-child pipelines](downstream_pipelines.md#parent-child-pipelines). +It separates out the configuration into multiple files, keeping things simpler. +You can combine parent-child pipelines with: - The [`rules` keyword](../yaml/index.md#rules): For example, have the child pipelines triggered only when there are changes to that area. |