Create a minimal pipeline
Write a `.gitlab-ci.yml` with `build` and `test` stages for a Node.js app. Use `node:20`, run `npm ci`, `npm run build`, and `npm test`.
DevOps & Tooling / Knowledge library
GitLab CI/CD
integrated pipelines for build, test, and deploy
Why learn GitLab CI/CD?
GitLab CI/CD automates software delivery inside the same platform where code is planned, reviewed, and merged. It reduces manual release steps, catches defects earlier, standardizes deployments, and adds traceability for audits and incident response.
Where it came from
GitLab CI started as a separate project before being integrated into core GitLab around the GitLab 8.x era. The `.gitlab-ci.yml` file became the central declarative format for defining jobs, stages, and rules. GitLab Runner evolved from early runner tooling into a multi-executor system (shell, Docker, Kubernetes, and more). Capabilities such as Auto DevOps, review apps, child pipelines, and merge trains broadened CI/CD from simple testing to full delivery orchestration.
- GitLab CI started as a separate project before being integrated into core GitLab around the GitLab 8.x era.
- The `.gitlab-ci.yml` file became the central declarative format for defining jobs, stages, and rules.
- GitLab Runner evolved from early runner tooling into a multi-executor system (shell, Docker, Kubernetes, and more).
- Capabilities such as Auto DevOps, review apps, child pipelines, and merge trains broadened CI/CD from simple testing to full delivery orchestration.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Write a `.gitlab-ci.yml` with `build` and `test` stages for a Node.js app. Use `node:20`, run `npm ci`, `npm run build`, and `npm test`.
- Add caching and artifacts so tests can reuse dependencies and build output. Use `needs` to reduce stage wait time.
- Add a `deploy_prod` job that runs only on `main`, requires a manual action, and publishes an environment named `production`.
- Refactor one large pipeline into parent-child pipelines. Keep lint/test in parent and trigger service-specific child pipelines.
- Add a merge-request pipeline rule that runs SAST and fails the pipeline on high-severity findings.
More ways to practice
Speed up feedback
Add caching and artifacts so tests can reuse dependencies and build output. Use `needs` to reduce stage wait time.
Safe production deploy
Add a `deploy_prod` job that runs only on `main`, requires a manual action, and publishes an environment named `production`.
Split complex workflows
Refactor one large pipeline into parent-child pipelines. Keep lint/test in parent and trigger service-specific child pipelines.
Security gate in merge requests
Add a merge-request pipeline rule that runs SAST and fails the pipeline on high-severity findings.
Documentation and sources
- GitLab CI/CD docs (docs.gitlab.com)
- GitLab CI YAML reference (docs.gitlab.com)
- GitLab Runner docs (docs.gitlab.com)
- GitLab releases (about.gitlab.com)
Catalog research notes
- Reusable CI/CD components and template composition have expanded for standardizing pipelines across projects.
- Policy-driven compliance and security checks are more deeply enforced at merge request and pipeline levels.
- Runner scalability has improved with stronger autoscaling patterns for container and cloud workloads.
- Pipeline UX improvements continue in areas like downstream pipelines, merge trains, and deployment visibility.
Connect the ideas
Explore next
Real World Example
Automated Logistics Fleet Deployment
A regional logistics firm managing a fleet of autonomous delivery drones that requires frequent firmware updates to navigation software.
The business problem
Manual deployment processes lead to inconsistent firmware versions across the drone fleet, resulting in navigation errors and significant downtime during manual troubleshooting.
How this topic solves it
GitLab CI/CD provides an integrated pipeline that enforces a standardized build, test, and deployment sequence, ensuring every firmware update is validated against automated test suites before being pushed to the fleet management server.
- Define a .gitlab-ci.yml file in the repository root to establish build, test, and deploy stages.
- Configure GitLab Runners as execution agents to process the firmware compilation and unit testing tasks.
- Utilize protected CI/CD variables to securely store API keys required for communicating with the fleet management server.
- Implement pipeline stages to ensure that the deployment job only triggers if the test stage completes successfully.
- Use CI/CD components to standardize the deployment logic across multiple drone model repositories.
The sequence of automated actions triggered by a code commit.
Developer pushes firmware update
Compiles firmware binary
Validates navigation logic
Pushes to fleet server
- Code Commit → triggers → Build Stage
- Build Stage → passes artifacts → Test Stage
- Test Stage → conditional on success → Deploy Stage
Implementation example
This configuration maps to the Automated Logistics Fleet Deployment scenario by defining the mandatory stages to ensure firmware is built, tested, and deployed in a controlled, secure manner.
stages:
- build
- test
- deploy
build_firmware:
stage: build
script: make compile # Compiles the drone firmware
test_firmware:
stage: test
script: ./run_nav_tests.sh # Validates navigation logic
deploy_to_fleet:
stage: deploy
script: ./push_to_server.sh # Deploys to fleet management server
variables:
API_KEY: $SECURE_API_KEY # Uses protected variable for securityExpected business outcome
A reliable, repeatable deployment process that eliminates configuration drift and ensures only verified firmware reaches the production drone fleet.
Limitations and checks
A primary limitation is the potential for pipeline bottlenecks if too many jobs are queued for a single runner; this can be checked by monitoring the job queue duration in the GitLab CI/CD pipeline dashboard.