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.

✅ 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.

🔍 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.

Step 1: Create the Configuration File

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

.gitlab-ci.yml

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

Step 2: Add Your First Pipeline

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

stages:
  - build

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

This is the simplest GitLab CI/CD pipeline.

Let's understand what each section does.

Understanding the Configuration

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.

build_job:

This is the name of our first job.

You can choose any meaningful name, such as:

build_app
compile_code
docker_build

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

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.

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:

echo "Hello from GitLab CI/CD!"


echo "Building the application..."

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

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.

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.

🚀 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.

🔍 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.

🏗️ 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:

build
test
deploy

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

⚙️ 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.

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.

stages:
  - build

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

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

🔄 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.

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..."

🎯 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

🌐 Portfolio: https://www.apurv-gujjar.co.in

🐙 GitHub: https://github.com/ApurvGujjar07

💼 LinkedIn: 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.