If you have just heard about the software “GitLab“ for the first time and you are unsure, what it is, how it works, how it is related to git and what is it used for then you have come to the right place.
This article answers all these questions, to get you up to speed to working with GitLab!
Let’s start with the most basic question.
What is GitLab? GitLab is an open-source version control system with integrated DevOps and software life-cycle management tools. In simpler words, Gitlab is an app that helps you maintain your git repository, do automated testing, with several other features like issue tracking and automated deployment.
In a way, it is similar to GitHub, as it lets you host your repository on their servers, but it comes with a lot of added features to make our lives as software engineers easier.
Now that we know what GitLab is, let’s proceed to see how it works and have a look at the various terminologies GitLab uses to get ourselves acquainted better with the GitLab environment.
Architecture of Gitlab
Let’s start by looking at the various components that GitLab is made of. Gitlab is basically made of 2 parts
- Gitlab Server
- Gitlab Runners
Gitlab server
The GitLab server is the central part of the GitLab architecture. It basically has 2 duties
- It holds the git repository
- It controls the GitLab runners
Thus Gitlab server is the computer that holds our git repositories. Along with holding the git repository, it also lets the user view the contents of our repo from a web browser interface. To achieve this, GitLab servers either use Apache or NGINX web server software in the backend on its computer. So in simple words, GitLab Server is a web server, that gives the end-user information about the git repositories hosted in it.
Have a look at the diagram below.
As you can see, there can be multiple clients to the GitLab server.
Let’s assume that you are working on a team and your entire team is working on a given project, and the source code of the project is hosted on a GitLab server. All of your teammates can have access to the source code via the GitLab server’s web user interface. All they need to do is log in to their accounts and the Gitlab server will show them the projects that they are part of.
If you are familiar with GitHub, I guess you have some experience using a web interface to access your git repository. Yes, GitLab Server works almost exactly the same way as GitHub. Next, let’s see the differences between GitLab and GitHub and see what makes GitLab special.
GitLab vs GitHub
The next logical question that comes into mind is
How is GitLab different from other services like Github and bitbucket? If you are using GitHub or BitBucket and you wish to keep your source code private, you need to have a paid account on these services. But on GitLab, you can download and install their server software in one of your own computers and use it as a GitLab server! You can even access your server remotely with the right network settings!
That’s just one difference between GitLab and GitHub, as GitLab offers plenty more advantages like DevOps, Automated Building and Testing, etc, as you will see in the rest of the article!
Now that we have seen about the GitLab server’s role in handling our git repos, let’s next discuss its role in controlling the GitLab runners.
Gitlab Runners
What is GitLab runner and what does it do?
According to GitLab runner documentation
GitLab Runner is the open-source project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with GitLab CI, the open-source continuous integration service included with GitLab that coordinates the jobs
From <https://docs.gitlab.com/runner/>
I guess the above explanation is getting a bit technical with some jargon, so let’s try and break it down and try to understand it better!
Let’s assume you and your team are working on source code for a project in visual studio. Logic says if someone tries to upload a broken code to the git repository the commit must not be accepted. But the Git software by itself can’t do that since it only tracks the changes made to the source code and doesn’t care if the code will compile or not.
So we need a way to compile to source code to make sure that there are no build errors before we take in any commits in the remote central repo.
That’s where GitLab runners come in. GitLab Runner is essentially a program that can automate the process of building and testing the source code before adding it to the repository.
Role of Gitlab runner in the Gitlab architecture
Gitlab runner can be either installed on the same computer that the GitLab server is running or kept on a separate machine. It is advisable to keep it in a separate machine as the GitLab runners functionality is implemented using scripts and its not a good idea to let users run their own scripts on the same machine that contains the source code repository.
Now that we have added Gitlab runner our system gets a little bigger and looks like in the image below.
As you can see we can also have more than one instance of GitLab runners. Each of these runners can be on a separate computer or in the same one. The real use of having multiple runners is scalability.
Assume you are part of a very large organization of 1000 programmers and they are working on about 100 projects. If you have only one GitLab runner, then if one of these 1000 programmers push their code to the GitLab server, then the server will start this one and the only runner to build and test the code.
Now if another programmer, part of a different project wants to push his code, then the GitLab server will see if there are any free runners. But since we have only one runner and that runner is already busy the latest push will have to wait till the runner gets free.
Imagine 50 other developers push their code to the GitLab server in the meantime! By the time the only runner does the building and testing all this code, the workday will be over!
To make this process more efficient we need more runners. This brings us to another job of the GitLab server, which is to automatically coordinate with and manage all the runners. It does so by seeing which runner is free and provide them with jobs to do.
So that’s the reason behind having many runners. Depending on how large your team is, you can have as many runners as needed!
Now that we have seen about the 2 components that make up GitLab: the GitLab Runner and Server, let’s see some of the capabilities that GitLab provides us with other than what we have already seen above.
Other capabilities of GitLab
This includes the DevOps capabilities of Gitlab. We have already seen about one of the DevOps duties which is to build and make sure that the code compiles before it gets added to the repository. But now let’s look at the other DevOps duties that GitLab can do.
What is DevOps? DevOps stands for development operations. It can be divided into 2 groups of activities
- Continuous Integration and
- Continuous Deployment
What is Continuous Integration? It is an automated process in which the code submitted by developers is built and thoroughly tested. Once all the tests are passed the code submitted is added to the repository. It is usually abbreviated in the industry as CI.
What is Continuous Deployment? It is an automated process in which the code that is recently integrated using CI is run through some final staging and production tests and then automatically delivered to the end-users.
What else can runners do other than compiling our source codes? The list below summarizes what you can do with GitLab other than compiling source codes
Continuous integration
- Run unit tests
- Perform code quality checks
- Run system-level tests
Continuous Delivery
- Perform live tests by Staging the software inhouse in a testing environment
- Deliver the update to the end-user
As you can see, GitLab is a fairly powerful tool at automating many tasks in the software development process.
Summary
To summarize this entire article, Gitlab consists of 2 parts
- Gitlab Server and
- Gitlab runners
The GitLab server is in the middle, it is connected to the developer’s computers through HTTP, which can be seen on the right and to help the GitLab server do its DevOps duties, we have several GitLab runners on the left!
If you can understand everything in the image above then you have successfully familiarized yourself with GitLab, it’s architecture, components, and features.
In the next article (link to be updated soon, once the article is ready) let’s see how to install and configure your own GitLab environment, locally on your computer to suit your needs!
Alright, let’s stop here.
I hope you guys learned something through this post and hope it was useful to you guys.
You can email us or contact us through this link if you have any questions or suggestions.
If you liked the post, feel free to share this post with your friends and colleagues!
