Introduction to Gitlab

Quality is our top priority and therefore the versioning and administration of the written code is very important for us. In order to be able to guarantee a good cooperation, we have been using the open source system Gitlab for quite some time.

Gitlab is an open source software to host and manage your own Git repositories. You can compare it to an open source github that you can run on your own server.

In addition to the main task of code management, other functionalities such as a simple issue tracking system, a wiki, and code review options are covered.

GitLab has a solid user and rights management, so users can be synchronized for example also with an existing LDAP. More than 25,000 organizations use Gitlab for their code management. Among them also considerable companies such as O`Reilly, Blackberry and Thomson Reuters.

As already described in the introduction, Gitlab is not only helpful for pure code management, we use the following functionalities, for example:

1. Management of the numerous Git repositories
2. Rights management
3. Issue tracking system with customer access
4. Code snippets
5. Webhooks (more about this in another blog article)

All customer projects as well as internal projects are versioned in our Gitlab and are therefore available in our Gitlab. In Gitlab it is possible to define groups. Each customer is created as a group and one group represents a namespace in the Git. Thus all Git repositories of a customer can be united under a uniform namespace.

This will look like the following:

• git@gitlab.domain.de:kunde/cms.git
• git@gitlab.domain.de:kunde/megacoole-erweiterung.git

Several members or a team can be assigned to a customer group. Depending on the defined authorization level, only the members of the group may push into the Git repository. In this way you can easily create the rights structures of the Git repositories.

In addition to this convenient management of Git repositories, Gitlab offers further advantages when working with repositories. The overview in the dashboard or on the project pages allows those involved in the project to easily get an overview of the current development status.

• Commits can be viewed.
• Commits can be commented and evaluated.
• Individual lines of code can be commented on.
• Branches can be visualized by graphs.

For example, we actively use these possibilities for code reviews. We do this for almost every commit, and each project participant is encouraged to review the others' code and give constructive feedback. In this way, we improve the general code, detect bugs early, and teach each other new techniques and tricks.

To avoid overhead, it is also a good idea to use gitlab's relatively simple issue tracking system. This does not offer the possibilities of systems such as Mantis, targetprocess or Jira, but due to the simple design the use is simple and intuitive and therefore suitable for a cooperation with the customer.

 Of course, we are always looking for functionality that is familiar from other systems, but the developers at gitlab are very active and every month the system is updated with new features and improvements. Of course you could develop the most necessary features yourself and submit them as a patch. After all, Gitlab is open source. Furthermore, necessary features can also be sponsored.

 But if you don't want to use the Gitlab ticket system under any circumstances, this is no problem, because known ticket systems can be easily connected. Thus, no wishes remain unfulfilled.

Last but not least we come to the Webhooks. We have grown fond of them and will even dedicate a blog entry to this topic. But what are webhooks?
First of all, a hook is something like a small script that is executed at a certain point in time. For example, when a push is made in a repository.

 Webhooks are entered in the repository administration interface. This must be accessible via URL. For example, the hook receives a JSON object with data about the commits for a push in order to be able to map the required functions.

 In our case, the notification function of Gitlab was not yet so mature in earlier versions. You could subscribe to an RSS feed of all actions, but the information sent could not be filtered sensibly. As a solution we wrote a PHP script which evaluates the information of a push with the help of the Gitlab REST API and then sends an e-mail with the diff to all team members of the project. So even without looking into the Gitlab, you are always kept up to date on what is happening in the repository.

Now I've written so much about Gitlab that you'll want to try it out sometime. In this section you will learn how to get started with Gitlab and where you can find more information about Gitlab.

As already mentioned, Gitlab can be used as a self-hosting solution. So you can install Gitlab on your own server. The installation can be very easy if you have some experience in server administration.

 The Gitlab team has written an installation guide. I tried it for you on a vServer and it worked surprisingly well.

 Except for the fact that the git version on the server was outdated and there was a minor incident when installing the RubyGems mysql2, everything worked. Despite the fact that I used an Apache2 instead of the recommended Nginx.

 But if this kind of installation is not for you, the Gitlab team also offers you a Vagrantfile with puppet recipes. With this the installation is a piece of cake. Especially for testing Gitlab it is ideal. And if you don't want the Vagrant installation either - Gitlab has recently started offering a cloud solution for that, too. But of course you don't host it yourself anymore, which can be a disadvantage!

When the user is ready to use, you can start creating a project. As you know it in computer science - we create a FooBar project.

In our example we have not created a group now and so the namespace for the new project is not group name/project name.git, but username/project name.git. As soon as a group has been created, it can be selected as namespace.

 When the project is created, a git repository with the project name is also created. How you can use these repositories will be shown on the project page until the first push.

I think the manual is self-explanatory. Now that we've initialized a git repository with our first push, you can see the information about the repository on the project page and on the dashboard. Where the feed on the dashboard is a summary of all the actions you have access to as a registered user.

 It is therefore very easy to create and manage a repository. You can view the commits in the repository. A diff is attached to the commit and this diff can be commented and rated.

As you can see from these screenshots, Gitlab is quite extensive in terms of code management and leaves nothing to be desired in this respect. Of course there are many more views.

The introduction is done! Since Gitlab is quite intuitive, many things are self-explanatory. I hope that we could make you a little desire on Gitlab and if you have questions to this Blogartikel, then write us nevertheless simply a E-Mail or contact us on the social networks. We would also be happy to accept you as customers in our Gitlab. ;-)