What is GitLab CI/CD?

Architecture Key Components DevOps Lifecycle

Learn what GitLab CI/CD is, its architecture, key components, and why it matters for modern DevOps. Complete guide covering pipelines, runners, and the complete DevOps lifecycle.

GitLab Continuous Integration Continuous Delivery

GitLab CI/CD is a built-in continuous integration and continuous delivery (CI/CD) tool that's part of the GitLab DevOps platform. It allows you to automate the build, test, and deployment of your applications directly from your GitLab repository, without needing external CI/CD tools.

GitLab CI/CD is defined in a .gitlab-ci.yml file at the root of your repository. This file defines the pipeline structure, stages, jobs, and scripts to execute. The pipeline is automatically triggered on events like code pushes, merge requests, or schedules.

Key Concept: GitLab CI/CD is not just a tool — it's a complete DevOps platform. It integrates version control, CI/CD, container registry, security scanning, monitoring, and deployment all in one place.

History and Origins

GitLab CI was first introduced in 2012 as a simple continuous integration tool integrated with GitLab. Over the years, it has evolved into a comprehensive DevOps platform:

2012: GitLab CI introduced as a separate project
2014: GitLab CI merged into GitLab core
2015: GitLab Runner introduced
2016: Review Apps, Environments, and Auto DevOps concepts
2018: GitLab Container Registry integrated
2020: GitLab CI/CD becomes a complete DevOps platform
2023+: Advanced security scanning, compliance, and AI-powered features

Evolution: GitLab CI/CD has evolved from a simple CI tool to a complete DevOps platform that covers the entire software development lifecycle — from planning to monitoring.

Why GitLab CI/CD Matters

GitLab CI/CD addresses critical challenges in modern software development:

Single Source of Truth

Code, pipelines, and configuration live together in Git. No more managing separate CI/CD tools and repositories.

Complete DevOps Lifecycle

From planning and coding to testing, deploying, and monitoring — GitLab covers the entire lifecycle.

Built-in Security

SAST, DAST, dependency scanning, and container scanning are built into the pipeline, not added on.

Container Registry

Store and distribute Docker images directly in GitLab. No need for external registries.

Kubernetes Integration

Native Kubernetes integration for deploying applications to any cluster, any cloud.

GitOps Ready

GitOps workflows with GitLab for declarative infrastructure and application management.

GitLab CI/CD Architecture

GitLab CI/CD follows a distributed architecture where the GitLab server coordinates pipeline execution through GitLab Runners.

Git Push → GitLab Server → GitLab Runner → Job Execution → Deploy

GitLab Server Components

GitLab Rails Application

Core GitLab application that manages repositories, users, and CI/CD configuration.

GitLab Workhorse

Handles large HTTP requests, file uploads, and job artifacts.

GitLab Shell

Handles Git SSH access and repository management.

GitLab Sidekiq

Background job processor for asynchronous tasks including pipeline scheduling.

PostgreSQL

Stores GitLab configuration, users, projects, and CI/CD data.

Redis

Caching and job queue management for GitLab services.

GitLab Runner Components

GitLab Runner

Agent that executes pipeline jobs. Can run on any machine and use different executors.

Executors

Different execution environments: shell, docker, kubernetes, virtualbox, etc.

Pipeline Processor

Processes the .gitlab-ci.yml file and determines job execution order.

.gitlab-ci.yml

YAML file defining the pipeline structure: stages, jobs, scripts, rules, variables, and more.

Stages

Logical grouping of jobs (build, test, deploy). Stages run sequentially; jobs within a stage run in parallel.

Jobs

Individual units of work within a stage. Jobs run independently and report their status back to GitLab.

Runners

Agents that execute jobs. Can be shared, group-specific, or project-specific. Choose from multiple executors.

Container Registry

Built-in Docker registry for storing and distributing container images used in pipelines.

Artifacts

Files generated by jobs that can be passed to subsequent jobs or downloaded for inspection.

Cache

Cache dependencies between pipeline runs to significantly speed up builds.

Environments

Track deployments across different environments (development, staging, production).

Security Scanning

Built-in SAST, DAST, dependency scanning, container scanning, and secret detection.

Pipelines

Complete CI/CD process that runs from code commit to deployment. Can be triggered by multiple events.

CI vs CD: Understanding the Difference

Continuous Integration (CI)

What it is: Automatically building and testing code changes whenever developers push to the repository.

Goal: Detect integration issues early, before they become bigger problems.

In GitLab: Triggered on push or merge request. Runs build and test stages.

Continuous Delivery (CD)

What it is: Automatically deploying validated code to environments, but with manual approval for production.

Goal: Ensure code is always in a deployable state, with human control over production.

In GitLab: Deploy stages with when: manual for production.

Continuous Deployment

What it is: Fully automated deployment to production without manual intervention.

Goal: Deploy every change that passes tests to production automatically.

In GitLab: Deploy stages with when: always for production.

                # CI/CD in .gitlab-ci.yml

                # Continuous Integration (CI)
                build:
                  stage: build
                  script:
                    - npm install
                    - npm run build

                test:
                  stage: test
                  script:
                    - npm test

                # Continuous Delivery (CD) - Manual approval
                deploy_production:
                  stage: deploy
                  script:
                    - deploy.sh production
                  environment:
                    name: production
                  when: manual  # Manual approval required

                # Continuous Deployment - Automatic
                deploy_staging:
                  stage: deploy
                  script:
                    - deploy.sh staging
                  environment:
                    name: staging
                  when: always  # Automatic deployment
            

GitLab CI/CD vs Other CI/CD Tools

GitLab CI/CD

Pros: Integrated into GitLab, single source of truth, complete DevOps platform.

Cons: Requires GitLab, less flexible than some alternatives.

Best For: Teams already using GitLab, all-in-one DevOps.

Jenkins

Pros: Highly flexible, massive plugin ecosystem, self-hosted.

Cons: Complex setup, maintenance overhead, separate from code.

Best For: Complex pipelines, legacy systems.

GitHub Actions

Pros: Deep GitHub integration, large marketplace, easy setup.

Cons: GitHub-centric, limits on public repos.

Best For: Teams using GitHub, open-source projects.

ArgoCD/Flux

Pros: GitOps-native, Kubernetes-focused, declarative.

Cons: Not a CI tool, requires external CI.

Best For: GitOps workflows, Kubernetes deployments.

Choosing the Right Tool: GitLab CI/CD is ideal if you're already using GitLab or want an all-in-one DevOps platform. If you need maximum flexibility or have an existing Jenkins setup, Jenkins might be better. For GitHub-based projects, GitHub Actions is the natural choice.

GitLab DevOps Lifecycle

GitLab CI/CD is part of a larger DevOps lifecycle that covers the entire software development process:

Plan → Code → CI → Secure → CD → Monitor

Plan

Issues, epics, milestones, and boards for project planning.

Code

Repositories, merge requests, and code review for collaboration.

CI

Automated build and test on every code change.

Secure

Security scanning integrated into the pipeline.

CD

Automated deployment to staging and production.

Monitor

Application performance monitoring and incident management.

Your First GitLab CI/CD Pipeline

                # .gitlab-ci.yml - Your First Pipeline
                # This is a simple pipeline that builds, tests, and deploys
                # a Node.js application.

                stages:
                  - build
                  - test
                  - deploy

                # Variables
                variables:
                  NODE_VERSION: "18"
                  DOCKER_REGISTRY: $CI_REGISTRY
                  DOCKER_IMAGE: $CI_REGISTRY_IMAGE

                # Build Stage
                build:
                  stage: build
                  image: node:$NODE_VERSION
                  script:
                    - echo "Installing dependencies..."
                    - npm ci
                    - echo "Building application..."
                    - npm run build
                  artifacts:
                    paths:
                      - dist/
                    expire_in: 1 day

                # Test Stage
                test:
                  stage: test
                  image: node:$NODE_VERSION
                  script:
                    - echo "Running tests..."
                    - npm ci
                    - npm test
                  artifacts:
                    reports:
                      junit: test-results.xml

                # Deploy Stage
                deploy_staging:
                  stage: deploy
                  image: node:$NODE_VERSION
                  script:
                    - echo "Deploying to staging..."
                    - npm run deploy:staging
                  environment:
                    name: staging
                    url: https://staging.example.com
                  only:
                    - develop

                deploy_production:
                  stage: deploy
                  image: node:$NODE_VERSION
                  script:
                    - echo "Deploying to production..."
                    - npm run deploy:production
                  environment:
                    name: production
                    url: https://example.com
                  when: manual
                  only:
                    - main
            

Your First Pipeline: This pipeline:

Builds the application on every push
Tests the application to ensure quality
Deploys to staging automatically on develop branch
Deploys to production manually on main branch
Tracks deployments in environments

Frequently Asked Questions

Is GitLab CI/CD free?

GitLab offers a free tier with 400 compute minutes per month for private repositories. Public repositories get unlimited CI/CD minutes. Paid tiers offer more minutes and features like security scanning.

Do I need to install GitLab Runner?

GitLab.com provides shared runners that work out of the box. For self-hosted GitLab or custom requirements, you need to install GitLab Runner. You can install it on any machine and use different executors.

What is the difference between CI and CD?

CI (Continuous Integration) automates building and testing code changes. CD (Continuous Delivery/Deployment) automates deploying validated code to environments. CD is the natural extension of CI.

Can I use GitLab CI/CD with other Git providers?

GitLab CI/CD is designed to work with GitLab repositories. However, you can use GitLab as a mirror for other Git providers. For other providers, consider Jenkins, GitHub Actions, or other CI/CD tools.

What is the difference between GitLab CI/CD and Jenkins?

GitLab CI/CD is integrated into GitLab with configuration in the repository (.gitlab-ci.yml). Jenkins is a standalone tool with configuration in Jenkinsfiles. GitLab CI is simpler for GitLab users; Jenkins is more flexible for complex workflows.

How do I get started with GitLab CI/CD?

Create a .gitlab-ci.yml file in your repository with stages and jobs. GitLab will automatically detect the file and run the pipeline on every push. Start simple, then add complexity as needed.

What are GitLab Runners?

GitLab Runners are agents that execute pipeline jobs. They can be shared (available to all projects), group-specific, or project-specific. Runners can use different executors (shell, docker, kubernetes, etc.).

How do I secure my GitLab CI/CD pipeline?

Use masked variables for secrets, protected branches for production, protected runners for sensitive jobs, security scanning templates, and least privilege for service accounts.

What is GitLab CI/CD?

Single Source of Truth

Complete DevOps Lifecycle

Built-in Security

Container Registry

Kubernetes Integration

GitOps Ready

GitLab Server Components

GitLab Rails Application

GitLab Workhorse

GitLab Shell

GitLab Sidekiq

PostgreSQL

Redis

GitLab Runner Components

GitLab Runner

Executors

Pipeline Processor

Tags

.gitlab-ci.yml

Stages

Jobs

Runners

Container Registry

Artifacts

Cache

Environments

Security Scanning

Pipelines

Continuous Integration (CI)

Continuous Delivery (CD)

Continuous Deployment

GitLab CI/CD

Jenkins

GitHub Actions

ArgoCD/Flux

Plan

Code

CI

Secure

CD

Monitor

GitLab vs Jenkins vs GitHub Actions

Setting Up GitLab CI/CD

.gitlab-ci.yml Explained

GitLab Runners

Container Registry

CI/CD Best Practices