GitLab CI basics - Deep Dive

Overview - GitLab CI basics

What is it?

GitLab CI is a tool that helps automate tasks like testing and deploying code whenever changes are made. It uses simple files to define steps that run automatically on a server. This means developers don't have to do repetitive work manually. It makes software development faster and more reliable.

Why it matters

Without GitLab CI, developers would spend a lot of time running tests and deploying code by hand, which can cause mistakes and delays. Automating these tasks ensures that code is always checked and delivered quickly, improving software quality and team productivity. It helps teams catch problems early and release updates smoothly.

Where it fits

Before learning GitLab CI, you should understand basic Git commands and how code repositories work. After mastering GitLab CI basics, you can explore advanced topics like pipelines, multi-project workflows, and deployment strategies.

Mental Model

Core Idea

GitLab CI automatically runs defined steps on your code changes to test and deliver software without manual work.

Think of it like...

GitLab CI is like a smart kitchen assistant that follows your recipe exactly every time you cook, so you don’t have to remember each step or worry about mistakes.

┌─────────────┐      ┌───────────────┐      ┌───────────────┐
│ Developer   │─────▶│ GitLab Server │─────▶│ Runner (Agent)│
└─────────────┘      └───────────────┘      └───────────────┘
       │                    │                      │
       │ Push code           │                      │
       │ triggers pipeline   │                      │
       │                    │ Executes jobs defined│
       │                    │ in .gitlab-ci.yml    │
       │                    │                      │
       ▼                    ▼                      ▼

Build-Up - 7 Steps

1

Foundation

What is GitLab CI and why use it

Concept: Introduce GitLab CI as a tool for automating code testing and deployment.

GitLab CI is part of GitLab that runs tasks automatically when you change your code. These tasks can check if your code works (tests) or send it to users (deploy). It saves time and reduces errors by doing these steps for you.

Result

You understand that GitLab CI helps automate repetitive tasks in software development.

Knowing the purpose of GitLab CI helps you see why automation is important for fast and reliable software delivery.

2

Foundation

Understanding the .gitlab-ci.yml file

Concept: Learn the configuration file that tells GitLab CI what to do.

GitLab CI uses a file named .gitlab-ci.yml in your project. This file lists jobs and stages, like 'test' or 'deploy', with commands to run. GitLab reads this file to know what steps to perform automatically.

Result

You can identify the key file that controls GitLab CI pipelines.

Recognizing the .gitlab-ci.yml file as the control center is essential to customizing automation.

3

Intermediate

Jobs and stages in pipelines

🤔Before reading on: do you think jobs run one after another or all at once? Commit to your answer.

Concept: Introduce the concepts of jobs (tasks) and stages (groups of jobs) in a pipeline.

A pipeline is made of stages like 'build', 'test', and 'deploy'. Each stage has jobs that run commands. Jobs in the same stage run at the same time, but stages run one after another. This order controls the flow of automation.

Result

You understand how GitLab CI organizes tasks to run in order and in parallel.

Knowing the difference between jobs and stages helps you design efficient pipelines that save time.

4

Intermediate

Using GitLab Runners to execute jobs

🤔Before reading on: do you think GitLab Server runs jobs itself or uses separate machines? Commit to your answer.

Concept: Explain that GitLab Runners are agents that run the jobs defined in pipelines.

GitLab Server sends jobs to Runners, which are separate machines or containers that actually run the commands. Runners can be shared or specific to projects. They make sure jobs run in a clean environment.

Result

You know how jobs get executed outside the main GitLab server.

Understanding Runners clarifies how GitLab CI scales and isolates job execution.

5

Intermediate

Basic example of a pipeline configuration

Concept: Show a simple .gitlab-ci.yml example with build and test jobs.

Example: stages: - build - test build_job: stage: build script: - echo "Building..." test_job: stage: test script: - echo "Testing..." This runs build_job first, then test_job.

Result

You can write a simple pipeline that runs two jobs in order.

Seeing a real example helps you connect theory to practice and start creating your own pipelines.

6

Advanced

Handling job failures and retries

🤔Before reading on: do you think a failed job stops the entire pipeline or just that job? Commit to your answer.

Concept: Learn how GitLab CI handles job failures and how to retry jobs automatically.

If a job fails, the pipeline usually stops at that stage and later stages don't run. You can configure retries to try a job again if it fails temporarily. This helps avoid pipeline failures due to flaky tests or network issues.

Result

You understand failure handling and can make pipelines more resilient.

Knowing failure behavior prevents wasted time and helps maintain pipeline reliability.

7

Expert

Optimizing pipelines with caching and artifacts

🤔Before reading on: do you think each job starts fresh or can reuse files from previous jobs? Commit to your answer.

Concept: Explore how caching and artifacts speed up pipelines by sharing files between jobs.

Caching saves files like dependencies so jobs don’t download them every time. Artifacts are files produced by one job that later jobs can use, like test reports. Proper use of these features reduces pipeline time and resource use.

Result

You can optimize pipelines for speed and efficiency in real projects.

Understanding caching and artifacts is key to scaling pipelines and saving resources in production.

Under the Hood

GitLab CI works by monitoring your code repository for changes. When you push code, GitLab Server reads the .gitlab-ci.yml file and creates a pipeline with stages and jobs. It then assigns jobs to GitLab Runners, which are separate processes or machines that run the commands in isolated environments like containers. The Runner reports back job status and logs to GitLab Server, which shows the pipeline progress in the web interface.

Why designed this way?

GitLab CI was designed to separate the control plane (GitLab Server) from execution (Runners) to allow scalability and security. Using a YAML file for configuration makes pipelines easy to read and version control. The staged pipeline model balances parallelism and order, enabling efficient and predictable automation.

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│ GitLab Repo │──────▶│ GitLab Server │──────▶│ GitLab Runner │
└─────────────┘       └───────────────┘       └───────────────┘
       │                     │                        │
       │ Push code            │ Parse .gitlab-ci.yml   │
       │                     │ Create pipeline jobs   │
       │                     │                        │
       │                     │ Send jobs to Runner    │
       │                     │                        │
       │                     │◀───── Job status ──────┤
       ▼                     ▼                        ▼

Myth Busters - 4 Common Misconceptions

Quick: Does a failed job always stop the entire pipeline? Commit yes or no before reading on.

Common Belief: If one job fails, the whole pipeline stops immediately.

Reality: Only jobs in the current stage stop; jobs in previous stages are done, and jobs in later stages do not run unless configured to allow failures or continue.

Why it matters: Assuming total pipeline failure can cause confusion and unnecessary pipeline reruns.

Quick: Do you think GitLab Runner is part of GitLab Server? Commit yes or no before reading on.

Common Belief: GitLab Runner is built into GitLab Server and runs jobs internally.

Reality: GitLab Runner is a separate service that runs jobs outside the server, allowing distributed and isolated execution.

Why it matters: Misunderstanding this can lead to deployment mistakes and scaling problems.

Quick: Can you use any file name instead of .gitlab-ci.yml for pipeline config? Commit yes or no before reading on.

Common Belief: You can name the pipeline config file anything you want.

Reality: GitLab CI only recognizes the .gitlab-ci.yml file at the root of the repository by default.

Why it matters: Wrong file naming means pipelines won’t run, causing confusion and delays.

Quick: Does caching always speed up pipelines? Commit yes or no before reading on.

Common Belief: Caching always makes pipelines faster without downsides.

Reality: Improper caching can cause stale data or increased storage use, sometimes slowing pipelines or causing bugs.

Why it matters: Blindly caching without understanding can introduce hard-to-find errors.

Expert Zone

1

GitLab CI allows conditional job execution using rules and only/except keywords, enabling complex workflows.

2

Shared Runners are convenient but can cause resource contention; using specific Runners improves performance and security.

3

Pipeline efficiency depends heavily on how caching and artifacts are managed; small misconfigurations can cause large slowdowns.

When NOT to use

GitLab CI is not ideal for extremely complex workflows requiring fine-grained orchestration or real-time event handling; specialized tools like Jenkins or Argo Workflows may be better. Also, for very small projects, manual scripts might be simpler.

Production Patterns

In production, teams use multi-stage pipelines with separate jobs for linting, building, testing, and deploying. They use environment variables for secrets, deploy only on protected branches, and use manual approval steps for production deployment.

Connections

Continuous Integration (CI)

GitLab CI is a specific implementation of the general CI concept.

Understanding GitLab CI deepens your grasp of how continuous integration automates software quality checks.

Containerization (Docker)

GitLab Runners often use Docker containers to run jobs in isolated environments.

Knowing Docker helps you understand how jobs run cleanly and consistently across different machines.

Assembly Line in Manufacturing

GitLab CI pipelines are like assembly lines where each stage adds value in order.

Seeing pipelines as assembly lines helps appreciate the importance of order and parallelism in automation.

Common Pitfalls

#1 Pipeline does not run because the config file is missing or misnamed.

Wrong approach:

Using a file named gitlab-ci.yml or ci.yml instead of .gitlab-ci.yml

Correct approach:

Naming the file exactly .gitlab-ci.yml at the root of the repository

Root cause:

Not knowing GitLab CI requires a specific filename and location for the pipeline config.

#2 Jobs run sequentially even though they could run in parallel, wasting time.

Wrong approach:

Defining all jobs in the same stage but with dependencies that force order, or putting all jobs in one stage

Correct approach:

Splitting jobs into different stages and using parallel jobs within the same stage

Root cause:

Misunderstanding how stages and jobs control execution order and parallelism.

#3 Pipeline fails due to missing dependencies every time.

Wrong approach:

Not using caching or downloading dependencies in every job from scratch

Correct approach:

Using cache keyword to save and restore dependencies between jobs

Root cause:

Not leveraging caching to optimize pipeline speed and reliability.

Key Takeaways

GitLab CI automates testing and deployment by running jobs defined in a .gitlab-ci.yml file whenever code changes.

Pipelines are organized into stages and jobs, where jobs in the same stage run in parallel and stages run sequentially.

GitLab Runners execute jobs outside the main server, enabling scalable and isolated job execution.

Proper pipeline design includes handling failures, using caching, and managing artifacts to optimize speed and reliability.

Understanding GitLab CI’s structure and behavior helps avoid common mistakes and build efficient automation workflows.