Build and test your program using Gitlab Pipeline

Photo by Clément Hélardot on Unsplash

Table of Contents

  1. CI/CD
  2. Gitlab Pipeline
  3. .gitlab-ci.yml


As a programmer, I often come up to the longest part when I developed new features in my program, which is to manually test and debug the code to make sure it performs well and fulfil the specifications. The iteration process of that we took to build and test our program consumes a lot of time and resources. This is where CI/CD come in handy.

CI stands for Continuous Integration, while CD stands for Continuous Delivery/Deployment. CI/CD holds a role to automate software development stages from building, testing, and deploying. By implementing this method, programmer will only need to focus on their code rather than doing operational stuffs like manually building and scanning through testcases to spot bugs in the system.

Below are some benefits of implementing CI/CD in software development activities:

  • Increase programmer productivity.
  • Discover bugs in early stages.
  • Provide faster release cycles.

Gitlab Pipeline

Photo by Pankaj Patel on Unsplash

As a repository management services, Gitlab provides CI/CD tools for all projects hosted in Gitlab. In practice, every commits or pushes that are made by developers will be built and tested automatically if the project already has its pipeline configured.


Pipeline is the top level component of CI/CD. It determines what commands or activities that need to be done during the automation process. It consists of:

  • Jobs : define what to do. For instance, jobs to compile or unit-test code. All of the jobs are executed by gitlab-runners.
  • Stages, define when to run the jobs. For instance, all of the test jobs should be done after build or compilation stages.

Normally, CI/CD pipeline consists of at least 4 stages:

  • Build: stage to install dependencies, compilation processes, and build the repo.
  • Test: test whether the repo pass all our testcases.
  • Staging: deployment to the staging environment if the program pass all of the testcases to make sure once more before going live through production.
  • Production: deployment to production environment so that it can run the services.

Types of pipeline

There are several types of pipeline:

  • Basic pipeline: Every stages are executed sequentially (in order). Every job in the same stage is executed concurrently if there are enough runners.
  • DAG pipeline: DAG stands for Directed Acyclic Graph. We can configure relationships and dependencies between jobs so that it can run faster than basic pipeline.
  • Child/parent pipeline: We can define sub pipelines in a parent pipeline that can only be triggered by specific events. More detailed explanation about child/parent pipeline and other pipeline types are in this documentation.


.gitlab-ci.yml is a yml-formatted file located in the root of our repository and contains our CI/CD configuration. In this file, we should define some aspects such as:

  • Scripts that needs to be run
  • Files or templates that should be included
  • Libraries and dependencies
  • Command to be executed

Scripts are grouped into jobs and multiple jobs are grouped into stages that run as part of a larger pipeline.

Jobs keywords

Below is a list of some keywords that are usually needed to define jobs.

  • stage : state the stage of the job.
  • image : specify what Docker image to used in the job.
  • services : specify additional Docker image to be used.
  • script : set of commands that are executed sequentially in the job formatted as list.
  • cache : files or directories to cache or shared between pipelines and jobs.
  • artifacts : files or directories attached to a job after it is finished (successed, failed, or always attached).
  • before_script : set of commands that are executed before scripts but after all of the artifacts are restored.
  • rules : list of conditional clauses that define whether a job should be executed in a pipeline.
  • variables : custom values that are passed to jobs.
  • only or except : control when to add jobs to a pipeline (almost similar to rules ).

File sample

Here is a sample of .gitlab-ci.yml file in Maven project development from Gitlab contributed examples.

In the above code snippet, we can see that the pipeline uses latest tag of Maven Docker image. It also set up two local variables and cache so that it has a shared directories for all the jobs. It has three jobs, which are build , test , and deploy with each resides in different stage. The interesting part of this pipeline is that deploy job will only be executed if the commit is in master branch and developers are able to experiment their feature developments in other branches.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Working on with SCoRe Lab for GSoC 2020: Week 11


Project Success: Time To Get Your Metrics Right

Building a Basic Calculator App with Kivy (a Python Framework)

4 Key Considerations For Salesforce Data Migration

HomeGuy3: #compressedairpipinglayout Not All Pipes Are Fit to Be the Same

Redeeming Benefits of the AWS Certification

A Riveting Issue: Logistics, Recessions, Tobacco Farming, and Free Software | Week #12

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Fauzan Ragitya

Fauzan Ragitya

More from Medium

How to Use Git Hooks for Shift Left on Continuous Integration

How to Expand Your Testing Repertoire

Using Git and GitLab for Software Development Team Collaboration

Can Ci/Cd get on with databases?