Gitlab hero border pattern left svg Gitlab hero border pattern right svg Background wave
Azure DevOps
Decision Kit
Decision Kit

GitLab vs. Azure DevOps Multi-Stage YAML Pipelines

In April 2020, Azure DevOps introduced Multi-Stage YAML pipelines for CI/CD. The Multi-Stage pipelines feature allows users the ability to execute the CI, CD or both functions within their YAML pipeline (file), a practice that GitLab has already been exercising.

The primary difference in GitLab’s approach to Multi-Stage Pipelines and Azure DevOps approach is the structure and correlation of “Stages” to “Jobs” within the YAML pipeline file.

GitLab Multi-stage Pipelines

GitLab Stages are defined globally for the pipeline. Each Job executed within the YAML pipeline identifies a Stage that it correlates to. Here is an example of how GitLab Stages and Jobs are structured in the YAML pipeline:

GitLab Multi State Pipelines

Azure DevOps Multi-stage Pipelines

Azure DevOps Stages are defined as divisions within the pipeline. Each Stage executed within the YAML pipeline identifies Jobs to run. Here is an example of how Azure DevOps Stages and Jobs are structured in the YAML pipeline:

AzureDevOps Multi State Pipelines


GitLab’s approach to configuring and structuring the Multi-stage YAML pipeline is easier to consume and less complicated than Azure DevOps approach. With GitLab, Job definitions include a Stage label to indicate at which Stage that Job should be executed (as seen above). With this approach, adding new attributes to a Job or even creating templates is much simpler due to how Stage definitions and Job definitions are separate within the structure of the YAML Pipeline. Azure DevOps approach, however, is more complicated since they group Job definitions within the Stage definitions (as seen above). Adding and deleting attributes to a Job within a Stage could present configuration confusion.