GitLab PM Associate: CI/CD and Delivery Visibility

CI/CD and Delivery Visibility

This domain tests how GitLab runs pipelines and how teams see delivery performance. You need to read .gitlab-ci.yml, understand job ordering and rules, and interpret deployment and DORA-style metrics.

Pipeline mechanics

A pipeline contains stages; jobs in the same stage run in parallel, and stages run sequentially by default.
needs: creates a directed acyclic graph so a job can start before its stage completes.
rules: are evaluated in order; the first matching rule wins. They can test variables such as $CI_PIPELINE_SOURCE, $CI_COMMIT_BRANCH, file changes, and existence.
when: manual makes a job optional; allow_failure keeps a failed job from blocking the pipeline.
Runners execute jobs. Shared runners serve many projects; group and project runners are scoped. Tags select runners.
Artifacts are files passed to later jobs or downloaded; cache speeds up repeated work but is not guaranteed.

Delivery visibility

Environments represent deployed targets such as staging or production; deployments record what was deployed and when. Merge request pipelines show results before merge. DORA metrics cover deployment frequency, lead time for changes, change failure rate, and time to restore service. Value Stream Analytics shows flow time by stage.

Worked example

A deploy job must run only from main and must be started by a human. The rule block is:

deploy:
  stage: deploy
  script: ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
    - when: never

The first rule matches main and sets manual; every other branch matches when: never. The reasoning: rules are first-match, so the catch-all must come last. Without it, the job would be added to pipelines on other branches with default on_success.

Traps that cost marks

Do not put a broad rule before a specific one; the broad rule wins. Do not assume artifacts are available to every job; later stages fetch them by default, while dependencies or needs can narrow that. Do not treat cache as a build artifact. Do not use only/except and rules together in the same job. Do not assume a manual job runs automatically.

Reading metrics

Compare deployment frequency with change failure rate; high frequency with high failure rate is not healthy. Lead time measures commit-to-production, not review time alone.