GitLab CI/CD#
GitLab ist ein mächtiges Continuous Integration/Continuous Delivery-Werkzeug (CI/CD), das auf der Basis von Git-Repositories arbeitet. GitLab legt über Git-Repositories eine Verwaltungsschicht, die es u.a. erlaubt, Repositories in Gruppen zu organisieren und den Zugang zu den Repositories zu kontrollieren. Darüber hinaus gibt es viele Möglichkeiten, einen CI/CD-Prozess zu implementieren.
Die GitLab-Allegra-Integration bietet
Zuordnung von Git-Commits zu Vorgängen
Zuordnung von Git-Branches zu Vorgängen (in Arbeit)
Zuordnung von Git-Pull Requests zu Vorgängen (in Arbeit)
Liste geänderter Dateien je Vorgang
Liste von Git-Commits in Cockpit-Kachel
Einen integrierten Repository-Browser
Direkte Links in den GitLab-Repository-Browser (in Arbeit)
Für Um Commits und Dateien in Ihrem Git-Repository mit Allegra zu verknüpfen, müssen Sie beim Commit in Ihrem
Commit-Kommentar eine Referenz auf betroffene Vorgänge in der Form „#<Vorgangsnr.>“, also z.B. „#4711“
eingeben.
Um ein Versionskontrollsystem zu integrieren, muss ein entsprechendes Plug-In im Verzeichnis
$ALLEGRA_HOME/plugins installiert sein. Für das jeweilige Projekt bzw. den Bereich muss die Funktion
“Versionskontrolle” aktiviert sein (Verwaltung > Bereiche > <Bereich> > Versionskontrolle).
In dieser Ansicht können Sie alle notwendigen Einstellungen zur Anbindung an ein Git-Repository vornehmen.
GitLab-Projekte konfigurieren#
Jedem Allegra-Arbeitsbereich kann ein GitLab-Projekt zugeordnet werden. Benötigt man mehrere Repositories, können entsprechend viele untergeordnete Allegra-Arbeitsbereiche erstellt werden und diesen dann wieder Repositories zugewiesen werden. Die Konfiguration erfolgt deshalb über ein Projekt und dort über den Navigationspunkt „Versionskontrolle“.
Jedes GitLab-Projekt verwaltet ein zugehöriges Git-Repository. Allegra muss auf das GitLab-Projekt und das darunter liegende Repository zugreifen können. Deswegen muss das GitLab-Projekt auch in Allegra bekannt gemacht werden. Dazu dienen die folgenden Einstellungen.
GitLab Server-Name und Server-Port#
Die URL und der Git-Port zum Repository-Server
GitLab Projekt-ID#
In GitLab hat jedes Projekt eine Identifikationsnummer. Die Projektnummer identifiziert eindeutig ein GitLab-Projekt auf einem GitLab-Server und ist genau einem Git-Repository zugeordnet.
Konfiguration der GitLab-Integration#
Vorgangsnummer-Muster#
Allegra verknüpft solche Commits die in ihrer Commit-Message Allegra-Vorgangsnummern referenzieren. Auch Branches und Pull Requests lassen sich auf diese Weise markieren.
Die eingebetteten Vorgangsnummern werden dabei anhand des hier festgelegten regulären Ausdrucks erkannt. Wenn bereichsspezifische Vorgangsnummern eingestellt sind, wird nach allen Präfixen gefolgt von einem Bindestrich gefolgt von einer Zahl gesucht.
Typ |
Wie |
Beispiel |
|---|---|---|
Branch |
Branches werden verknüpft, wenn die Vorgangsnummer im Namen des Branch enthalten ist. |
CDU-9022-Neugestaltung der GitLab-Integration |
Commit |
Commits werden verlinkt, wenn die Vorgangsnummer in der Commit-Nachricht enthalten ist. |
Gitlab-Integration überarbeiten (#4711, #3302) |
PR |
Pull-Requests werden verlinkt, wenn der Fehlerschlüssel im Titel des Pull-Requests oder im Namen des Quellzweigs enthalten ist. |
DSGV-1119 - Neugestaltung des Login-Bildschirms |
Authentifizierungs-Methoden#
Das System unterstützt die folgenden Authentifizierungs-Methoden:
Anonymous : Nur für direkten Zugang über das file-Protokoll
Kennwort: Sie benutzen Benutzername und Kennwort
Public/private key: Sie benutzen ein Schlüsselpaar
Token: Sie verwenden einen von GitLab erzeugten Access Token.
Repository-Browser#
Das System verfügt über einen integrierten Repository-Browser. Sie können darauf über die Cockpit-Kachel „Versionsverwaltung“ und beim Bearbeiten eines Vorgangs zugreifen, indem Sie auf den Commit-, Branch- oder Pull Request-Link klicken.
Außerdem können Sie direkt in den GitLab-Browser springen, was besonders angenehm ist, wenn GitLab und Allegra mit demselben SSO-System geschützt sind.
Aktualisierung von Allegra durch Git#
Allegra kann seine Versionskontroll-Daten auf zwei Arten mit einem GitLab-Server synchronisieren:
Über einen zeitgesteuerten automatischer Prozess alle x Minuten, wobei x in der Datei
$ALLEGRA_HOME/quartz-jobs.xmlangepasst werden kann.Über einen Rest-Endpunkt. Wenn das System dort eine POST-Anforderung erhält, aktualisiert es alle Versionskontrolldaten. Die URL ist:
{Allegra Server URL}/rest/vcPlugin/fetchLogs. Sie können diese Endpoint-URL in Hook-Skripten Ihres Git- oder GitLab-Servers verwenden.
Versionskontroll-Cockpit-Kachel#
Die Versionskontroll-Cockpit-Kachel kann alle Versionskontroll-Aktivitäten in einem Allegra-Projekt darstellen, unabhängig vom darunter liegenden Versionskontrollsystem. Klickt man auf den zugehörigen Link, kommt man in den Versionskontroll-Browser, je nach Konfiguration in den internen oder einen externen.
Cockpit-Kachel für Versionskontroll-Darstellung#
Versionskontrolle in Vorgangsansicht#
Im unteren Teil der Vorgangsbearbeitungsmaske werden im Reiter „Versionskontrolle“ alle diesem Vorgang zugeordneten Commits, Branches und Pull Requests gezeigt. Die Verknüpfung erfolgt dabei wie weiter oben beschrieben über die Vorgangsnummern als Bestandteil des Commit-Textes bzw. des Namens für Branches und Pull Requests.
Dem Vorgang zugeordnete Commits, Branches und Pull Requests#
Integrierter Repository-Browser#
Der interne Repository Browser bietet sich vor allem dann als Alternative zum Browser des GitLab-Servers an, wenn es keine Single Sign On-Integration gibt.
Der interne Repository Browser#