229 lines
15 KiB
TeX
229 lines
15 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}:
|
|
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 eingschrä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}
|
|
|
|
|
|
\section{Selbstgehostete Lösung}
|
|
|
|
\subsection{Installation}
|
|
|
|
\subsection{Konfiguration}
|
|
|
|
\subsection{Betrieb}
|
|
|
|
\section{CI/CD}
|
|
|
|
%https://docs.gitlab.com/topics/build_your_application/
|
|
|
|
\subsection{GitLab Runner}
|
|
\subsection{Pipelines}
|
|
\subsection{Jobs}
|
|
\subsection{CICD-Komponenten}
|
|
\subsection{GitLab vs. GitHub}
|
|
\subsection{Anwendungsbeispiel}
|
|
|
|
\section{Evaluierung}
|
|
|
|
\subsection{Vorgehensweise}
|
|
|
|
%Kriterien ausdenken
|
|
|
|
\subsection{Funktionalität}
|
|
|
|
\subsection{Performanz}
|
|
|
|
\subsection{Nachhaltigkeit}
|
|
|
|
\subsection{Sicherheit}
|
|
|
|
\subsection{Kompatibilität}
|
|
|
|
\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}
|
|
\end{acronym}
|
|
|
|
\printbibliography
|
|
\end{multicols}
|
|
|
|
\end{document}
|