GitLab CI/CD. Main concepts and terms

2 minute read

If you want to use Continuous Integration (CI) and Continuous Delivery (CD) services you need to know basic terms using in GitLab. I selected the foremost ones and set links to the description and additional information about them.

Configuration file

For using a CI/CD service you need to create a .gitlab-ci.yml file to the root directory of your repository. This file is used by GitLab Runner to manage your project’s jobs and stored in a YAML format.


GitLab Runner is a daemon in a host machine that is used to running your jobs and send the results back to GitLab. It permanently holds a connect with Gitlab. When a user runs job by pipeline Runner executes commands from .gitlab-ci.yml on the host.


Jobs are set of commands that stored in section script in a config file. GitLab Runner runs jobs in a host machine. Each job is run independently of each other. The most popular jobs are a build_web_app1, build_web_app2, prepare, test, deploy, and etc.


A stage allows to group jobs, and jobs of the same stage are executed in parallel. Jobs of the next stage are run after the jobs from the previous stage complete successfully.


A pipeline is a group of jobs that get executed in stages (batches). All of the jobs in a stage are executed in parallel and if they all succeed the pipeline moves on to the next stage. If one of the jobs fails the next stage is not (usually) executed. You can access the pipelines page in your project’s Pipelines tab.


An artifact is a list of files and directories which are attached to a job after it completes successfully. The uploaded artifacts will be kept in GitLab during expiry period. You can download the artifacts archive or browse its contents in Job Info page.


GitLab provides a full history of your deployments per every environment. Environments are like tags for your CI jobs, describing where code gets deployed. GitLab keeps track of your deployments, so you always know what is currently being deployed on your servers. For example, you can create and use typical environments - production and staging.


When defined jobs exist in a dependency block of your .gitlab-ci.yml the Runner should be download all artifacts before start the current job. It can be used to divide build and deploy jobs for example. The deploy job often uses generated artifacts on previous stages.

Next post will describe how to install and configure a GitLab Runner for using it in your first pipeline.