Operations 12 min read

GitLab CI/CD: Introduction, Workflow, and Quick Start Guide

This article provides a comprehensive overview of GitLab CI/CD, explaining continuous integration, delivery, and deployment concepts, detailing the .gitlab-ci.yml configuration, pipeline workflow, runner setup, Auto DevOps features, and includes practical code examples for building, testing, and deploying applications.

Architecture Digest
Architecture Digest
Architecture Digest
GitLab CI/CD: Introduction, Workflow, and Quick Start Guide

GitLab CI/CD is an integrated toolset in GitLab that enables continuous integration (CI), continuous delivery (CD), and continuous deployment. It automates building, testing, and validating code changes on each push to a repository, helping catch bugs early and ensuring code quality before production.

The core of GitLab CI/CD is the .gitlab-ci.yml file placed at the repository root. This file defines jobs, stages, scripts, dependencies, and deployment instructions, which are executed by GitLab Runner.

1. GitLab CI/CD Overview

CI runs automatically on each code change, building and testing the application. CD extends CI by optionally deploying the built artifact to an environment, while continuous deployment fully automates the deployment step.

1.1 How GitLab CI/CD Works

When a .gitlab-ci.yml file is present, GitLab detects it and triggers pipelines composed of jobs. Jobs are grouped into stages (e.g., build, test, deploy) and run in parallel or sequentially depending on configuration.

before_script:  - apt-get install rubygems ruby-dev -y
run-test:
  script:
    - ruby --version

1.2 Basic CI/CD Workflow

After pushing code, the pipeline runs through stages: verify (build & test), package (store artifacts), and release (deploy). The UI visualizes pipeline status, job logs, and allows manual interventions when needed.

2. Quick Start

Create a .gitlab-ci.yml file defining stages and jobs. Example for a Ruby project:

image: "ruby:2.5"
before_script:
  - apt-get update -qq && apt-get install -y sqlite3 libsqlite3-dev nodejs
  - ruby -v
  - which ruby
  - gem install bundler --no-document
  - bundle install --jobs $(nproc)
rspec:
  script:
    - bundle exec rspec
rubocop:
  script:
    - bundle exec rubocop

Commit and push the file, then configure a Runner (VM, Docker container, or Kubernetes pod) in Settings → CI/CD → Runners . The Runner executes the defined jobs.

3. Auto DevOps

Auto DevOps provides predefined CI/CD configurations for automatic detection, build, test, deployment, and monitoring of applications, especially on Kubernetes. Enabling it under Settings → CI/CD → Auto DevOps simplifies the full DevOps lifecycle.

Examples include deploying a Spring Boot app with a pipeline that builds a JAR, pushes to a container registry, and deploys to a Kubernetes cluster.

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

The article also lists useful documentation links for deeper exploration of GitLab CI/CD and Auto DevOps.

CI/CDKubernetesdevopsGitLabPipelinerunnerAuto DevOps
Architecture Digest
Written by

Architecture Digest

Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.