{"id":4463,"date":"2026-01-25T15:30:33","date_gmt":"2026-01-25T14:30:33","guid":{"rendered":"https:\/\/informatik.htwk-leipzig.de\/seminar\/?p=4463"},"modified":"2026-01-25T15:31:43","modified_gmt":"2026-01-25T14:31:43","slug":"gitlab-ci-cd","status":"publish","type":"post","link":"https:\/\/informatik.htwk-leipzig.de\/seminar\/lehrveranstaltungen\/betriebliche-informationssysteme\/2026\/gitlab-ci-cd\/","title":{"rendered":"GitLab CI\/CD"},"content":{"rendered":"

GitLab CI\/CD<\/h1>\n

Continuous Integration (CI)<\/h3>\n

Die Praktik der Continuous Integration ist ein Bestandteil der agilen Softwareentwicklung: M\u00f6chte ein Entwickler ein Feature implementieren, so erstellt dieser sich, kontrolliert von einem Versionsverwaltungssystem, einen separaten Feature-Zweig, in welchem die \u00c4nderungen vorgenommen werden. Features werden so kleinteilig wie m\u00f6glich implementiert und ebenso so schnell wie m\u00f6glich wieder mit dem Hauptzweig des Projekts vereint. Beim Vereinen (mergen) von Branches werden die \u00c4nderungen automatisiert getestet und die Software gebaut, um im Entwicklungsprozess sicherzustellen, dass die Integration des neuen Features problemlos m\u00f6glich ist. Diese Vorgehensweise erm\u00f6glicht das parallele Arbeiten an einem Projekt mit geringem Risiko und in kurzer Zeit, jeder Entwickler ist nahezu zu jeder Zeit auf dem neuesten Entwicklungsstand, sodass es keine komplizierten Merges bzw. Integrationen des Features in den Hauptzweig geben sollte, durch Tests beim Integrieren sinken die Chancen auf Bugs.<\/p>\n

Continuous Delivery und Deployment (CD)<\/h3>\n

Zwei Aspekte der Continuous Integration sind Continuous Delivery und Continuous Deployment.
\nErsterer beschreibt, dass zu jedem Zeitpunkt in der Entwicklung die Software korrekt kompiliert bzw. \u201cbaubar\u201d ist. Dies wird erreicht, indem neue Features umgehend integriert werden sowie die Software automatisch getestet, kompiliert und in die Produktiv-\/ Testumgebung eingebunden wird. Dies geschieht \u00fcber eine Pipeline. Dem Auftraggeber der Software kann also jederzeit eine funktionsf\u00e4hige Software im aktuellen Stand vorgezeigt werden.
\nContinuous Deployment f\u00fchrt Delivery noch einen Schritt weiter: die automatisch deployte Software wird automatisch in die Produktivumgebung eingebunden und ver\u00f6ffentlicht. Unternehmen bevorzugen normalerweise aber gestaffelte Deployments, sodass nicht jedes Feature sofort ver\u00f6ffentlicht wird.<\/p>\n

Git und GitLab<\/h3>\n

GitLab ist eine Versionsverwaltungssoftware (VCS) zum hosten auf einem eigenen Server, die auf der Open-Source Software Git basiert und 2011 von den Ukrainern Dmitri Saparoschez und Valery Sizov entwickelt wurde. Privat ist GitLab in der Community Edition kostenlos, die Enterprise Edition f\u00fcr Unternehmen ist kostenpflichtig, nach dem Kauf der Konkurrenz-Plattform GitHub durch Microsoft im Jahr 2018, erlebte GitLab einen deutlichen Zuwachs an Nutzerzahlen.
\nDie Hauptaufgabe eines VCS ist es, \u00c4nderungen an Quellcode bzw. Dateien zu verfolgen und zu speichern, sodass diese \u00c4nderungen nachvollzogen und im schlechtesten Fall auch r\u00fcckg\u00e4ngig gemacht werden k\u00f6nnen. Die Projekte werden als Archive (Repositories) organisiert, welche Ordnerstruktur und Dateien beinhalten. Wie bereits weiter oben angerissen, ist das Verzweigen von Entwicklungsst\u00e4nden (Branches) ein zentraler Bestandteil von Git, sodass unabh\u00e4ngig vom Hauptzweig entwickelt und danach wieder miteinander vereinigt werden kann. Zus\u00e4tzlich zu den Git Funktionen bietet GitLab Tools f\u00fcrs Projektmanagement wie z.B. Issue Tracking und Kanban-Board zum Zuteilen und Verfolgen der Aufgaben im Team. Mit Pipelines ist es m\u00f6glich, mit dem Prinzip von CI\/CD agil zu entwickeln.<\/p>\n

Pipelines<\/h3>\n

Die CI\/CD Pipelines sind eine Kernkomponente von GitLab. Diese werden \u00fcber eine .gitlab-ci.yml Datei konfiguriert und werden durch bestimmte Trigger ausgel\u00f6st, z.B. beim Erstellen eines Branches oder beim Erstellen einer Merge Request. Dann werden nacheinander Stages bzw. Jobs auf einem Runner, einer Art virtuellen Maschine, ausgef\u00fchrt, die Code z. B. kompiliert, testet und deployt.
\n\u00dcber das GitLab Pages Feature k\u00f6nnen direkt \u00fcber die Pipeline statische Webseiten erzeugt und selbst oder \u00fcber die GitLab Dom\u00e4ne gitlab.io ver\u00f6ffentlicht werden.<\/p>\n

Stages und Jobs<\/h3>\n

Jobs werden auf einem Runner ausgef\u00fchrt und stellen die einzelnen Bausteine einer Pipeline dar. Jeder Job hat einen Namen und wird in der Konfigurationsdatei der Pipeline wie in folgendem, simplen Beispiel definiert:
\n\"\"
\nEinzelne Anweisungen stellen Befehle in der Kommandozeile dar. Jobs m\u00fcssen aber nicht ausschlie\u00dflich durch Pipelines ausgef\u00fchrt werden, sondern z. B. auch durch einen REST-API-Call oder manuell \u00fcber das Web-Interface. Auch Abh\u00e4ngigkeiten k\u00f6nnen \u00fcber das Schl\u00fcsselwort \u201cneeds:\u201d dargestellt werden, sodass die Reihenfolge der Ausf\u00fchrung festgelegt werden kann. Standardm\u00e4\u00dfig werden alle Jobs parallel ausgef\u00fchrt, sofern genug Runner vorhanden sind.
\n\"\"<\/p>\n

Jobs sind \u00fcber Stages gruppierbar. Der Unterschied zu losen Jobs liegt darin, dass Stages nacheinander ausgef\u00fchrt werden, sodass nur die Jobs innerhalb einer Stage gleichzeitig ausgef\u00fchrt werden und nicht alle gleichzeitig. Das ist n\u00fctzlich, wenn z. B. Quellcode erst \u00fcber Jobs kompiliert und danach getestet und ver\u00f6ffentlicht werden soll. Im obigen Bild sind die Stages build, test und deploy definiert. Es kann erst getestet werden, wenn die Software erfolgreich kompiliert wurde. Die Konfiguration erfolgt \u00fcber das Schl\u00fcsselwort „stage:“.
\nEin BPMN-Diagramm verdeutlicht den Ablauf:
\n\"\"<\/p>\n

Variablen<\/h3>\n

CI\/CD Variablen sind Umgebungsvariablen, die das Verhalten von Jobs und Pipelines beeinflussen sowie Werte in Job-Skripts setzen k\u00f6nnen, z. B. zum Speichern von Ordnerpfaden und Secrets\/ Passw\u00f6rtern. Es gibt neben selbst definierten- auch vordefinierte Variablen wie z. B. $CI_JOB_STAGE, welche die Bezeichnung der aktuellen Stage zur\u00fcckliefert. Variablen k\u00f6nnen entweder in der Pipeline-Konfigurationsdatei oder \u00fcber die GitLab-Weboberfl\u00e4che definiert werden, letztere M\u00f6glichkeit sollte f\u00fcr Tokens oder Passw\u00f6rter verwendet werden, um diese nicht zu ver\u00f6ffentlichen.<\/p>\n

Git Hooks<\/h3>\n

Hooks sind ein grundlegender Bestandteil des Git \u00d6kosystem und k\u00f6nnen in \u201c.git\/hooks\u201d als automatische Abl\u00e4ufe definiert werden. Diese werden entweder auf dem Server oder auf dem Client ausgef\u00fchrt. Serverseitige Hooks sind zum gr\u00f6\u00dften Teil durch Pipelines abgel\u00f6st. Clientseitige Hooks k\u00f6nnen durch die Flag \u201c–no-verify\u201d \u00fcbergangen werden. Serverseitige Hooks werden nicht \u00fcbersprungen. Die Dateien beinhalten Bash-Scripts, welche an der entsprechenden Stelle innerhalb des Commit- und Merge-Prozesses an entsprechender Stelle ausgef\u00fchrt werden.<\/p>\n

Pre Commit<\/h5>\n

Diese Hook wird noch vor dem Commiten von dem Client ausgef\u00fchrt. Somit bietet diese die m\u00f6glichkeit den Codestyle zu \u00fcberpr\u00fcfen und zu modifizieren, bevor diese commitet wird.
\nAn dieser Stelle werden Linter genutzt um einen einheitlichen codestil zu gew\u00e4hrleisten.<\/p>\n

Alternativen<\/h3>\n

GitHub<\/h5>\n

\u00c4hnlich wie das Vorgehen von GitLab ist es unter Microsofts GitHub auch m\u00f6glich, Praktiken von Continuous Integration und Continuous Deployment zu implementieren. Hierbei gibt es die GitHub Actions, diese k\u00f6nnen kostenlos bei \u00f6ffentlichen Repositories und \u00fcber selbst gehostete Runner bei privaten Repositories die Pipeline (unter Github Workflow) ausf\u00fchren. Hierbei werden die verschiedenen Stages (unter Github Actions) \u00fcber den Runner ausgef\u00fchrt. Das Nutzen eines von GitHub gehosteten Runner bietet die M\u00f6glichkeit, beispielsweise Integrationstests auf Linux, Microsoft und Mac Betriebssystemen durchgef\u00fchrt werden.<\/p>\n

Azure<\/h5>\n

Ebenso von Microsoft verf\u00fcgt Azure \u00fcber die M\u00f6glichkeit, eine Pipeline zu konfigurieren, mit der es m\u00f6glich ist, die CI\/CD-Anweisungen auszuf\u00fchren. Diese funktioniert wie GitHub Workflow und orientiert sich syntaktisch stark daran.<\/p>\n

Quellen<\/h3>\n