Understanding GitLab Pipelines

# CHAPTER 2

Understanding GitLab Pipelines #

1. Introduction #

In GitLab, the "conveyor belt" that moves your code from a developer's laptop to a live production server is called a Pipeline. However, a pipeline is not just one massive script; it is a highly structured, orchestrated sequence of events. To master GitLab CI/CD, you must first master the vocabulary and architecture of how pipelines execute. In this chapter, we will dissect the anatomy of a pipeline, exploring the hierarchical relationship between Stages, Jobs, and the robotic servers (Runners) that actually execute your commands.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Define the structural components of a Pipeline.

• Differentiate between a "Stage" and a "Job".

• Understand how Jobs within the same Stage execute in parallel.

• Understand how Stages execute sequentially.

• Define what a GitLab Runner is.

3. Beginner Explanation #

Imagine a commercial car wash.

• The Pipeline: The entire car wash tunnel from start to finish.

• The Stages: The distinct zones in the tunnel.

1. 1. *Stage 1: Washing*

1. 2. *Stage 2: Rinsing*

1. 3. *Stage 3: Drying*

• The Jobs: The specific machines inside each zone.

• In the *Washing* stage, the "Soap Sprayer Job" and the "Scrubbing Brush Job" happen at the exact same time (in parallel).

• The Execution Order: The car cannot move to the *Drying* stage until the *Rinsing* stage is 100% complete. If the *Washing* stage breaks down, the conveyor belt stops, and the car never reaches the drying stage.

This is exactly how your code is processed.

4. The Architecture of a Pipeline #

Every GitLab Pipeline is defined by three primary layers:

1. Stages (The Timeline) Stages define the *chronological order* of execution. By default, standard DevOps pipelines use three stages:

• build (Compile the code)

• test (Run automated security and quality checks)

• deploy (Push the code to a live server)

*Rule: Stage 2 (test) will absolutely not start until Stage 1 (build) finishes successfully.*

2. Jobs (The Work) Jobs are the actual tasks to be done. A Job belongs to a Stage.

• Inside the test stage, you might have two Jobs:

• securityscanjob

• unittestjob

*Rule: Jobs inside the SAME stage run simultaneously (in parallel), saving massive amounts of time.*

3. Runners (The Robots) GitLab itself does not run your code. GitLab is just the manager. When a Pipeline is triggered, GitLab hands the Job instructions to a GitLab Runner. A Runner is a separate server (usually a Linux machine or a Docker container) that wakes up, executes your terminal commands, reports the success or failure back to GitLab, and then goes back to sleep.

5. Mini Project: Run First GitLab Pipeline #

Let's trigger a pre-built pipeline in the GitLab UI to see the architecture in action.

Step-by-Step Walkthrough:

1. 1. Navigate to your gitlab-ci-practice project on GitLab.com.

1. 2. On the left-hand sidebar, hover over Build and click Pipelines.

1. 3. You will likely see a blank screen because we haven't written a configuration file yet.

1. 4. Let's create a dummy pipeline. Click the blue Run pipeline button.

1. 5. In the next screen, click Run pipeline again.

1. 6. *Wait, why did it fail or say "No stages/jobs for this pipeline"?* Because GitLab requires a specific configuration file to know what to do! We will write this file in the next chapter.

1. 7. *Observation:* Look at the UI structure. Even when empty, you can see the tabs for "All", "Finished", "Branches", and "Tags". This dashboard will be your command center once your pipelines are active.

6. Real-World Scenarios #

A massive e-commerce company pushes new code for their shopping cart.

• The Pipeline triggers.

• Stage 1 (Build): The code is compiled into a Docker container.

• Stage 2 (Test): Three jobs run in parallel: frontendtests, backendapitests, and databasemigrationtests.

• *Disaster!* The databasemigrationtests Job fails because of a typo in the SQL code.

• Because that Job failed, the entire Test Stage fails.

• Because the Test Stage failed, the Deploy Stage is automatically canceled. The broken code never reaches the customers. The developers are notified via Slack to fix the typo.

7. Best Practices #

• Maximize Parallelism: If you have 500 automated tests, do not put them all in one massive Job that takes 45 minutes to run. Break them into 5 separate Jobs (e.g., testauth, testpayment, testui) and put them all in the test Stage. GitLab will run all 5 jobs at the same time using 5 different Runners, reducing your total testing time to 9 minutes.

8. Common Mistakes #

• Stage Dependency Confusion: Beginners often put a deployment job in the test stage by accident. This causes the code to be deployed to the live server at the *exact same time* it is being tested, entirely defeating the purpose of the Quality Gate. Always ensure strict sequential separation between Testing and Deployment.

9. Exercises #

1. 1. Explain the relationship between "Stages" and "Jobs" regarding sequential versus parallel execution.

1. 2. What is the role of a "GitLab Runner" within the CI/CD architecture?

10. FAQs #

Q: What happens if I don't define any Stages in my configuration? A: If you don't explicitly define your own stages, GitLab CI falls back to a default set of stages: .pre, build, test, deploy, and .post. However, professional engineers always explicitly define their stages for clarity.

11. Summary #

In Chapter 2, we mapped the architectural blueprint of GitLab CI/CD. We broke down the monolithic concept of a "Pipeline" into digestible, hierarchical components. We established that Stages dictate the sequential timeline of our automated factory, ensuring quality gates are respected. We learned that Jobs are the specific, parallelized tasks executed within those stages. Finally, we introduced the GitLab Runner, the unseen robotic workforce that actually processes our code.

12. Next Chapter Recommendation #

We understand the theory of the pipeline, but how do we actually write the instructions for the robots? Proceed to Chapter 3: GitLab CI YAML Syntax.