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:
🚀 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:
A developer pushes code to a GitLab repository.
GitLab detects the .gitlab-ci.yml file.
A new pipeline is created automatically.
Jobs are executed stage by stage.
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.
