Merge branch 'main' into roman-hotfix

DMS_paper15_gitlab.tex

@@ -105,12 +105,12 @@
 		\tableofcontents
 		
 		\section{Einleitung}
-		
+		\authornote{Roman Schöne}
 		\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).
+		\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 (auch \textit{Main-Branch} genannt). 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.
+		\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 Fehler enthalten. 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]
@@ -118,7 +118,7 @@
 			\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.
+		Diese wissenschaftliche Ausarbeitung beschäftigt sich damit, inwiefern sich die von GitLab bereitgestellten Werkzeuge bzw. Möglichkeiten eignen um eine beispielhafte Anwendung zu entwickeln, zu testen und einzusetzen. Ebenso wird betrachtet in welchen Punkten sich der Aufbau 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 GitLab 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:
@@ -198,13 +198,7 @@
 			\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}.
@@ -273,12 +267,12 @@ build-image:
   script:
     - docker build -t app:$CI_COMMIT_SHA .
 
-deploy-staging:
+deploy:prod:
   stage: deploy
   script:
     - ssh user@host 'docker pull app'
-  only:
+  rules:
-    - main
+    - if: '$CI_COMMIT_BRANCH == "main"'
 \end{lstlisting}
 
 		Die starre Stage-Reihenfolge lässt sich mit dem Schlüsselwort \texttt{needs} aufbrechen. Durch \texttt{needs} entsteht ein gerichteter Graph ohne Zyklen, ein sogenannter \ac{DAG}. Ohne Zyklen heißt, dass kein Job direkt oder über Umwege wieder von sich selbst abhängt. Wenn die definierten Vorgänger eines Jobs fertig sind, startet dieser automatisch und wartet nicht auf die gesamte vorherige Stage \cite{cowell_automating_2023}. Dadurch entfallen unnötige Wartezeiten, und unabhängige Jobs können bei mehreren verfügbaren Runnern parallel laufen. Wiederkehrende Pipeline-Bausteine, die an mehreren Stellen gebraucht werden, lassen sich über \texttt{include} aus anderen Repositories nachladen \cite{gitlab_gitlab_nodate}.
@@ -346,7 +340,7 @@ stages:
 				\end{tabular}%
 			}
 		\end{table}
-		Die ersten beiden Stages werden bei jedem Push auf jeden Branch automatisch gestartet. Sie entsprechen den klassischen \ac{CI}-Schritten nach Duvall et al.~\cite{duvall_continuous_2007} und Fowler~\cite{fowler_continuous_2006}. Ihr Zweck ist es, für jeden Codestand ein schnelles, automatisches Feedback zu liefern. Die Stage \texttt{deploy} deckt den Continuous-Delivery-Anteil ab. Hier trennen sich zwei Pfade. Auf einem Feature-Branch steht der Job \texttt{deploy:staging} als manueller Schritt bereit, der in der Pipeline-Übersicht sichtbar ist. So lässt sich eine Änderung bei Bedarf in einer laufenden Vorschau begutachten und testen, bevor sie in den Hauptzweig übernommen wird. Ein Push auf \texttt{main} baut die Anwendung automatisch und liefert sie nach \texttt{production} aus. Nach der Begriffsabgrenzung von Shahin et al.~\cite{shahin_continuous_2017} entspricht der automatische Pfad nach \texttt{main} damit Continuous Deployment, während der manuelle Pfad nach Staging dem klassischen Continuous Delivery entspricht.
+		Die ersten beiden Stages werden bei jedem Push auf jeden Branch automatisch gestartet. Sie entsprechen den klassischen \ac{CI}-Schritten nach Duvall et al.~\cite{duvall_continuous_2007}. Ihr Zweck ist es, für jeden Codestand ein schnelles, automatisches Feedback zu liefern. Die Stage \texttt{deploy} deckt den Continuous-Delivery-Anteil ab. Hier trennen sich zwei Pfade. Auf einem Feature-Branch steht der Job \texttt{deploy:staging} als manueller Schritt bereit, der in der Pipeline-Übersicht sichtbar ist. So lässt sich eine Änderung bei Bedarf in einer laufenden Vorschau begutachten und testen, bevor sie in den Hauptzweig übernommen wird. Ein Push auf \texttt{main} baut die Anwendung automatisch und liefert sie nach \texttt{production} aus. Nach der Begriffsabgrenzung von Shahin et al.~\cite{shahin_continuous_2017} entspricht der automatische Pfad nach \texttt{main} damit Continuous Deployment, während der manuelle Pfad nach Staging dem klassischen Continuous Delivery entspricht.
 
 			Diese Jobs laufen auf zwei verschiedenen Runnern. \texttt{lint} und \texttt{unit-test} nutzen einen gemeinsamen Runner mit Docker-Executor und führen ihre Schritte in einer Container-Umgebung mit \texttt{node:20-alpine} aus. Über \texttt{tags} sind die Deploy-Jobs an einen zweiten Runner mit Shell-Executor gebunden. Sie bauen das Image mit \texttt{docker build} und starten es anschließend mit \texttt{docker run}. Für diese Befehle braucht der Runner direkten Zugriff auf den Docker-Daemon des Hostsystems. Die Prüfung bleibt so in einem isolierten Container, während die Veröffentlichung selbst auf dem Hostsystem läuft.
 
@@ -456,6 +450,8 @@ Der \ac{DAG} über \texttt{needs}, also die Verknüpfung der Jobs nach ihren Abh
 
 		\subsection{Nachhaltigkeit}
 		
+		\authornote{Roman Schöne}
+		
 		Unter Betrachtung der in \ref{sec:scalability} erwähnten Referenzarchitektur wird betrachtet inwiefern die von GitLab vorgeschlagenen Architekturen sich bezüglich ihres Stromverbrauchs bemessen. GitLab liefert Empfehlungen für virtuelle Server für die Anbieter \ac{GCP}, \ac{AWS} und Azure. Ausgenommen von GPUs sind CPU und Arbeitsspeicher die Komponenten mit dem höchsten Stromverbrauch \cite{davyEstimatingAWSEC22022}. im folgenden wird eine Schätzung abgeben, die auf Daten von \ac{AWS} Instanzen basieren und sich auf die Leistung von CPU und Arbeitsspeicher beschränkt. Im konkreten werden Instanzen der Typen \texttt{c5, c5n} und \texttt{m5} in der GitLab Empfehlung erwähnt. \\ 
 		Für unterschiedliche \ac{AWS}-Instanzen liefert \cite{davyEstimatingAWSEC22022} einen Datensatz der Auskunft über die Leistung in Watt nach Anzahl der vCPUS ,unter einer bestimmten Auslastung, gibt. Eine \ac{vCPU} bezeichnet eine virtualisierte Variante einer physischen CPU \cite{VCPUWasIst2023}. Es ist zu beachten, dass die Testdaten aus \ref{tab:power_consumption} untertakteten Instanzen stammen und bieten eine untere Schätzung. Ebenso wird angenommen, dass der Arbeitsspeicher immer in Relation zur Anzahl von \ac{vCPU}s liegt und ist in \ref{tab:power_consumption} miteinbezogen.
 		\begin{table}[H]
@@ -481,6 +477,8 @@ Der \ac{DAG} über \texttt{needs}, also die Verknüpfung der Jobs nach ihren Abh
 		
 		\subsection{Sicherheit}
 		
+		\authornote{Roman Schöne}
+		
 		Eine eigene GitLab-Instanz kann so konfiguriert werden, dass diese dem US-amerikanischen Sicherheitsstandard \acs{NIST} \acs{SP} 800-53 für Sicherheitskontrolle in Informationssystemen des \acl{NIST} entsprechen \cite{gitlab_gitlab_nodate}. Die Angebote von GitLab, damit die \ac{SaaS}-Version bzw. GitLab.com und GitLab Dedicated sind nach \acs{ISO}/\acs{IEC} 27001:2022 zertifiziert \cite{GitLab16522166}. Diese Norm spezifiziert Anforderungen an Informationssicherheitsmanagement im Kontext von Organisationen. Für dieselben Angebote besitzt GitLab eine Zertifizierung nach Norm \acs{ISO}/\acs{IEC} 27017:2015, welche Richtlinien zur Kontrolle der Informationssicherheit von Cloud-Services festlegt \cite{gitlab_gitlab_nodate}. Es ist zu erwarten, dass diese Norm bald erneuert wird \cite{ISOIEC27017}.
 		Im folgenden Abschnitt wird darauf eingegangen mit welchen Möglichkeiten wie GitLab vor Angriffen von ausserhalb geschützt werden kann. Die GitLab-Dokumentation unterteilt Schutzmassnahmen in die Kategorien \cite{gitlab_gitlab_nodate}:
 		\begin{itemize}
@@ -496,6 +494,8 @@ Der \ac{DAG} über \texttt{needs}, also die Verknüpfung der Jobs nach ihren Abh
 		
 		\subsection{Kompatibilität}
 		
+		\authornote{Roman Schöne}
+		
 		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}
@@ -582,6 +582,8 @@ Der \ac{DAG} über \texttt{needs}, also die Verknüpfung der Jobs nach ihren Abh
 		\end{table}
 		\subsection{Skalierbarkeit}
 		
+		\authornote{Roman Schöne}
+		
 		\label{sec:scalability}
 		
 		GitLab bietet Empfehlungen für Referenz-Architekturen, welche versuchen einen Kompromiss zwischen den Kriterien Performanz, Resilienz und finanzieller Kosten herzustellen. Um eine passende Architektur zu wählen orientiert sich GitLab an der Metrik: \ac{RPS}. Die RPS lassen sich nach Anfrage in folgende Typen aufgliedern \cite{gitlab_gitlab_nodate}:
@@ -600,14 +602,20 @@ Der \ac{DAG} über \texttt{needs}, also die Verknüpfung der Jobs nach ihren Abh
 		
 		\subsection{Dokumentation}
 		
+		\authornote{Roman Schöne}
+		
 		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}
 		
+		\authornote{Roman Schöne}
+		
 		Einige Aspekte über GitLab wurden aufgrund der Breite der Thematik nur leicht angeschnitten. Der Vergleich von GitLab mit anderen Code-Hosting Plattformen wie GitHub könnte um zusätzliche Plattformen, wie in  \ref{tab:migration_platforms} erweitert werden. Das Anwendungsbeispiel oder auch das Einrichten einer eigenen Instanz hätte für weitere Plattformen übertragen werden können um einen direkten Vergleich zu schaffen. Ebenso wurde aufgrund von Demonstrationszwecken und einer höheren Nachvollziehbarkeit eine minimalistische Webanwendung als Anwendungsbeispiel verwendet. In der Realität sind die Anwendungsfälle von komplexerer Natur. Ein Grossteil der Evaluationen basieren auf der Dokumentation von GitLab. Die Dokumentation unterliegt selbst einer kontinuierlichen Änderung mit den neuen Releases von GitLab und bietet selbst nur das Abbild eines Zeitausschnitts. Für die erstellten Schätzung im Kapitel Nachhaltigkeit ist zu beachten, dass viele Annahmen getroffen werden müssen. Da die Messdaten aus untertakteten Instanzen stammen kann es zu Abweichungen mit realen Daten führen. Dieser Vergleich beschränkt sich nur auf \ac{AWS} und könnte erweitert werden. Die von GitLab empfohlenen Maschinentypen sind eher als Richtlinie zu sehen. In den meisten Anwendungsfällen muss selbst abgewägt werden, wie das eigene System aufgebaut sein muss. Ebenso hätten selbst praktische Tests durchgeführt werden können um echte Daten für die Kapitel Nachhaltigkeit sowie Skalierbarkeit zu erhalten. Diese Ergebnisse hätten mit weiteren Plattformen verglichen werden können.  Für den Aspekt der Sicherheit hätte beispielsweise ein Schwachstellen-Scan der von GitLab bereitgestellten Docker-Container unter dem Dockerhub \url{https://hub.docker.com/r/gitlab/gitlab-ce} durchgeführt werden können. Aufgrund zusätzlichem zeitlichen und finanziellen Aufwand wurde sich gegen diese Punkte entschieden. Die hier erwähnten Probleme bieten jedoch einen Ausgangspunkt für auf diesem Dokument aufbauenden Arbeiten.
 		
 		\section{Ausblick}
 		
+		\authornote{Roman Schöne}
+		
 		Aufgrund der Open Source Philosophie von GitLab wird versucht die Differenz bezahlter und frei nutzbare Funktionalitäten gering zu halten \cite{degeler_gitlab_2014}. \textit{GitLab Inc.} ist demnach weniger stark gewinnorientiert wie andere Softwareunternehmen. GitLab als Code-Hosting Plattform und Open Source Projekt wird mit grosser Wahrscheinlichkeit für die Zukunft erhalten bleiben und an zusätzlichen Funktionalitäten gewinnen.
 		
 		\section{Zusammenfassung}