#  Day 4  GitLab CI/CD Pipelines


Learn Continuous Integration, Continuous Delivery, Pipelines, Stages, Jobs & `.gitlab-ci.yml`

### 📖 Introduction

In the previous articles, we explored GitLab fundamentals, repository management, and collaboration workflows. Now it's time to automate the software development lifecycle using **GitLab CI/CD Pipelines**.

Instead of manually building, testing, and deploying applications, GitLab can automate these tasks whenever changes are pushed to your repository. This automation helps teams deliver software faster, maintain consistent quality, and reduce human errors.

In this article, you'll learn the fundamentals of GitLab CI/CD, understand how pipelines work, create your first `.gitlab-ci.yml` file, and explore how GitLab executes jobs automatically from code commit to deployment.

By the end of this guide, you'll have a solid understanding of GitLab CI/CD and be ready to build your own automated pipelines.

### 🎯 What You'll Learn

After completing this article, you'll understand:

*   ✅ What is Continuous Integration (CI)?
    
*   ✅ What is Continuous Delivery (CD)?
    
*   ✅ What is GitLab CI/CD?
    
*   ✅ What is a Pipeline?
    
*   ✅ Understanding `.gitlab-ci.yml`
    
*   ✅ Stages
    
*   ✅ Jobs
    
*   ✅ Pipeline Execution Flow
    
*   ✅ Build → Test → Push → Deploy Workflow
    
*   ✅ Creating Your First GitLab CI/CD Pipeline
    

### 📚 Prerequisites

Before continuing, make sure you have:

*   A GitLab account
    
*   A GitLab repository
    
*   Git installed on your system
    
*   Basic knowledge of Git
    
*   A sample project (optional)
    

### 🚀 What is Continuous Delivery (CD)?

Continuous Delivery (CD) is the practice of automatically preparing an application for deployment after it has been successfully built and tested.

Once the CI process completes without errors, the application is packaged and made ready for release. The final deployment to production may still require manual approval, giving teams complete control over when new features are released.

Continuous Delivery reduces deployment risks and ensures that software is always in a deployable state.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/12a09162-c3b0-465b-a2bf-254541af45a8.png align="center")

## ✅ Benefits of Continuous Delivery

*   Faster software releases
    
*   Reduced deployment risks
    
*   Consistent deployment process
    
*   Higher release confidence
    
*   Applications remain deployment-ready
    

### 🔄 What is GitLab CI/CD?

GitLab CI/CD is GitLab's built-in automation platform that helps developers build, test, and deploy applications directly from their GitLab repositories.

Whenever code is pushed to a repository, GitLab automatically detects the `.gitlab-ci.yml` configuration file and starts a pipeline. Each pipeline consists of one or more stages, and each stage contains one or more jobs that execute predefined tasks.

This automation eliminates repetitive manual work, improves software quality, and accelerates the development lifecycle.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/5e4cc96b-9d02-47b3-9b39-c3d6114b4745.png align="center")

## 🔍 How GitLab CI/CD Works

A typical GitLab CI/CD workflow follows these steps:

1.  A developer pushes code to a GitLab repository.
    
2.  GitLab detects the `.gitlab-ci.yml` file.
    
3.  A new pipeline is created automatically.
    
4.  Jobs are executed stage by stage.
    
5.  If all jobs succeed, the application is ready for deployment.
    

This process runs automatically for every new commit, ensuring that code is continuously validated.

### ⚙️ What is a Pipeline?

A **Pipeline** is the core component of GitLab CI/CD. It is a sequence of automated steps that GitLab executes whenever changes are pushed to your repository.

Instead of manually building, testing, and deploying your application, a pipeline performs these tasks automatically in a predefined order.

A pipeline is divided into **Stages**, and each stage contains one or more **Jobs**. GitLab executes the stages one by one, ensuring that the previous stage completes successfully before moving to the next.

### 📄 Understanding `.gitlab-ci.yml`

The `.gitlab-ci.yml` file is the heart of every GitLab CI/CD pipeline. It defines **what should happen**, **when it should happen**, and **how GitLab should execute each job**.

GitLab looks for this file in the **root directory** of your repository. Whenever a new commit is pushed, GitLab reads this configuration file and creates a pipeline based on its instructions.

Without a `.gitlab-ci.yml` file, GitLab has no instructions to create or execute a CI/CD pipeline.

### 📁 Creating Your First `.gitlab-ci.yml` File

Now that we understand the purpose of the `.gitlab-ci.yml` file, let's create our first GitLab CI/CD pipeline.

For this demonstration, I have created a simple GitLab repository named `gitlab-practice`, which we'll use throughout this article.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/ef7f9aae-65b0-4971-a009-5c379c8c9b4e.png align="center")

### Step 1: Create the Configuration File

Inside the root directory of your repository, create a new file named:

```shell
.gitlab-ci.yml
```

GitLab automatically detects this file whenever new changes are pushed to the repository.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/af176755-74c0-4af5-b209-f4b7ea18db36.png align="center")

### **Step 2: Add Your First Pipeline**

Open the .gitlab-ci.yml file and add the following configuration:

```yaml
stages:
  - build

build_job:
  stage: build
  script:
    - echo "Hello from GitLab CI/CD!"
    - echo "Building the application..."
```

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/e6d482d1-2724-42d2-b6e0-6f49314a8247.png align="center")

This is the simplest GitLab CI/CD pipeline.

Let's understand what each section does.

### Understanding the Configuration

```shell
stages:
  - build
```

Here, we define a single stage named **build**.

A stage represents a phase of the pipeline. Every job assigned to this stage will execute when the pipeline runs.

```yaml
build_job:
```

This is the name of our first job.

You can choose any meaningful name, such as:

```yaml
build_app
compile_code
docker_build
```

The job name is only used to identify the task inside the pipeline.

```yaml
stage: build
```

This tells GitLab that the job belongs to the **build** stage.

If multiple stages exist, GitLab executes them in the order they are defined.

```yaml
script:
```

The `script` section contains the commands that GitLab Runner will execute.

In our example, it simply prints two messages to the job logs.

script:

```yaml
echo "Hello from GitLab CI/CD!"


echo "Building the application..."
```

When the pipeline runs, the output will look similar to:

```plaintext
Hello from GitLab CI/CD!
Building the application...
```

### Step 3: Commit and Push the Changes

After creating the `.gitlab-ci.yml` file, commit and push it to your GitLab repository.

```shell
git add .
git commit -m "Add first GitLab CI/CD pipeline"
git push origin main
```

As soon as the code is pushed, GitLab automatically starts a new pipeline.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/ede38c4b-9454-403b-9bfb-7e0955fd5e2b.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/1c1cf1b9-f593-48a7-b9fe-dd327fdefbf4.png align="center")

### **🚀 Step 4: Watch Your First Pipeline in Action**

After committing and pushing the `.gitlab-ci.yml` file, GitLab automatically detects the new configuration and creates a pipeline.

You don't need to start the pipeline manually. As soon as the changes are pushed to the repository, GitLab begins executing the pipeline based on the instructions defined in the `.gitlab-ci.yml` file.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/fadf10f1-b0e5-46de-90a5-9d75e4457ef0.png align="center")

### 🔍 Viewing Job Logs

Click on the pipeline, then select the **build\_job**.

GitLab opens the job details page where you can see the complete execution log generated by the Runner.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/28a5c087-c506-4e23-a5f6-ac3daeca5e72.png align="center")

### 🏗️ Understanding Stages

In our first pipeline, we created only one stage called **build**.

A **Stage** represents a phase of the CI/CD pipeline. GitLab executes stages sequentially, meaning the next stage starts only after the previous one completes successfully.

In real-world projects, pipelines usually contain multiple stages such as building the application, running tests, and deploying it.

For example:

stages:

```shell
build
test
deploy
```

This tells GitLab to execute the pipeline in the following order:

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/94dae497-6646-42f5-b77c-226879e2511b.png align="center")

### ⚙️ Understanding Jobs

A Job is an individual task that runs inside a stage.

Every job performs a specific action, such as building the application, running tests, or deploying code.

In our example, the job is named build\_job.

```yaml
build_job:
  stage: build
  script:
    - echo "Hello from GitLab CI/CD!"
    - echo "Building the application..."
```

Here:

*   `build_job` → Name of the job
    
*   `stage: build` → Assigns the job to the build stage
    
*   `script` → Commands executed by the GitLab Runner
    

When the pipeline runs, GitLab executes the commands listed under the `script` section.

### 🧩 Multiple Jobs in a Stage

A stage can contain more than one job.

```yaml
stages:
  - build

build_app:
  stage: build
  script:
    - echo "Building Application"

build_docker:
  stage: build
  script:
    - echo "Building Docker Image"
```

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/046abb38-b684-457e-bc73-e0159da4a4c9.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/1ee66e4b-6ea8-4371-a353-7f1f522322b6.png align="center")

### 🔄 Build → Test → Push → Deploy Workflow

A typical GitLab CI/CD pipeline follows four key stages. First, the application is **built** by compiling the code, installing dependencies, or creating a Docker image. Next, automated **tests** verify that the application works correctly. If all tests pass, the Docker image or build artifact is **pushed** to a container registry. Finally, the application is **deployed** to the target environment, such as a Virtual Machine, Kubernetes cluster, or cloud platform.

```yaml
stages:
  - build
  - test
  - push
  - deploy

build:
  stage: build
  script:
    - echo "Building the application..."

test:
  stage: test
  script:
    - echo "Running tests..."

push:
  stage: push
  script:
    - echo "Pushing Docker image..."

deploy:
  stage: deploy
  script:
    - echo "Deploying application..."
```

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/cdd512e5-212f-431c-a82d-23b5e8d11aea.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/bc5c4aba-84e0-4b6a-82ea-0b8704a41b1d.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/d6b3d538-c0b9-4664-bf1f-9c3c61c1dc1d.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/53557000-5906-4cd9-a06e-5ff76c9820df.png align="center")

### 🎯 Summary

Congratulations! 🎉 You have completed **Day 4** of the GitLab learning series.

In this article, you learned **GitLab CI/CD**, created your first `.gitlab-ci.yml` file, understood **pipelines, stages, and jobs**, and explored the **Build → Test → Push → Deploy** workflow.

## **👨‍💻 About the Author**

**Hi, I'm Apurv Gujjar**, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.

I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.

## **📬 Connect With Me**

📧 **Email:** [**gujjarapurv181@gmail.com**](mailto:gujjarapurv181@gmail.com)

🌐 **Portfolio:** [**https://www.apurv-gujjar.co.in**](https://www.apurv-gujjar.co.in)

🐙 **GitHub:** [**https://github.com/ApurvGujjar07**](https://github.com/ApurvGujjar07)

💼 **LinkedIn:** [**https://www.linkedin.com/in/apurv-gujjar**](https://www.linkedin.com/in/apurv-gujjar)

If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.
