Master GitLab CI/CD: From Basics to Auto DevOps in One Guide

GitLab CI/CD is an integrated tool in GitLab that enables continuous integration, delivery, and deployment by automatically running scripts defined in a .gitlab-ci.yml file stored at the repository root.

Continuous Integration (CI): automatically build and test code on each push.

Continuous Delivery (CD): extend CI to automatically prepare deployments, manually triggered.

Continuous Deployment (CD): fully automated deployment without manual steps.

When developers push small code changes to a Git repository, GitLab detects the .gitlab-ci.yml file, creates a pipeline composed of jobs, and executes the defined scripts using a GitLab Runner.

GitLab CI/CD Introduction

The process reduces early‑stage bugs by building, testing, and validating code before merging into the main branch, and can automatically deploy to production after each push.

How GitLab CI/CD Works

A pipeline groups jobs defined in .gitlab-ci.yml. Each job runs the specified scripts, dependencies, and deployment steps. The Runner executes these jobs similarly to a terminal.

before_script:
  - apt-get install rubygems ruby-dev -y

run-test:
  script:
    - ruby --version 6

The above snippet defines a before_script to install dependencies and a run-test job that prints the Ruby version.

Creating a .gitlab-ci.yml File

Place the file in the repository root. Example for a Ruby project:

image: "ruby:2.5"

before_script:
  - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
  - ruby -v
  - which ruby
  - gem install bundler --no-document
  - bundle install --jobs $(nproc) "${FLAGS[@]}"

rspec:
  script:
    - bundle exec rspec

rubocop:
  script:
    - bundle exec rubocop

After committing the file, push it to the remote repository; GitLab automatically detects it and triggers the pipeline.

Pushing the Configuration

git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master

Configuring a Runner

A Runner can be a VM, physical machine, Docker container, or a cluster. It communicates with GitLab via API and executes the jobs defined in the pipeline.

After a Runner is registered, you can view pipeline and job status in the GitLab UI under CI/CD → Pipelines and CI/CD → Jobs.

Auto DevOps

Auto DevOps provides predefined CI/CD configurations that automatically detect, build, test, deploy, and monitor applications. Enabling it (Settings → CI/CD → Auto DevOps) allows a project to run a full DevOps lifecycle with minimal configuration.

Example: deploying a project to Google Kubernetes Engine using Auto DevOps involves creating a project from a GitLab template, adding a Kubernetes cluster, installing Helm, Ingress, and Prometheus, and then letting GitLab create the pipeline automatically.

Basic CI/CD Workflow

When code is pushed, the pipeline runs stages such as build, test, deploy, and performance testing. The UI visualizes each stage and job, and you can inspect logs by clicking on job statuses.

Example: Deploying a Spring Boot Application

image: java:8

stages:
  - build
  - deploy

before_script:
  - chmod +x mvnw

build:
  stage: build
  script:
    - ./mvnw package
  artifacts:
    paths:
      - target/demo-0.0.1-SNAPSHOT.jar

production:
  stage: deploy
  script:
    - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx
    - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io
    - ./cf push
  only:
    - master

This configuration builds the Spring Boot JAR and deploys it to Cloud Foundry when changes are merged to the master branch.