Master GitLab CI/CD: Build, Test, Deploy Pipelines Efficiently

CI/CD Background

CI (Continuous Integration) means frequently merging code into the main branch and running automated tests to ensure stability. CD (Continuous Delivery/Deployment) extends CI by automatically delivering new versions to testing or production after successful verification.

Why Use CI/CD?

Automates repetitive integration, testing, and deployment tasks.

Detects and fixes issues earlier, reducing repair cost.

Accelerates delivery by catching errors early and allowing quick rollbacks.

Minimizes human error in repetitive actions.

Reduces waiting time between development, integration, testing, and deployment.

Improves product quality through built‑in code quality checks.

GitLab CI/CD Overview

GitLab CI is GitLab’s built‑in CI tool. Pipelines are triggered by events such as pushes, merges, or tags, and each pipeline consists of stages and jobs defined in a .gitlab-ci.yml file.

.gitlab-ci.yml Configuration

The file uses YAML syntax, similar to JSON but with indentation‑based structure. Example YAML snippet:

tabitha:
  name: Tabitha Bitumen
  job: Developer
  skills:
    - lisp
    - fortran
    - erlang

Key concepts:

Job

A single task in the pipeline; must contain a script section.

job1:
  script: execute-script-for-job1
job2:
  stage: build
  script:
    - scripts/build.sh
  only:
    - master

Stage

Defines a phase of the pipeline (e.g., build, test, deploy). Jobs in the same stage run in parallel.

stages:
  - build
  - test
  - deploy

Pipeline

The top‑level component that orchestrates stages and jobs. A failure in any job aborts the pipeline unless configured otherwise.

Common .gitlab-ci.yml Keywords

stage : Assigns a job to a specific stage.

script : Commands executed by the runner; multiple lines are allowed.

before_script / after_script : Commands run before or after the main script.

allow_failure : Determines whether a job failure stops the pipeline.

cache : Shares files between jobs.

only / except : Controls when a job runs based on refs, variables, or file changes.

retry : Number of retries on failure.

variables : Defines environment variables for jobs.

when : Execution condition (e.g., on_success, manual, always).

tags : Selects specific GitLab‑runner tags.

GitLab‑Runner Installation & Registration

Install the runner (example for RPM‑based Linux):

# Download
curl -LJO https://GitLab-runner-downloads.s3.amazonaws.com/latest/rpm/GitLab-runner_${arch}.rpm
# Install
rpm -i GitLab-runner_${arch}.rpm

Register the runner using the URL and token from GitLab Settings → CI/CD → Runners:

sudo GitLab-runner register
# Enter the GitLab instance URL
${url}
# Enter the registration token
${token}
# Enter a description
${description}
# Enter tags (comma‑separated)
${tags}
# Choose an executor (e.g., shell, docker)
${executor}

Building a Pipeline

After configuring .gitlab-ci.yml and the runner, push code to trigger the pipeline. Example pipeline preview:

A typical pipeline configuration:

stages:
  - scm
  - test
  - manual-point
  - deploy

scm:
  stage: scm
  script:
    - scripts/build.sh

test:
  stage: test
  script:
    - scripts/test.sh

manual-point:
  stage: manual-point
  script:
    - echo I am manual job
  only:
    - master
  when: manual
  allow_failure: false

deploy:
  stage: deploy
  script:
    - scripts/deploy.sh
  only:
    - master

When the manual job appears, the pipeline pauses until a user clicks to continue.

Scheduled Pipelines

Use GitLab Settings → Schedule to run pipelines on a cron schedule. Cron syntax uses five fields (minute, hour, day of month, month, day of week).

# * * * * *   every minute
30 10 * * *  every day at 10:30
30 10 * * SAT,SUN  every Saturday and Sunday at 10:30
0 8 1-20 * *  8:00 on days 1‑20 of each month