GitLab is a web-based DevOps lifecycle tool. It is used by developers to store software code, maintain versions, share with other developers, and provides useful features such as CI/CD which help developers focus on their main task: developing software. GitLab consists of two versions: a community edition and an enterprise edition. The former is opensource and free to use, while the latter is paid and holds extra features and customer support. Both versions offer the ability to host projects online or on your own servers. GitLab itself is written in Ruby, using the Ruby on Rails framework, and maintained on its own platform.

In 2016 another team, following the same course, has also analysed Gitlab1. The aim is to built upon their work, highlight the differences and progress made since then.

Team Introduction

We are four Computer Science master students at the Delft University of Technology. We all recently concluded our bachelor Computer Science and Engineering at said university. Most of our team have experience with GitLab and found it interesting that a project hosting service is itself open-sourced. Furthermore, it seemed like a very large project with lots of contributors which makes it interesting to analyse. It also interested us because GitLab is a remote-only company, which we hope means they are used to - and perhaps more open to - contributions and discussions with strangers.

  • Rolf de Vries
  • Bram van Walraven
  • Rico Hageman
  • Hilco van der Wilk
  1. Martijn Pronk, Han Lie, Jasper Denkers, Christian Veenman, Delft Students on Software Architecture DESOSA 2016, GitLab: Code, Test & Deploy Together 

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.

Architecting for everyone’s contribution

In this second article in a series of four, we, four Computer Science master students from Delft University of Technology, continue our pursuit to analyse the open-source project GitLab. In our previous article, we discussed the fundamental concepts and product vision of GitLab. In this article, we will dive deeper into the key architectural elements of the system to gain a better understanding how these concepts and visions were realised.

Staying on the Rails: A Quality Assessment

In our last article, we looked at the architectural decisions made during the development of GitLab. The vision behind most decisions was to enable everybody to contribute. This time, we will look at the different methods used to maintain high-quality standards for a software project where everybody is invited to contribute. Furthermore, we will investigate the project in detail to highlight potential points of improvement.

Towards a greener DevOps lifecycle

This is the last part of our series about the open-source project GitLab. Previously we have talked about the context, the architecture and the quality assurance processes of GitLab. To finish off, in this article we will make a sustainability analysis of both GitLab as the company and as the project. We will assess the supported and used infrastructure, search for features improving energy efficiency and investigate the impact of being an all-remote company. Additionally, we will see how GitLab employees value sustainability for them and the company.