Stop 06 · CI/CD PipelinesTopics · 4/10

GitLab CI/CD

In short

If your code lives on GitLab, CI/CD is already built in. One YAML file at the root of the repo, and every push gets built, tested and deployed, with no extra server to install.

GitLab's built-in, tightly integrated CI/CD system defined via a .gitlab-ci.yml file — a strong choice when your whole workflow already lives on GitLab.

The mascot stands at the gate of a compact campus with a hostel, a library and classrooms inside the walls.

Think of it like this

The all-in-one college campus

Some colleges have the hostel, mess, library, classrooms and exam hall inside one gate. No travelling between buildings across the city. GitLab is that campus: code, issues, merge requests, CI runners and a container registry, all inside one product.

Watch it happen

One push through .gitlab-ci.yml

Push

test

build

deploy

1/4You push to a branch. GitLab reads .gitlab-ci.yml and creates a pipeline.

The big ideas

What you need to know

Stages and jobs

Stages run in order. Jobs inside a stage run at the same time. A failed job stops later stages.

Runners do the work

GitLab.com offers shared runners, and you can register your own runner inside a private network.

rules control when

rules: decide whether a job runs, for example only on main, only for tags or only when certain files changed.

Predefined variables

GitLab injects values like CI_COMMIT_SHORT_SHA and CI_REGISTRY_IMAGE, handy for tagging builds.

See it in code

Walk through the code

yaml

1stages: [test, build, deploy]2test:3  stage: test4  image: node:225  script: [npm ci, npm test]6build:7  stage: build8  image: node:229  script: [npm ci, npm run build]10  artifacts: { paths: [dist/] }11deploy:12  stage: deploy13  script: ./deploy.sh dist/14  environment: production15  rules:16    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

1/4Declare the stage order once at the top.

Use the CI Lint tool in GitLab's pipeline editor to validate this file before you push.

Save yourself the pain

Common mistakes

Oops

Using the old only/except keywords from outdated tutorials everywhere.

Do this instead

Prefer rules:, which is more flexible. GitLab's docs recommend it for new pipelines.

Oops

Running npm ci from scratch in every job and wondering why pipelines are slow.

Do this instead

Use cache: for dependencies and artifacts: to pass build output between stages.

Your mission

Your first GitLab pipeline

~30 min

Quick check

Two jobs are both in the test stage. How do they run?

Go deeper

1Write a basic .gitlab-ci.yml pipeline for a sample project.
2Learn GitLab's stages and jobs concepts and how they compare to GitHub Actions' jobs and steps.
3Compare GitLab CI/CD's built-in features (like environments) to GitHub Actions' equivalents.