327 lines
26 KiB
TeX
327 lines
26 KiB
TeX
\documentclass{article}
|
|
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage{helvet}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage[ngerman]{babel}
|
|
\usepackage{multicol}[]
|
|
\usepackage{blindtext}
|
|
\usepackage{float}
|
|
\usepackage{booktabs}
|
|
\usepackage{makecell}
|
|
|
|
\usepackage{fancyhdr}
|
|
\usepackage{geometry}
|
|
\usepackage{abstract}
|
|
\usepackage{graphicx}
|
|
\usepackage{acronym}
|
|
\usepackage{hyperref}
|
|
|
|
\usepackage{amsmath}
|
|
|
|
\usepackage{biblatex}
|
|
|
|
\graphicspath{ {./bilder/} }
|
|
|
|
\geometry{
|
|
a4paper,margin=25mm
|
|
}
|
|
|
|
\title{\huge{Dev Ops mit Microservices - GitLab}}
|
|
\date{\today}
|
|
\author{
|
|
\begin{tabular}{ccc}
|
|
\textbf{Roman Schöne} & \textbf{Christopher Schmitt}\\
|
|
2211275 & ???????\\
|
|
roman.schoene@stud.th-mannheim.de & christopher.schmitt@stud.th-mannheim.de
|
|
\end{tabular}\\\\
|
|
Technische Hochschule Mannheim
|
|
}
|
|
\addbibresource{literatur/dms.bib}
|
|
|
|
\renewcommand\familydefault{\sfdefault} % Helvetica
|
|
|
|
\begin{document}
|
|
\pagestyle{fancy}
|
|
%... then configure it.
|
|
\fancyhead{} % clear all header fields
|
|
\fancyhead[L]{GitLab}
|
|
\fancyhead[R]{DMS - DevOps mit Micro Services}
|
|
\fancyfoot{} % clear all footer fields
|
|
\fancyfoot[LE,RO]{\thepage}
|
|
|
|
\maketitle
|
|
|
|
\begin{abstract}
|
|
\blindtext
|
|
\end{abstract}
|
|
|
|
|
|
|
|
|
|
\begin{multicols}{2}
|
|
\tableofcontents
|
|
|
|
\section{Einleitung}
|
|
|
|
\subsection{Motivation}
|
|
|
|
\textbf{\ac{CI}} ist eine Methodik zur Softwareentwicklung. Ziele der Vorgehensweise sind die Erstellung von qualitativen Quellcode, durch stetiges Überprüfen der Funktionalität des verfassten Code. Der Entwicklungsstand einer Software liegt innerhalb des sogenannten Hauptzweiges. Entwickler nehmen fortlaufend kleinere Änderungen vor und bauen diese innerhalb kurzen Entwicklungszyklen in den Hauptzweig ein. Der Entwickler stellt eine Anfrage, ob sein Code in den Hauptzweig aufgenommen werden kann (Pull Request). Damit eine korrekte Funktionsweise des Hauptzweiges sichergestellt werden kann, wird jeweils eine Reihe an Tests durchgeführt. Schlagen diese Tests fehl, so muss der Entwickler seine Änderungen ausbessern und den Prozess erneut anstossen und wiederholt diesen Schritt solange bis die Tests erfolgreich sind. Die Änderungen können somit in den Hauptzweig übernommen werden (Merge).
|
|
Häufig findet \ac{CI} in Kombination mit agiler Projektmethodik statt. \cite{arefeen_continuous_2019}.\\
|
|
\textbf{\ac{CD}} beschreibt den durch \ac{CI} notwendigen Aspekt der Automatisierung. Eine manuelle Durchführung der Tests benötigt einen höheren zeitlichen Aufwand und kann fehlerhaft durchgeführt werden. Zu den Vorteilen von \ac{CI}/\ac{CD} zählen eine frühe Fehlererkennung und schnellere Entwicklungszyklen.
|
|
GitLab ist eine Plattform, die es ermöglicht \ac{CI}/\ac{CD} in Verbindung mit agiler Entwicklung umzusetzen.
|
|
Nach der jährlichen Entwicklerumfrage von Stack Overflow, ist GitLab, mit 35.6 \%, neben GitHub, mit 81.8 \%, und Jira, mit 46.4 \% eine der meistgenutzten Plattformen zur Dokumentation und zur kollaborativen Zusammenarbeit an Code \cite{2025StackOverflow}. Siehe \ref{fig:stackoverflow-devsurvey-tools}
|
|
\begin{figure}[H]
|
|
\includegraphics[width=\linewidth]{bilder/stack_overflow_developer_survey_collab_tools_documentation.png}
|
|
\caption{Auswahl der 10 meist verwendeten Dokumentations- und Kollaborations Werkzeuge nach Stack Overflow Survey 2025 \cite{2025StackOverflow}}
|
|
\label{fig:stackoverflow-devsurvey-tools}
|
|
\end{figure}
|
|
Diese wissenschaftliche Ausarbeitung beschäftigt sich damit, inwiefern sich die von GitLab v18.11 bereitgestellten Werkzeuge bzw. Möglichkeiten eignen um eine beispielhafte Anwendung zu entwickeln, zu testen und einzusetzen. Ebenso wird betrachtet in welchen Punkten sich die Implementierung von \ac{CI}/\ac{CD} in GitLab zu seinem Mitstreiter GitHub unterscheidet.
|
|
\subsection{Softwarelösung}
|
|
GitLab ist eine mit Git kompatible Plattform für Code-Hosting. Der Code von GitLab ist in Ruby verfasst \cite{degeler_gitlab_2014}. Unter der Haube verwendet Git die relationale Datenbank PostgreSQL. Auf GitLab kann mithilfe einer Weboberfläche zugegriffen werden \cite{gitlab_about}. Es wird differenziert in die kostenfreie \ac{CE} und kostenpflichtige \ac{EE}.
|
|
GitLab kann in folgenden unterschiedlichen Formen genutzt werden:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{\ac{SaaS}} Die Plattform wird innerhalb der Cloud von GitLab gehostet. Die Arbeit mit GitLab kann sofort gestartet werden.
|
|
\item \textbf{Selbst gehostet} GitLab kann auf linux-basierten Servern selbst betrieben werden. Installation, Konfiguration und Administration der Infrastruktur muss selbst übernommen werden.
|
|
\item \textbf{Dediziertes \ac{SaaS}} Für Unternehmen und Regierungen kann GitLab in eigenen isolierten Instanzen verwendet werden, um hohe Sicherheitsstandards und gesetzliche Regulierungen zu gewährleisten.
|
|
\end{itemize}
|
|
|
|
Für die \ac{SaaS}- und die selbst gehostete Variante von GitLab gibt es drei unterschiedliche Preispläne: Free, Premium und Ultimate. Tabelle \ref{tab:saas_plans} zeigt eine Auswahl an Funktionalitäten und deren Verfügbarkeit nach Preisplan. In der selbst gehosteten Variante von GitLab sind die technischen Limitierungen Nutzeranzahl, Rechnungszeit und Speicher von der Bereitstellung eigener Serverkapazitäten abhängig. Die Verfügbarkeit der restlichen Funktionalitäten ist analog.
|
|
\begin{table}[H]
|
|
\begin{tabular}{@{}llll@{}}
|
|
\toprule
|
|
& \multicolumn{3}{c}{Verfügbarkkeit} \\ \midrule
|
|
Preisplan & Free & Premium & Ultimate \\ \midrule
|
|
Nutzerzahl & 5 & $\infty$ & $\infty$ \\
|
|
\makecell[cl]{Rechnungs-\\zeit} & 400 min & 10000 min & 50000 min \\
|
|
Speicher & 10 GiB & 500 GiB & 500 GiB\\\midrule
|
|
\ac{CI}/\ac{CD} & X & X & X\\
|
|
\makecell[cl]{Container-\\Scan} & X & X & X\\
|
|
Web \acs{IDE} & - & X & X\\
|
|
Pushregeln & - & X & X\\
|
|
\makecell[cl]{Integrierte\\Testfälle} & - & - & X\\ \midrule
|
|
\makecell[cl]{Zeitracking} & X & X & X\\
|
|
Wikis & X & X & X\\
|
|
\makecell[cl]{Issue-\\Gewichte} & - & X & X\\
|
|
\makecell[cl]{Projekt-\\analyse} & - & X & X\\
|
|
\makecell[cl]{Statusseite} & - & - & X\\
|
|
\midrule
|
|
Preis & 0\texteuro & \makecell[cl]{29\texteuro je$\frac{\text{Nutzer}}{\text{Monat}}$} & \makecell[cl]{kunden-\\spezifisch}\\ \bottomrule
|
|
\end{tabular}
|
|
\caption{Auswahl an Funktionalitäten und deren Verfügbarkeit, nach Preisplan \cite{gitlab_about}}
|
|
\label{tab:saas_plans}
|
|
\end{table}
|
|
|
|
\subsection{Geschichte}
|
|
|
|
GitLab wurde von Sytse Sijbrandij und von Dmitriy Zaporozhets gegründet. Zaporozhets entwickelte GitLab 2011 als Hilfsmittel für seine eigenen Projekte. GitLab war zu dem Zeitpunkt eine private und freie Plattform zum eigenen Code-Hosting, entwickelt von Zaporozhets. Zaporozhets und Sijbrandij lernten sich auf der \href{https://thenextweb.com/conference}{The Next Web} Konferenz kennen. Nachdem Zaporozhets sich entschied den Quellcode von GitLab frei zugänglich zu machen, entstand die Partnerschaft mit Sijbrandij. Um den Einstieg in die Nutzung von GitLab zu erleichtern entschieden sich Sijbrandij GitLab als \ac{SaaS} unter der Domain \url{https://gitlab.com/} anzubieten. Der Quellcode von GitLab ist frei unter \url{https://gitlab.com/gitlab-org/gitlab} verfügbar \cite{degeler_gitlab_2014}. Der Quellcode des Konkurrenten GitHub ist nicht frei zugänglich. 2014 wurde GitLab erstmalig als Unternehmen eingetragen und erfuhr seitdem einen grossen Zuwachs an Mitarbeitern. Aktuell zählt GitLab mehr als 2600 Mitarbeiter, die über 65 Länder verteilt leben \cite{gitlab_about}. GitLab selbst besitzt keinen grossen ausgebauten Firmenhauptsitz, da Mitarbeiter hauptsächlich remote arbeiten und freie Verfügung über ihre Arbeitszeit besitzen. Der organisatorische Aufbau und der Ablauf interner Prozesse von GitLab, können in dem von GitLab öffentlichem Handbuch \url{https://handbook.gitlab.com/} nachgelesen werden \cite{choudhuryGitLabWorkWhere2020}.
|
|
GitLab finanziert sich durch Spenden um neue Funktionalitäten zu realisieren. Ein weiterer Teil der Einnahmen kommt durch den Abschluss von kostenpflichtiger Abonnements. \cite{degeler_gitlab_2014}.
|
|
Abbildung \ref{fig:gitlablogo} zeigt das Logo von GitLab. Es besteht aus einem Tanuki, einem in Japan heimischen Waschbärhund, und dem GitLab Schriftzug.
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=0.8\linewidth]{./bilder/gitlab-logo-100-rgb.png}
|
|
\caption{Logo GitLab}
|
|
\label{fig:gitlablogo}
|
|
\end{figure}
|
|
GitLab erregte in mehreren Fällen mediale Aufmerksamkeit auf sich. 2017 verlor die \ac{SaaS}-Lösung von GitLab sechs Stunden an Nutzerdaten, aufgrund von einer menschlichen Fehlreaktion, ausgelöst durch Spamanfragen die in Problemen mit der Datenbank resultierten \cite{GitLabcomDatabaseIncident}. GitLab wagte im Oktober 2021 den Gang an die Börse und ist aktuell als Aktie im \ac{NASDAQ} unter dem Kürzel: GTLB erhältlich \cite{teamGitLabIncGTLB}.
|
|
Ebenso bestanden 2022 Pläne inaktive Repositories löschen. Nach starker Kritik wurde sich dazu entschieden, anstatt zu löschen, zu archivieren \cite{onlineVersionsverwaltungGitLabRudert2022}.
|
|
|
|
\subsection{Aufbau}
|
|
|
|
Zusammenarbeit in GitLab ist in Form von Gruppen organisiert. Diese können in Subgruppen unterteilt werden. Gruppen und Subgruppen können Projekte und Mitarbeiter zugeordnet werden.
|
|
Jedes Projekt besteht aus einer Issue-Seite und einem Code-Repository. Für ein Projekt kann optional ein Wiki angelegt werden, um Informationen in Form von \ac{GLFM} zu dokumentieren \cite{gitlab_gitlab_nodate}. \ac{GLFM} ist eine spezielle Markdown-Spezifikation, welche die grundlegende Definition erweitert. Projekte besitzen folgende Sichtbarkeitsstufen:
|
|
\begin{itemize}
|
|
\item \textbf{Public} Als öffentlich zugängliche Ressourcen kann jedermann zugreifen. Ein Zugriff ist auch ohne einen GitLab Account möglich.
|
|
\item \textbf{Internal} Nur GitLab-Nutzer können auf die als intern markierte Ressource zugreifen.
|
|
\item \textbf{Private} Nur Nutzer die explizit als Mitarbeiter/Teilnehmer zu einem Projekt hinzugefügt wurden, können auf private Ressourcen zugreifen.
|
|
\end{itemize}
|
|
Ein Projekt wird immer unter einem Namensraum angelegt. In GitLab wird in 2 Typen von Namensräumen unterschieden:
|
|
\begin{itemize}
|
|
\item \textbf{Nutzer} Der Namensraum von einem Nutzer kann keine Subgruppen enthalten. Wird sich entschieden den Nutzernamen zu ändern, so ändert sich auch die URL des Namensraum
|
|
\item \textbf{Gruppe} Innerhalb von Gruppen können Subgruppen erstellt werden, welche ihre Einstellungen vorerst von ihrer Elterngruppe erben.
|
|
\end{itemize}
|
|
Tabelle \ref{tab:namespaces} zeigt eine Auflistung beispielhafter Namensräume mit entsprechender URL für eine Gitlab-Instanz unter der Domain \texttt{domain.com}.
|
|
\begin{table}[H]
|
|
\centering
|
|
\resizebox{\columnwidth}{!}{%
|
|
\begin{tabular}{@{}lll@{}}
|
|
\toprule
|
|
Namensraum & URL & Beschreibung \\ \midrule
|
|
\texttt{max} & https://domain.com/max & \makecell[cl]{Nutzer mit Namen \\ \texttt{max}} \\
|
|
\texttt{team} & https://domain.com/team & \makecell[cl]{Gruppe mit Namen \\ \texttt{team}} \\
|
|
\texttt{team/design} & https://domain.com.com/team/design & \makecell[cl]{Subgruppe \texttt{design}\\ der Gruppe \texttt{team}} \\ \bottomrule
|
|
\end{tabular}%
|
|
}
|
|
\caption{Beispielhafte Namensräume von Projekten in GitLab}
|
|
\label{tab:namespaces}
|
|
\end{table}
|
|
GitLab unterscheidet in folgende Nutzertypen, die auf eine GitLab Instanz zugreifen können \cite{gitlab_gitlab_nodate}:
|
|
\begin{itemize}
|
|
\item \textbf{Auditor} Ein Auditor besitzt nur Lese-Zugriff auf alle zur Verfügung stehenden Ressourcen. Auditoren werden in der Praxis meist verwendet um die Einhaltung von bspw. gesetzlichen Regularien und Richtlinien, die von einem Unternehmen erfüllt werden sollen, zu überprüfen. Auditoren sind nur innerhalb des selbstgehosten und dedizierten Lösung möglich.
|
|
\item \textbf{External} Ein externer Nutzer besitzt eingeschränkten Zugriff auf private Ressourcen einer GitLab-Instanz. Diese müssen davor explizit als externe Nutzer hinzugefügt werden. Meistens werden externe Nutzer verwendet um Nutzern außerhalb eines Unternehmens spezifischen Zugriff auf ein Projekt oder eine Gruppe zu geben. Externe Nutzer sind nur innerhalb des selbstgehosten und dedizierten Lösung möglich.
|
|
\item \textbf{Internal} Ein Interner Nutzer besitzt meist eingeschränkten Zugriff und wird durch GitLab automatisch erstellt. Interne Nutzer können als Bots betrachtet werden, die automatisierte Prozesse durchführen, die durch normale Nutzer nicht ausgeführt werden können. Interne Nutzer sind für alle Lösungen von GitLab erhältlich.
|
|
\item \textbf{Service} Service Accounts repräsentieren nicht menschliche Nutzer. Service Nutzer kommen bei der automatischen Ausführung von Prozessen und Pipelines zum Einsatz. Service Nutzer sind für alle Lösungen von GitLab erhältlich.
|
|
\end{itemize}
|
|
\subsection{GitLab vs. GitHub}
|
|
|
|
Bei der Wahl von Code-Hosting ist oft GitHub die erste Wahl. GitHub wurde 2008 von Chris Wanstrath, Tom Preston-Werner und Phillip Jeffrey Hyett gegründet. GitHub wurde 2018 für ungefähr 7,5 Milliarden USD an den Software-Giganten Microsoft verkauft \cite{jrHowThis33yearold2018}. Der Code von GitHub selber ist nicht öffentlich zugänglich. Für Github besteht keine Option die Plattform selbst zu hosten. Nutzer sind daran gebunden, unter der Haube, auf Services zuzugreifen, die in Microsoft Azure laufen. \url{github.com} besitzt im Vergleich zu \url{gitlab.com} eine höhere Anzahl an Nutzern für Q4 2025. GitHub hat verdächtige Nutzer und Bots in ihrer Angabe herausgefiltert und kommt auf eine Gesamtanzahl an ca. 179 Millionen Nutzer \cite{GitHubInnovationGraph}. GitLab gibt an, dass von mindestens 50 Millionen Nutzern ausgegangen werden kann \cite{Q4FY2026GitLab}.
|
|
Aufgrund der grösseren Nutzerbasis eignet sich GitHub mehr für eine kollaborative Zusammenarbeit an \ac{OSS}. Ein Projekt erreicht mehr Nutzer, die potenziell beitragen können.
|
|
GitLab und GitHub teilen sich neben demselben Namenspräfix, ähnliche Mechanismen \cite{gitlab_gitlab_nodate}.\\\\
|
|
\ac{CI}/\ac{CD} ist für jeweils beide Plattformen erhältlich. Unter GitHub bieten \textit{GitHub Actions} die Möglichkeit Build-, Test- und Deploymentprozesse zu automatisieren. In GitHub sind diese Abläufe in Form von \textit{Workflows} organisiert. Ein \textit{Workflow} wird durch ein Ereignis ausgelöst. Ein \textit{Workflow} ist in \textit{Jobs} aufgegliedert. \textit{Jobs} beinhalten Anweisungen bspw. in Form von Kommandozeilenskripts, die sequentiell ausgeführt werden. Eine \textit{Action} beschreibt eine Menge an wiederverwendbaren \textit{Jobs}. \textit{Workflows} werden auf einem Server bzw. einem \textit{Runner} ausgeführt. Für GitHub ist auch das eigene Hosten eines \textit{Runners} möglich. Die Verwendung von eigens gehosteten Runnern, sowie der von GitHub bereitgestellten Runnern ist für öffentliche Repositories kostenlos. Für private Repositories existiert ein Zeitbudget.\\\\
|
|
Beide Plattformen bieten KI-Assistenten an. Für GitHub existiert \textit{GitHub Copilot} und für GitLab \textit{GitLab Duo Agent}. Aktuell kann \textit{GitHub Copilot} mit einem eingeschränkten Zugriff auf Funktionalitäten, kostenlos verwendet werden. Im Gegensatz ist aktuell eine kostenfreie Nutzung von \textit{GitLab Duo Agent} nicht möglich. Copilot beschränkt sich auf alle Artefakte, die in einem Code-Repository liegen. \textit{GitLab Duo Agent} besitzt einen größeren Kontext, zu dem zusätzlich Dokumentation, Planung und Sicherheit gehören. Aufgrund der Aneignung von \textit{Visual Studio Code} durch Microsoft ist \textit{GitHub Copilot} nativ enthalten. Eine Unterstützung für \textit{GitLab Duo Agent} muss über die offizielle \href{https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow}{Erweiterung} ergänzt werden. Interaktionen mit \textit{GitHub Copilot} werden standardmässig von GitHub zum trainieren und verbessern von KI-Modellen verwendet. UM eine Weiterverarbeitung der Daten zu verhindern muss manuell widersprochen werden. Für beide KI-Assistenten kann das unterliegende Modell variiert werden.\\\\
|
|
Das Hosten von Code-Schnipseln ist in GitHub als \href{https://gist.github.com/}{Gist} und in GitLab unter \href{https://gitlab.com/dashboard/snippets}{Snippets} möglich. Organisationen können in GitHub ebenfalls abgebildet werden.
|
|
|
|
\section{CI/CD}
|
|
|
|
%https://docs.gitlab.com/topics/build_your_application/
|
|
|
|
\subsection{GitLab Runner}
|
|
\subsection{Pipelines}
|
|
\subsection{Jobs}
|
|
\subsection{CICD-Komponenten}
|
|
\subsection{Anwendungsbeispiel}
|
|
|
|
\section{Selbstgehostete Lösung}
|
|
|
|
\subsection{Installation}
|
|
|
|
\subsection{Konfiguration}
|
|
|
|
\subsection{Betrieb}
|
|
\section{Evaluierung}
|
|
|
|
\subsection{Vorgehensweise}
|
|
|
|
%Kriterien ausdenken
|
|
|
|
\subsection{Funktionalität}
|
|
|
|
\subsection{Performanz}
|
|
|
|
\subsection{Nachhaltigkeit}
|
|
|
|
\subsection{Sicherheit}
|
|
|
|
\subsection{Kompatibilität}
|
|
|
|
GitLab als Code-Hosting Plattform ist ausschließlich für Linux-Distributionen erhältlich. Es wird differenziert in die kostenpflichtige Variante \ac{EE} und die kostenlose \ac{CE} erhältlich.
|
|
GitLab plant Pakete hauptsächlich für Betriebssysteme, mit \ac{LTS} Versionen zu veröffentlichen. Releases werden nicht mehr publiziert, wenn der Anbieter des Betriebssystems \ac{EOL} des Systems bekannt gibt. GitLab nimmt sich die Freiheit unter anderen Gründen den Support für ein Betriebssystem einzustellen \cite{gitlab_gitlab_nodate}:
|
|
\begin{itemize}
|
|
\item \textbf{keine Wirtschaftlichkeit}, da zu hohe Wartungskosten oder zu wenig Kunden auf die Technologien setzen
|
|
\item \textbf{technische Einschränkungen} wie bspw. zusätzliche Abhängigkeiten, Sicherheitsanforderungen oder technologische Veränderungen die eine Erstellung von Paketen erschwert oder unmöglich gestaltet.
|
|
\end{itemize}
|
|
Die folgende Tabelle \ref{tab:supported_os} zeigt eine Auflistung aller aktuell (zum 15.05.2026) von GitLab unterstützten Betriebssysteme und ihrer Architekturen (Siehe \url{https://docs.gitlab.com/install/package/#supported-platforms}). Neben den offiziellen GitLab-Paketen existieren ebenso inoffizielle Pakete der GitLab-Community.
|
|
\begin{table}[H]
|
|
\centering
|
|
\resizebox{\columnwidth}{!}{%
|
|
\begin{tabular}{@{}llll@{}}
|
|
\toprule
|
|
Betriebsystem & OS-Version & CE & EE \\ \midrule
|
|
AlmaLinux & 8-10 & X & X \\
|
|
Amazon Linux & 2, 2023 & X & X \\
|
|
Debian & 11-13 & X & X \\
|
|
openSUSE Leap & 15.6 & X & X \\
|
|
\makecell[cl]{SUSE Linux Enterprise Server} & 12 & & X \\
|
|
Oracle Linux & 8-9 & X & X \\
|
|
\makecell[cl]{Red Hat Enterprise Linux } & 8-10 & X & X\\
|
|
Ubuntu & \makecell[cl]{22.04, 24.04} & X & X\\ \bottomrule
|
|
\end{tabular}%
|
|
}
|
|
\caption{unterstützte Betriebssysteme für GitLab}
|
|
\label{tab:supported_os}
|
|
\end{table}
|
|
Folgende Installationsmöglichkeiten existieren für \ac{CE} und \ac{EE} sowie für GitLab Runner:
|
|
\begin{itemize}
|
|
\item Installation als Linux-Paket für das jeweilige unterstützte Betriebssystem
|
|
\item Betrieb mithilfe des offiziellen Docker-Images von GitLab (Siehe Dockerhub: \url{https://hub.docker.com/u/gitlab})
|
|
\item In Kubernetes als Helm-Chart, einem speziellen Paketformat für Kubernetes
|
|
\item Installation per GitLab Operator unter Kubernetes. Ein Kubernetes Operator erlaubt Erweiterung bzgl. des Verhaltens von Clustern, ohne dabei den ursprünglichen Quellcode von Kubernetes zu modifizieren.
|
|
\end{itemize}
|
|
GitLab Runner kann für eine grössere Auswahl an Betriebssystemen installiert werden. Tabelle \ref{tab:runner_os} zeigt eine Auflistung unterstützter Versionen von Betriebssystemen für GitLab Runner. Wird - verwendet, so ist keine Version von GitLab für das jeweilige Betriebssystem spezifiziert.
|
|
\begin{table}[H]
|
|
\centering
|
|
\resizebox{\columnwidth}{!}{%
|
|
\begin{tabular}{@{}ll@{}}
|
|
\toprule
|
|
Betriebsystem & OS-Version \\ \midrule
|
|
Debian & 11-15 \\
|
|
Mint & 21-22.1 \\
|
|
Raspbian & 11-15 \\
|
|
Ubuntu & 25.10, 24.04, 22.04, 20.4, 18.04 \\
|
|
Amazon Linux & 2, 2023, 2025 \\
|
|
\makecell[cl]{Red Hat\\Enterprise Linux} & 7-10 \\
|
|
Fedora & 42, 43 \\
|
|
Oracle Linux & 10, 9, 8, 7 \\
|
|
openSUSE & 16.0, 15.6 \\
|
|
\makecell[cl]{SUSE Linux\\Enterprise Server} & 15.7, 15.6, 15.5, 15.4, 12.5 \\
|
|
FreeBSD & - \\
|
|
Windows & - \\
|
|
macOS & - \\ \bottomrule
|
|
\end{tabular}%
|
|
}
|
|
\caption{Unterstützte Betriebssysteme für GitLab Runner}
|
|
\label{tab:runner_os}
|
|
\end{table}
|
|
Zur Kompatibilität zählt ebenso die Möglichkeit von anderen Code-Hosting Plattformen zu GitLab zu migrieren. GitLab bietet nur die Möglichkeit an automatische Migrationen von Git-Repositories durchzuführen. Auf \ac{SVN} basierende Repositories müssen externe Werkzeuge (wie bspw. \href{https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git}{git svn} oder \href{http://www.catb.org/~esr/reposurgeon/repository-editing.html}{Reposurgeon})verwendet werden um diese in Git-Repositories umzuwandeln. Für eine Auswahl an Plattformen bietet GitLab ein Migrationswerkzeug. Bei der Migration werden, bspw. für Autoren von Commits, Platzhalter für Nutzer eingeführt. Es besteht die Möglichkeit Platzhalter-Nutzer wieder realen Nutzern der GitLab-Instanz zuzuordnen. Dieser Vorgang wird als \textit{Post-migration Mapping} bezeichnet. Wird das Projekt in den Namensraum eines Nutzers exportiert, ist eine solche Zuordnung nicht möglich. Stattdessen wird dem Besitzer des Namensraum jeder Beitrag zugeordnet. \cite{gitlab_gitlab_nodate}. Tabelle \ref{tab:migration_platforms} zeigt eine Auflistung an Plattformen bzw. Repositories, für die Gruppen oder Projekte, unter der Verwendung des Migrationswerkzeug und \textit{Post-migration Mapping} importiert werden können.
|
|
\begin{table}[H]
|
|
\centering
|
|
\resizebox{\columnwidth}{!}{%
|
|
\begin{tabular}{@{}lllll@{}}
|
|
\toprule
|
|
Ursprung & Gruppen & Projekte & Werkzeug & Post-Mapping \\ \midrule
|
|
GitLab (direkter Transfer) & X & X & X & X \\
|
|
GitLab (Datei-Export) & X & X & X & - \\
|
|
Bitbucket Server & - & X & X & X \\
|
|
GitHub & - & X & X & X \\
|
|
Gitea & - & X & X & X \\
|
|
Bitbucket Cloud & - & X & X & - \\
|
|
FogBugz & - & X & X & - \\
|
|
Git Repo (Manifest) & - & X & X & - \\
|
|
Git Repo (URL) & - & X & X & - \\
|
|
IBM Devops ClearCase & - & X & - & - \\
|
|
\acs{CVS} & - & X & - & - \\
|
|
Perforce P4 & - & X & - & - \\
|
|
Subversion & - & X & - & - \\
|
|
\acs{TFVC} & - & X & - & - \\
|
|
Jira (Issues) & - & - & X & - \\ \bottomrule
|
|
\end{tabular}}
|
|
\caption{Migrations-Unterstützung von GitLab}
|
|
\label{tab:migration_platforms}
|
|
\end{table}
|
|
\subsection{Skalierbarkeit}
|
|
|
|
\subsection{Dokumentation}
|
|
|
|
Alle GitLab-Lösungen sind umfassend auf der offiziellen Seite \url{https://docs.gitlab.com/} dokumentiert. Jeder Release von GitLab besitzt bezüglich Haupt- und Nebenversionsnummer eine eigene Version der Dokumentation. Online kann auf eine eingeschränkte Auswahl zugegriffen werden. Nach den Ausgaben der Dokumentation kann unter \url{https://archives.docs.gitlab.com/} gesucht werden. Diese Suche reicht zurück bis zur Version 16.0. Nach Bedarf können ältere Versionen im Offline-Archiv \url{https://docs.gitlab.com/archives/#offline-archives} als Docker-Container heruntergeladen und gestartet werden. Das Offline Archiv reicht bis zu der Version 10.3 zurück. Die Dokumentation wird aus den Quellcode-Repositories der GitLab Projekte gebaut und in regelmässigen Abständen aktualisiert \cite{gitlab_gitlab_nodate}.
|
|
|
|
\section{Diskussion}
|
|
|
|
\section{Ausblick}
|
|
|
|
\section{Zusammenfassung}
|
|
|
|
\section*{Abkürzungsverzeichnis}
|
|
\begin{acronym}[Abkürzungsverzeichnis]
|
|
\acro{IDE}{Integrated Development Environment}
|
|
\acro{CD}{Continous Delivery, kontinuierliche Auslieferung}
|
|
\acro{SaaS}{Software as a Service}
|
|
\acro{CI}{Continuous Integration, kontinuierliche Integration}
|
|
\acro{NASDAQ}{National Association of Securities Dealers Automated Quotations}
|
|
\acro{GLFM}{Gitlab Flavored Markdown}
|
|
\acro{EOL}{End of Life}
|
|
\acro{LTS}{Long Term Support}
|
|
\acro{CE}{Community Edition}
|
|
\acro{EE}{Enterprise Edition}
|
|
\acro{OS}{Operating System}
|
|
\acro{SVN}{Subversion}
|
|
\acro{TFVC}{Team Foundation Version Control (TFVC)}
|
|
\acro{CVS}{Concurrent Versions System}
|
|
\acro{OSS}{Open Source Software}
|
|
\end{acronym}
|
|
|
|
\printbibliography
|
|
\end{multicols}
|
|
|
|
\end{document}
|