GitLab: A single application for the entire DevOps lifecycle

This article is the first in a series of four, where we, four Computer Science master students from Delft University of Technology, will be analysing the open-source project GitLab. In this series we will be conducting an analysis for several aspects about managing an open-source project, both technical and non-technical. Before we dive into these aspects in later articles, we will first provide some context on what Gitlab is and where it is going.

What is GitLab and where did it come from?

GitLab is a web-based DevOps lifecycle tool which, according to their own claims, offers a “single application for the entire DevOps lifecycle”. This lifecycle, among other things, includes Git-repository management, issue tracking and CI/CD.

The project was started by Ukrainians Dmitriy Zaporozhets and Valery Sizov around 2011, who at the time needed a tool to better collaborate with their team. The company was officially founded in 2014 with the Dutch Sytse Sijbrandij as CEO and Dymitriy as CTO. Around this time the company had short of ten employees and the tool itself would later be described by Head of Product Mark Pundsack as an “ugly, open source knock-off of GitHub”. However, in the years after that GitLab experienced significant growth, it became a so-called unicorn and is now valued at $2.75 billion with over 1150 employees¹.

Interestingly, when you try to visit their address, you will find a UPS store where they have a mailbox. This is because they are a remote-only company, self-proclaiming to be the largest². Having no office has its implications which we will later discover and is one of the reasons they are so reliant on their own tool to develop GitLab itself and various other associated services.

Open-source vs open-core

Despite GitLab being an open-source project, most of its contributions are made by employees of GitLab Inc. This company is the driving force behind the project and ensures continuity. There are two editions of GitLab available to allow the company to pay its employees. First, there is the Community Edition (CE), the free and complete open-source version including, but not limited to, all the contributions of non-employees. Then there is the paid Enterprise Edition (EE) which uses the CE at its core but includes additional features and functionality on top of the core³.

The source code, issues and pull requests of both editions are publicly available. The difference between open-source and open-core is in essence that an open-source project is completely free to use, while an open-core project is partly free to use and a fee has to be payed for additional functionality. In further research, we will focus mainly on the open-source free-to-use Community Edition of GitLab, unless mentioned otherwise.

As described before, GitLab aims to deliver “a single application for the entire DevOps lifecycle”. Source code management, issue tracking, time tracking and continuous integration are the minimum required features to accomplish this. These are all integrated in the Community Editon. Integrations with other tools and features improving the efficiency and quality of the DevOps lifecycle are provided by the Enterprise Edition.

The problem of many stakeholders

There are several different kinds of users involved in the DevOps lifecycle and thus does GitLab maneuvers itself in a difficult position with many different stakeholders involved. Developers, project managers, operation managers and DevOps engineers are just a few examples of end users of the application. They all have different demands and different processes and workflows. To accommodate for all these different needs, GitLab had to find a very flexible way of setting up a development process. Their solution to this will be described in the next section.

What makes GitLab very interesting is that they use a strategy called dogfooding, which means that the whole company uses GitLab for their own product development. For example software engineers not only build the software for GitLab, they also use the GitLab software for development of GitLab. This double role holds for almost any employee of GitLab, which makes the entire company an end user of their own product. Being an end user themselves, makes it also easier to place themselves into the shoes of their customers and therefore develop for the needs of many different stakeholders.

Different users, different needs

Having so many different stakeholders, GitLab had the problem of many different end-user mental models as well. Each role in the lifecycle will have different ways to interact with the system. To unify these models, GitLab has a few core services, which are simple, but very flexible⁴. These will be described below.

• Projects Projects are used as a top level distinction between different systems, applications or company departments.
• Issues Issues provide a way to document any changes, improvements or bugs in the project.
• Repositories The repository provides a way to store files with version control using Git in the project.
• Merge requests Merge requests can be used as a way to discuss, improve and analyze changes to the repository.
• CI Provides continuous validation of the repository state and can prevent any bugs covered by automated testing.

Combining these above features, almost all stages in the DevOps lifecycle are covered and each department can use a (sub)set of these features in their daily workflow. As an example we take a software developer who works on project X. The developer is assigned to fix a bug in project X and to see what the bug actually is, he takes a look at the issue. In the issue is documented what the problem is and the developer can ask questions in the issue if something is unclear. Then when he has fixed the bug, he commits it to the repository and opens a merge request. After review by another developer, the merge request is merged and by using CI the developers know this fix did not cause another bug.

As you can see, the developer makes use of most core services and interacts with different people, without having to use different platforms. The product manager who documented the bug can also easily see the progress of the fixes in the same application by looking at the status of the merge request.

The Future

GitLab started in 2013 as a repository management system like Github. It lets teams share code, keep track of issues and collaborate. Over time GitLab grew from an open-source project to an open-core company, providing a single application for the entire DevOps Lifecycle. With their product, GitLab aims for product leadership, already having reached that for Continuous Integration and Source Code Management⁵. GitLab aims to reach this stage in the near future for Continuous Deployment and Release Automation, Project management and Application Security Testing as well.

In a 2018 livestream⁶, GitLab’s Head of Product Mark Pundsack explained that they want to step away from ‘Minimum Viable Changes’ and towards ‘Minimum Lovable Feature’. In essence, this means that they aim to increase the depth of some of their features. Their main features, like Source Code Management and Continuous Integration, are far more mature than most other features. By making all features lovable, GitLab aims to create a product where its users love using all parts of it.

GitLab’s roadmap aims at maturing their DevOps categories like Managing, Monitoring and Releasing, with new features like Status Pages, Secrets Management and Code Analytics⁷.

Finally, there is a list of moonshot ideas⁸ that may take a long time to implement, test and deliver. Ideas are applicable to both the open-source community edition and the proprietary enterprise edition and range from better experience from the command line tools and IDEs to features that better accommodate machine learning projects and microservices.

In this article, we tried to give a brief introduction to GitLab, its history, business model, users, and future plans. We will use this information in the upcoming article where the software architecture is subject to our investigation.