Gitlab 101
GitLab DevOps Platform is a Source Code Management (SCM) tool that is based on the Git version control system. This application distinguishes itself from its competitors by continuously improving its various features such as Continuous Integration (CI), Continuous Delivery (CD), security, wiki, issue tracking, and planning. It also quickly integrates innovative features like GitOps and Machine Learning (ML) pipelines
GitLab was started as an open-source project in 2011. At first, the majority part of the application was written in Ruby, and later, improvements were added using the Go language. It started with the aim of enabling software development teams to work in collaboration and then has turned into an end-to-end DevOps platform that delivers faster, more efficient and secure software. Nowadays, GitLab is very popular as a platform that offers significant ease and advantages for DevOps processes, also it is increasing popularity every year. By containing all stages of the DevOps software cycle, it greatly reduces the workload of the developers.
Every team within the companies can manage projects transparently, consistently, and traceably throughout the DevOps lifecycle using GitLab. The software planning, building and deploying can be done faster and more reliable.
The services provided by GitLab are detailed in the image above. As seen here, GitLab enables the use of a single tool for tasks such as security, storage, monitoring, and more throughout the entire process from project planning to the final stages. This point is very important. Because, it can be a challenging task to integrate multiple tools to work together correctly for software developers. GitLab provides us great advantages in this respect. These configuration processes can be easily done with the user interface, and it can also be activated through the ".gitlab-ci.yml" file, which can be referred to as the brain of CI/CD processes.
We can say that GitLab is one of the best manageable tools for CI/CD processes due to its ability to keep CI/CD processes "As Code" and its continuous development in this area over the years. There are actually two important components of GitLab for these processes. To better understand the functions of these components, let's provide an example analogy: “.gitlab-ci.yml” can be thought of as the brain, and “Gitlab-Runner” as the human body. What is meant here is that the ".gitlab-ci.yml" file defines the tasks that the pipeline will perform, and the “GitLab Runner” creates and executes the pipeline based on these settings. In summary, in order to use GitLab CI/CD, one needs to first write a YAML file named ".gitlab-ci.yml" that defines the pipeline, then install and configure GitLab Runner, and finally execute the pipeline using it.
What is “GitLab Runner”?
"GitLab Runner" is an open-source project written in the Go language. It executes the "jobs" specified in the ".gitlab-ci.yml" file and sends their outputs back to the GitLab server. It uses the GitLab API to communicate with the GitLab server. GitLab Runner" can be installed on various platforms such as Linux, Windows, MacOS, and Docker. It can test software written in different languages. For example, we can mention .NET, Java, Python, PHP, and other languages.
"GitLab Runner" can be configured in different ways. Adjusting these configurations based on the type or workload of projects can benefit the software development process. In the "Shared Runner" category, the runners can be accessed by all groups and projects within GitLab. "Specific Runners" can be authorized to work on a specific project based on user preferences. "Group Runners" can be accessed by all subgroups and projects within the same group.
What is “.gitlab-ci.yml”?
As previously mentioned, the ".gitlab-ci.yml" file is where configurations for the desired pipeline are made. In this YAML file, the following can be defined:
- The scripts you want to run.
- Other configuration files and templates you want to included.
- Dependencies and caches.
- The commands you want to run in sequence and those you want to run in parallel.
- The location to deploy your application to.
- Setting the automation or manual execution of commands.
These are some of the elements that can be defined in the ".gitlab-ci.yml" file to configure the pipeline for your project.
To better understand GitLab, let's look at its key components:
By default, a "pipeline" should have three stages: "build," "test," and "deploy." A "stage" defines when and how a "job" should be executed. Each stage can contain one or multiple jobs. The tasks to be performed in a pipeline are defined using jobs. Jobs within a stage are executed in parallel, and if all jobs in a stage are successful, the pipeline proceeds to the next stage. If a job fails in a stage, the pipeline does not proceed to the next stage.
In summary, scripts are grouped within jobs, and jobs work as smaller components of a pipeline. Independent jobs can be grouped under a stage to be executed in the desired order. It is important to prioritize the sequencing of jobs based on the project and the desired tests.
When the ".gitlab-ci.yml" file is added to the repository, GitLab detects it and the previously defined jobs start running on the GitLab Runner. Here's a simple example that illustrates the process:
Firstly, the "build-code-job" within the "build stage" is executed. This job provides the output of the Ruby version and builds the project using the "rake" command. If this stage completes successfully, the "test-code-job" jobs start running in parallel, testing the specified files.
REFERENCES:
