What is GitLab CI/CD and How Does the Pipeline Model Work?
Learn how GitLab CI/CD pipelines, stages, jobs, and runners work together, including DAG execution via needs, for DevOps interviews.
Expected Interview Answer
GitLab CI/CD is GitLab’s built-in continuous integration and delivery system, configured through a single `.gitlab-ci.yml` file that defines stages and jobs executed by GitLab Runners, tightly integrated with GitLab’s source control, container registry, and deployment features.
A pipeline is composed of stages (for example build, test, deploy) that run in order, while jobs within the same stage run in parallel by default unless explicit `needs` relationships create a directed acyclic graph for faster fan-out/fan-in execution. Runners — GitLab’s execution agents, shared or project-specific — pick up jobs and execute them inside isolated environments, typically Docker containers defined per job via the `image:` keyword. GitLab CI/CD ships with first-class features beyond raw pipeline execution: Auto DevOps for zero-config pipelines, built-in container/package registries, environments with manual approval gates, and merge request pipelines that run against the merged result before merging. Because it is deeply integrated into one platform, teams get pipeline visibility, security scanning, and deployment tracking without stitching together separate tools.
- Single YAML file drives the entire pipeline, versioned with the code
- DAG-based `needs` relationships speed up complex pipelines
- Built-in container registry, environments, and approval gates
- Merge request pipelines validate the merged result pre-merge
AI Mentor Explanation
GitLab CI/CD is like a franchise’s single master operations manual that lists ordered stages — fitness testing, nets, tactical review — where every drill in one stage must finish before the next stage begins, but drills within the same stage run across multiple nets simultaneously. A specific drill can jump ahead of its stage if it only depends on one earlier drill finishing, not the whole stage, similar to a DAG shortcut. Ground staff (runners) assigned to each net execute the actual drills defined in the manual. Because everything from squad selection to matchday approval lives in one manual, the whole preparation pipeline stays visible end to end.
Step-by-Step Explanation
Step 1
Define stages and jobs
Write .gitlab-ci.yml declaring `stages:` and jobs, each assigned to a stage and a Docker `image`.
Step 2
Runner picks up jobs
A GitLab Runner (shared or project-specific) executes each job inside its own isolated container.
Step 3
Stages run in order, jobs in parallel
Jobs within a stage run concurrently; `needs` can create a DAG to skip waiting for the whole prior stage.
Step 4
Deploy through environments
Deployment jobs target defined environments, optionally gated behind manual approval before promoting.
What Interviewer Expects
- Understanding of stages vs jobs and their execution order
- Awareness of how `needs` creates a DAG for faster pipelines
- Knowledge of GitLab Runner execution and per-job container isolation
- Familiarity with merge request pipelines and environment-based deployment gates
Common Mistakes
- Assuming all jobs run strictly in file order regardless of stage/needs
- Not isolating jobs via distinct Docker images, causing tooling conflicts
- Forgetting merge request pipelines validate the merged result, not just the branch
- Overlooking manual approval gates required for production environments
Best Answer (HR Friendly)
“GitLab CI/CD lets us define our whole pipeline — build, test, deploy — in one YAML file that lives in the repo, organized into stages that run in order while jobs inside each stage run in parallel. Because it is built into GitLab itself, we also get the container registry, environment tracking, and approval gates without needing separate tools.”
Code Example
stages:
- build
- test
- deploy
build-job:
stage: build
image: node:20
script:
- npm ci
- npm run build
test-job:
stage: test
image: node:20
script:
- npm test
deploy-job:
stage: deploy
environment: production
when: manual
script:
- ./deploy.shFollow-up Questions
- How does the `needs` keyword change pipeline execution order?
- What is the difference between a shared runner and a specific runner?
- How do merge request pipelines differ from branch pipelines?
- What does Auto DevOps configure automatically?
MCQ Practice
1. What file defines a GitLab CI/CD pipeline?
GitLab reads pipeline configuration from .gitlab-ci.yml checked into the root of the repository.
2. By default, how do jobs within the same stage execute?
Jobs assigned to the same stage run concurrently by default, while stages themselves run in order.
3. What does the `needs` keyword enable in a GitLab pipeline?
`needs` creates direct job dependencies, allowing execution to skip waiting for every job in the preceding stage.
Flash Cards
What is GitLab CI/CD? — GitLab’s built-in CI/CD system configured via .gitlab-ci.yml and executed by Runners.
Stages vs jobs? — Stages run in order; jobs within a stage run in parallel by default.
What does `needs` do? — Creates a DAG so a job can start once specific prior jobs finish, not the whole stage.
What executes GitLab CI jobs? — GitLab Runners, typically inside isolated Docker containers per job.