Introduction to GitLab CI/CD

What happens between git push and a finished deployment? This module clarifies the terms Continuous Integration, Continuous Delivery and Continuous Deployment with concrete examples. You create your first GitLab project, get familiar with Merge Requests, the Container Registry and the pipeline view. By the end you understand where CI/CD fits into daily development and how GitLab maps each step.

You write your first .gitlab-ci.yml from scratch: Jobs, Stages and Scripts form the foundation. You define an image, use before_script for setup steps and watch GitLab execute the pipeline in real time. Then you extend the pipeline with a test job and see how GitLab halts execution on failure.

Not every job should run on every push. You work with CI/CD Variables (project, group, instance), protect secrets using masked and protected flags, and control pipeline logic with rules. Why are the old only/except keywords and workflow:rules templates deprecated? You see the difference in practice and build a pipeline that runs different jobs depending on branch and merge request status.

Where do your jobs actually run? You learn the difference between Shared, Group and Project Runners, configure Tags for targeted job assignment, and compare the Shell, Docker and Kubernetes executors. In the hands-on exercise you register your own runner. Then you see how the Kubernetes Executor automatically spins up pods on demand and tears them down after the job: autoscaling without manual intervention.

Artifacts and cache sound similar but solve different problems. You store build results as Artifacts and make them available to subsequent stages. Then you set up a Cache for node_modules or Maven repositories so pipelines don't reload all dependencies on every run. With the needs keyword you break the rigid stage order and run independent jobs in parallel.

You build a Docker image directly in the pipeline and push it to the GitLab Container Registry. You compare two approaches: Docker-in-Docker (dind) and the socket mount. When does each approach make sense, and what are the security implications of privileged mode? Finally you tag images automatically with the Git reference and use Multi-Stage Builds for lean production images.

An image without a scan is a risk. You integrate Trivy as a job in your pipeline to automatically check for CVEs in base images and dependencies. Then you activate GitLab's built-in SAST (Static Application Security Testing) and view results directly in the merge request. You define thresholds that block the pipeline, making the decision about production readiness early in the process.

Maintaining the same pipeline logic across ten projects? That doesn't scale. You work with include and extends to define jobs centrally. Then you go a step further: with the CI/CD Component Catalog you publish reusable pipeline building blocks with versioned inputs that other teams can integrate directly. You build your own component, publish it to the catalog and include it in a second project.

Code that only works locally is useless. You configure Environments (staging, production) with their own variables and protection rules. Then you set up a Deployment that rolls out automatically on every merge to main. The highlight: Review Apps that spin up a dedicated preview environment for each merge request and tear it down after the merge. Every reviewer sees the changes live.

Pipelines fail, and speed matters when they do. You use CI Lint for syntax checking before pushing, enable debug logging for detailed output and analyze common failure patterns (runner timeouts, image pull errors, permission issues). To close: a checklist of daily best practices including interruptible jobs, job token permissions following the least privilege principle, and structuring large pipelines with parent-child pipelines.