removed funcionality, wrote discussion and future

DMS_paper15_gitlab.tex

@@ -81,7 +81,7 @@
 	\fancyhead[L]{GitLab}
 	\fancyhead[R]{DMS - DevOps mit Micro Services}
 	\fancyfoot{} % clear all footer fields
-	\fancyfoot[LE,RO]{\thepage}
+	\fancyfoot[C]{\thepage}
 	
 	\maketitle
 	
@@ -399,13 +399,11 @@ stages:
 
 		Bewertet wird GitLab als selbstbetriebene Plattform. Wo der Aufbau dieser Arbeit es zulässt, stützt sich die Bewertung auf die in Abschnitt~\ref{sec:selfhosted} beschriebene selbstgehostete \ac{CE}-Instanz und die \ac{CI}/\ac{CD}-Pipeline aus dem Anwendungsbeispiel. Kompatibilität, Skalierbarkeit und Dokumentation lassen sich an einer einzelnen Instanz nicht erproben und werden auf Ebene der Plattform beurteilt.
 
-		Die Bewertung folgt einem Katalog aus sieben Kriterien: Funktionalität, Performanz, Nachhaltigkeit, Sicherheit, Kompatibilität, Skalierbarkeit und Dokumentation. Funktionalität, Performanz, Sicherheit und Kompatibilität orientieren sich an etablierten Softwarequalitätsmerkmalen. Nachhaltigkeit, Skalierbarkeit und Dokumentation kommen hinzu, weil sie im Eigenbetrieb stärker ins Gewicht fallen als bei einer fertig betriebenen \ac{SaaS}-Lösung.
+		Die Bewertung folgt einem Katalog aus den Kriterien: Performanz, Nachhaltigkeit, Sicherheit, Kompatibilität, Skalierbarkeit und Dokumentation. Performanz, Sicherheit und Kompatibilität orientieren sich an etablierten Softwarequalitätsmerkmalen. Nachhaltigkeit, Skalierbarkeit und Dokumentation kommen hinzu, weil sie im Eigenbetrieb stärker ins Gewicht fallen als bei einer fertig betriebenen \ac{SaaS}-Lösung.
 
 		Innerhalb jedes Kriteriums wird qualitativ argumentiert. Herangezogen werden die offizielle Dokumentation, die zitierte Literatur und die eigenen Beobachtungen aus Installation und Betrieb. Die Performanz bildet die Ausnahme. Hier werden die Laufzeiten der Demo-Pipeline gemessen und gegenübergestellt.
 
 		Zwei Grenzen sind vorab zu nennen. Die Instanz läuft auf einem einzelnen Server, Aussagen zur Skalierbarkeit stützen sich daher auf die Architektur und die Herstellerangaben und nicht auf einen eigenen Lasttest. Die gemessenen Laufzeiten stammen aus einer bewusst kleinen Anwendung und zeigen Grössenordnungen, keine repräsentativen Benchmarks.
-
-		\subsection{Funktionalität}
 		
 		\subsection{Performanz}
 		\authornote{Christopher Schmitt}
@@ -460,7 +458,7 @@ Der \ac{DAG} über das Schlüsselwort \texttt{needs} ist hier kaum ein Hebel. Di
 					m5            & 2.1    & 2.4     & 2.8     & 3.1     & 3.4     & 3.7     & 4.1     & 4.4     & 4.7     & 5       & 5.4  \\ \bottomrule   
 				\end{tabular}%
 			}
-			\caption{Leistung in Watt für eine vCPU abgestuft nach Auslastung \cite{davyEstimatingAWSEC22022}}
+			\caption{Leistung in Watt nach vCPUs abgestuft nach Auslastung \cite{davyEstimatingAWSEC22022}}
 			\label{tab:power_consumption}
 		\end{table}
 		Da in \ref{tab:power_consumption} keine Daten zu \texttt{c5n} enthalten sind, werden die Werte mit denen von \texttt{c5} geschätzt. Abbildung \ref{fig:estimation_power} zeigt die Schätzung der Leistung für die empfohlenen Referenzarchitekturen nach Benutzern für eine Abstufung nach Auslastung. 
@@ -590,17 +588,24 @@ Der \ac{DAG} über das Schlüsselwort \texttt{needs} ist hier kaum ein Hebel. Di
 		\end{figure} Im Grunde gibt es zwei Möglichkeiten zu skalieren. Dazu zählt die Verwendung einer höher liegenden Referenzarchitektur oder die horizontale oder Vertikale Skalierung einzelner Komponenten. Bei der horizontalen Skalierung müssen Lastverteiler hinzugefügt und konfiguriert werden.
 		GitLab bietet für einige Intervalle an zu erwartenden Nutzern (bzw. \ac{RPS}) Empfehlungen für \href{https://docs.gitlab.com/administration/reference_architectures/}{Architekturen}. Alle Architekturen sind auf eine Skalierung ausgelegt. Weitere Funktionalitäten ergeben erst ab einer gewissen Anzahl an Benutzern Sinn. Der Betrieb von GitLab im High Availability Modus stellt sicher, dass einzelne Komponenten bei Ausfällen kompensiert werden können. Durch Redundanz ergeben sich höhere finanzielle Kosten. GitLab gibt an, dass die Schwelle für den Betrieb im High Availability Modus bei ungefähr 3000 Nutzern liegt \cite{gitlab_gitlab_nodate}. Um die Ausfallsicherheit weiter zu erhöhen kann GitLab in mindestens zwei Umgebungen innerhalb unterschiedlicher Regionen betrieben werden. Dies führt zu höheren Kosten und einem komplexeren Systemaufbau. Einzelne Komponenten von GitLab können in die Cloud ausgelagert werden. Grössere Repositories, sogenannte \textit{Monorepos} mit einer Grösse von mehreren Gigabytes, können zu hohen Auslastungen führen. Die hohe Last ist softwareseitig begründet, weshalb die Skalierung durch zusätzliche Hardware kaum Nutzen erweist. Die Auslastung kann durch Optimierungsmassnahmen am Repository verringert werden \cite{gitlab_gitlab_nodate}. Eine Gefahr beim Skalieren einer einzelnen Komponente kann zu ungewollten Konsequenzen führen. Die empfohlenen Architekturen sind so ausgelegt, dass die Skalierung der einzelnen Komponenten in einem passenden Verhältnis zueinander stehen. Besitzt eine skalierte Komponente einen höheren Durchlauf kommt die Last, bei abhängigen Komponenten an. Diese müssen zwangsweise ebenso skaliert werden \cite{gitlab_gitlab_nodate}.
 		
-		
 		\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}
 		
+		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 \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}
 		
+		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}
 		\authornote{Christopher Schmitt}
+		
+		\section*{Anhang}
+		
+		Ein Teil der Daten und Grafiken welche innerhalb dieses Artikels verwendet wurden können unter dem Gitea Repository \url{https://gitty.informatik.hs-mannheim.de/2211275/dms} eingesehen werden.
 
 		\section*{Abkürzungsverzeichnis}
 		\begin{acronym}[Abkürzungsverzeichnis]

literatur/dms.bib

@@ -209,6 +209,17 @@
   file = {C:\Users\Roman\Zotero\storage\PIAEFUHX\gitlab-dot-com-database-incident.html}
 }
 
+@misc{GitLabIncSan,
+  title = {{GitLab Inc., San Francisco, USA: Netzwerk, Wirtschaftsinfos}},
+  shorttitle = {{GitLab Inc., San Francisco, USA}},
+  journal = {www.northdata.de},
+  urldate = {2026-06-11},
+  abstract = {GitLab Inc., San Francisco, USA: Netzwerk, Wirtschaftsinfos},
+  howpublished = {https://www.northdata.de/GitLab\%20Inc\%C2\%B7,\%20San\%20Francisco,\%20US/\_c6616511147},
+  langid = {ngerman},
+  file = {C:\Users\Roman\Zotero\storage\6AHHUKYD\_c6616511147.html}
+}
+
 @inproceedings{golzadeh_rise_2022,
   title = {On the Rise and Fall of {{CI}} Services in {{GitHub}}},
   booktitle = {Proceedings of the 2022 {{IEEE}} International Conference on Software Analysis, Evolution and Reengineering ({{SANER}} 2022)},