To follow along with the instructions in this chapter, please download the Git repository with examples, commands and instructions, available at GitHub: https://github.com/PacktPublishing/Mastering-GitLab-12/tree/master/Chapter01. Look in the Readme.md file for a general explanation of the content of the directory.

To run or install software used in this chapter you need one of the following platforms:

• Debian 10 Linux codename 'Buster'
• CentOS 7.x or RHEL (Red Hat Enterprise Linux) 7.x
• macOS Sierra or later

The story began in 2011, when Dimitri Zaporozhets, a web programmer from Ukraine, was faced with a common problem. He wanted to switch to Git for version management and GitHub to collaborate, but that was not allowed in his company. He needed a tool that did not hinder him in developing code and was easy to use. Like many developers, he had issues with the collaboration tool that he was obliged to use. To get around those issues, he created his side project in Ruby on Rails: GitLab. Together with his colleague, Valery Sizov, he developed this project alongside his regular work.

After this initiative, the project grew enormously:

The core of the GitLab software is called the CE. It is distributed under the MIT license, which is a permissive free software license created at the Massachusetts Institute of Technology. You are allowed to modify the software and use it in your creations.

No feature that ever made it to CE will ever be removed, or moved to a closed source version. When GitLab EE was created in 2013, it was, at its core, GitLab CE, but it had additional enterprise features, such as Lightweight Directory Access Protocol (LDAP) groups. Those features are not open source, per se, but can be added to the core version if they are perceived by the company as a core feature. The idea was that companies should also contribute as much as possible to solving problems and creating new features.

In 2016, the GitLab EE product was divided into three tiers: Starter...

GitLab is not a monolithic application. It tries to follow the Unix philosophy, which means that a software module should do only one particular thing, and do it well. The components that GitLab is made of are not as small and elegant as Unix's awk and sed, but each component has a single purpose. You can find a high-level overview of these components in the following diagram:

Gitlab started as a pure Ruby on Rails application, but some components were later redesigned using Go. Ruby on Rails is a development framework built on top of the Ruby programming language. It implements a model-view-controller pattern and offers methods to connect to different databases (for example, ActiveRecord). It values convention over configuration and don't-repeat-yourself (DRY) programming. It is very well suited to rapid development, and at the...

GitLab CI is a feature that helps perform the Continuous Integration (CI) of software components. When several developers work together using a versioning system, problems can arise when changes made by one developer break the product as a whole. The best way to make sure this happens less often, or at least early in the process, is to use integration tests more frequently, hence the name continuous.

GitLab CI was launched as a standalone project in 2013, but was later integrated into the main GitLab package. Combined with the GitLab Runner software, this feature has been very popular with developers and is an important driver of the business. It also enabled GitLab to build their product into a solution that not only does CI, but even continuous delivery up to production environments. The current product vision for GitLab is to serve as a complete DevOps life cycle...

GitLab Runners were originally developed by Kamil Trzciński in 2015. They're now one of the most popular features of GitLab.

The initial GitLab-CI-Runner was a very simple application written in Ruby, but worked well in quite basic setups. You can think of it as a reference implementation of what a bare runner could look like.

The main problem with the old runner is that it could only run one concurrent job at a time. If you wanted to run more, you could either set up a new server or create an additional user to build jobs.

Secondly, it always ran projects on the server shell. This made it really hard to test projects using different versions of Ruby or any other dependencies...

Toward the end of 2016 and at the start of 2017, there was a public debate in the GitLab community about whether reverting back from the cloud to bare metal would be cost-effective for GitLab.com. At the time, the filesystem used for repositories was Ceph. The performance of that distributed filesystem was not good enough to handle GitLab.com. They asked the community for advice and received a lot of feedback from people who experienced similar moves firsthand. In the end, the decision was made to stay in the cloud (https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/). Instead, GitLab would focus on creating a solution, not on the filesystem level, but making sure that Git input/output (I/O) behavior is better managed at the application level. This can be seen as the birth of the Gitaly component. Sid Sijbrandij emphasized the importance of being...

In this chapter, we have learned about the people and the organization behind GitLab. Starting from the beginning, we have shown you how the project has developed over the years. We went through the core components of GitLab and how to install them. For some components, we included ways to debug the installation.

We also gave a brief introduction to GitLab CI and the client programs that interact with it, such as GitLab Runner. We showed you why this feature is so important and how it is perceived by the IT industry.

In the next chapter, we will install and configure GitLab on different kinds of systems. If you're new to the product, prepare to be amazed!

1. When and by whom was GitLab initially developed?
2. How is GitLab funded?
3. Name all the programming languages that are used in the GitLab software.
4. Which licenses are used by GitLab?
5. Why are they using these licenses?
6. Name the core components of GitLab.
7. How many offices does GitLab have?
8. What is stored in Redis?
9. What has Gitaly replaced?
10. Which cloud service was chosen by GitLab to focus on in 2018?

• Sidekiq—source and documentation: https://github.com/mperham/sidekiq
• Ruby on Rails: https://rubyonrails.org
• Unicorn: https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-tricks/
• Cloud Native programming with Golang by Mina Andrawos, Martin Helmich: https://www.packtpub.com/in/application-development/cloud-native-programming-golang
• Nginx HTTP Server - Fourth Edition by Clement Nedelcu, Martin Fjordvald: https://www.packtpub.com/in/virtualization-and-cloud/nginx-http-server-fourth-edition
• Mastering Redis by Jeremy Nelson: https://www.packtpub.com/in/big-data-and-business-intelligence/mastering-redis
• PostgreSQL Administration Cookbook, 9.5/9.6 Edition by Simon Riggs, Gianni Ciolli, Gabriele Bartolini: https://www.packtpub.com/in/big-data-and-business-intelligence/postgresql-administration-cookbook-9596-edition