Learn GitLab CI/CD - History, Concepts & Core Architecture

#Introduction

In episode 0 you set up the three skill foundations — Git & GitLab workflow, YAML, and bash — plus a complete environment with glab and VS Code. Now it's time to pause the typing for a moment and understand why we're all here. Before writing your first .gitlab-ci.yml, you need to fully grasp how GitLab's architecture is designed, how its components work together, and why GitLab CI has become the primary choice at enterprise companies.

Believe it or not, the biggest mistake beginners make is jumping straight into writing pipeline YAML without understanding the architecture — the result is a pipeline that's just a collection of copy-pasted commands, hard to maintain and hard to debug. This episode builds that conceptual foundation.

#Main Discussion

#Why GitLab CI/CD Is Popular at Enterprise Scale

GitLab started in 2011 as an open-source Git hosting tool, and in 2016 released the first integrated CI/CD that runs directly inside the platform. The difference compared with other tools: GitLab is a single all-in-one application — not a set of tools stitched together with webhooks. Within one platform you get:

• Source Code Management (SCM): Git repositories, branch protection, and code review.
• Issue Tracking: issues, epics, milestones, and planning boards.
• CI/CD: automated pipelines for build, test, and deploy.
• Container Registry: a built-in Docker registry for the images you build.
• Security Dashboard: SAST, dependency scanning, secret detection, and container scanning in one view.

It's like a restaurant: with traditional tools you have to hire separate suppliers for ingredients, the chef, and the cashier. In GitLab everything lives in one kitchen — ingredients come in from commits, recipes are tested by the pipeline, and the results are served through deployments, all within a single application. This is the main reason enterprise teams choose GitLab: one workflow, one source of truth, one team managing it all.

#GitLab CI/CD Core Architecture

There are three core components you should understand forever:

• GitLab Server / SaaS — the "brain". This component stores project metadata, provides the UI and REST API, and triggers pipelines every time an event occurs (push, MR, tag). On GitLab.com, the server is fully managed by GitLab; when self-hosted, the server runs on your own infrastructure.
• GitLab Runner — the "worker". A lightweight execution agent, separate from the server. The runner listens for commands from the GitLab Server, picks up jobs from the queue, executes them, then reports the results back. It can run on a local machine, VM, Docker, or Kubernetes.
• .gitlab-ci.yml — the declarative file at the repository root that describes the entire pipeline. This file is the "recipe": if it exists in the repository, GitLab automatically reads it and executes it every time an event occurs.

When a commit is pushed, this is the flow that happens:

Developer pushes commit to GitLab
        |
        v
GitLab Server detects .gitlab-ci.yml
        |
        v
Server creates pipeline and queues jobs
        |
        v
Runner picks up job, checks out code, executes script
        |
        v
Runner sends log and status back to GitLab Server
        |
        v
Status appears in UI, merge request, and notifications

#Pipeline Execution Hierarchy: Stages, Jobs, Scripts

Inside .gitlab-ci.yml, the pipeline executes based on a three-level hierarchy:

• Stages — the sequence of execution phases. Classic example: build → test → deploy. All jobs in the same stage run in parallel; the next stage only starts after every job in the previous stage succeeds.
• Jobs — specific units of work within a stage. Each job holds a single responsibility — for example a unit_test job and a lint job both sitting in the test stage.
• Scripts — the list of CLI commands executed within a job. If any command returns a non-zero exit code, the job is considered failed.

stages:
  - build
  - test
  - deploy
 
unit_test:
  stage: test
  script:
    - npm test

You can see the pattern: stages defines the order, unit_test is a job placed in the test stage, and npm test is the script being run. A simple mental picture: a pipeline is a building, stages are its floors, jobs are the rooms on each floor, and scripts are the work done inside those rooms.

#GitLab CI vs GitHub Actions vs Jenkins Comparison

To make GitLab's position clear, let's compare it with its two main competitors:

No choice is absolutely wrong — Jenkins is still great for full control, and GitHub Actions shines for teams in the GitHub ecosystem. GitLab CI is chosen when you want a single application to handle the entire development flow, from repository to security dashboard, without the cost of integrating tools together.

#Closing

In this episode 1, you've built important conceptual foundations:

• Why GitLab is popular at enterprise: a single all-in-one application covering SCM, issue tracking, CI/CD, container registry, and security dashboard.
• Core architecture: GitLab Server as the orchestrator, GitLab Runner as the executor, and .gitlab-ci.yml as the declarative pipeline definition.
• Execution hierarchy: stages (phases), jobs (units of work), and scripts (CLI commands) arranged from large to small.
• Tool comparison: GitLab CI's advantages and position among GitHub Actions and Jenkins.

Now you know how the architecture works, it's time to understand how to write it. In episode 2 we'll create your first .gitlab-ci.yml with the basic syntax: global keywords, stages definition, job structure, inline and multi-line scripts, and allow_failure for handling errors. See you in episode 2!