2.5 Gitlab

Dieses Kapitel behandelt die Verwendung von GitLab. Es werden nur einige der wichtigsten Punkte abgedeckt, da die Features von GitLab sehr umfassend sind.

Merge Requests

Ein Merge Request (bei GitHub Pull Request genannt) ist eine Anfrage ans Team, bei welchem Konfigurationsänderungen oder neue Features auf den Master Branch des Repositories gemerged werden sollen. Je nach Repository gibt es spezifische Konventionen, an die man sich halten sollte, bei /sys sind dies zum Beispiel diese hier.

Berechtigungen

GitLab kennt ein Berechtigungsmodell, welches in mehrere Stufen unterteilt ist. Nachzulesen gibt es dieses hier

GitLab CI

GitLab CI ist ein sehr mächtiges Tool, um Buildprozesse zu automatisieren. Hooks sind nur ein kleiner Bestandteil der Möglichkeiten, die sich damit ergeben. Es sei die Introduction von GitLab empfohlen, welche die Grundkonzepte und den Workflow gut erklärt. Ein wichtiger Teil von GitLab CI sind wie in der Introduction erwähnt Pipelines. Um sich ein Bild von einer “richtigen” Pipeline zu machen, ist z.B. diejenige im ansible-puzzle Repository ein gutes, wenn auch relativ ausführliches Beispiel.

Weitere Einstellungen und Features

Protected Branches

GitLab bietet die Möglichkeit, Branches “vor Commits zu schützen”. Dies ist vorallem dann sinnvoll, wenn grössere Teams an einem Repository entwickeln, und mit Merge Requests arbeiten. Ein protected Master Branch zum Beispiel schützt davor, dass unerwünschte Änderungen über automatisierte Deployments aus Versehen in der Produktion landen. Dieses Feature unterstützt auch das Vier-Augen-Prinzip, damit alle Änderungen garantiert den Merge Prozess durchlaufen müssen.

Branches vergleichen

Ein praktisches Feature ist die Möglichkeit, Branches zu vergleichen. Beispielsweise: ansible-puzzle