add author notes to own chapters

DMS_paper15_gitlab.tex

@@ -52,6 +52,7 @@
 	showstringspaces=false,
 }
 
+\newcommand{\authornote}[1]{\textit{\small Verfasst von: #1}\par\medskip}
 
 \graphicspath{ {./bilder/} }
 
@@ -85,6 +86,7 @@
 	\maketitle
 	
 	\begin{abstract}
+		\authornote{Christopher Schmitt}
 		\blindtext
 	\end{abstract}
 	
@@ -205,6 +207,7 @@
 		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}
+		\authornote{Christopher Schmitt}
 
 		\ac{CI}, \ac{CD} und Continuous Deployment bauen aufeinander auf, werden in der Literatur aber oft vermischt. \ac{CI} bezeichnet das automatische Übersetzen und Testen jeder Codeänderung gegen den gemeinsamen Hauptzweig. \ac{CD} steht in dieser Arbeit für Continuous Delivery. Jeder geprüfte Stand lässt sich damit jederzeit in eine produktionsnahe Umgebung ausliefern, der eigentliche Sprung in die Produktion bleibt aber eine bewusste, manuelle Freigabe. Continuous Deployment geht einen Schritt weiter und automatisiert auch diese Freigabe. Die Abkürzung CD wird dabei für beide letztgenannten Stufen verwendet, was regelmässig zu Verwechslungen führt \cite{shahin_continuous_2017}. Alle drei Stufen bildet GitLab mit denselben Bausteinen ab: Runner, Pipelines und Jobs. Gesteuert werden sie über eine einzige Konfigurationsdatei im Repository \cite{cowell_automating_2023}.
 
@@ -342,6 +345,7 @@ stages:
 		Im Rahmen der Live-Präsentation wird der Lebenszyklus einer Codeänderung in drei Schritten gezeigt. Zunächst wird auf einem Feature-Branch eine sichtbare Änderung am Anwendungscode vorgenommen und in das Repository übertragen. Die Stages \texttt{lint} und \texttt{unit-test} laufen automatisch durch. Danach wird der Job \texttt{deploy:staging} über die Weboberfläche freigegeben. Die Änderung ist unmittelbar unter der Staging-Adresse sichtbar, ohne dass sie bereits im Hauptzweig liegt. Den Abschluss bildet der Merge Request gegen \texttt{main}. Wird er akzeptiert, durchläuft eine neue Pipeline auf \texttt{main} erneut \texttt{lint} und \texttt{unit-test} und löst anschliessend automatisch \texttt{deploy:prod} aus. Die neue Version läuft damit ohne weiteren Eingriff in der Produktion.
 		
 		\section{Selbstgehostete Lösung}\label{sec:selfhosted}
+		\authornote{Christopher Schmitt}
 
 		Neben dem Bezug als \ac{SaaS} lässt sich GitLab auch auf eigener Hardware selbst betreiben. Diese Variante wird von GitLab als \emph{Self-Managed} bezeichnet \cite{gitlab_gitlab_nodate}. Sie kommt hauptsächlich in zwei Fällen zum Einsatz. Entweder erlauben Datenschutz- oder Compliance-Vorgaben nicht, dass Quellcode auf fremden Servern liegt. Oder die \ac{SaaS}-Variante wird mit steigender Nutzerzahl zu teuer. Installation, Konfiguration, Aktualisierungen und Sicherungen müssen dafür allerdings selbst übernommen werden \cite{painter_practical_2024}. Im Folgenden wird beschrieben, wie eine solche Instanz im Rahmen dieser Arbeit auf einem privaten Linux-Server aufgesetzt wurde und welcher Aufwand dabei anfiel.
 
@@ -391,8 +395,9 @@ stages:
 		\section{Evaluierung}
 		
 		\subsection{Vorgehensweise}
+		\authornote{Christopher Schmitt}
 
-		Bewertet wird nicht GitLab im Allgemeinen, sondern der konkrete Aufbau dieser Arbeit. Grundlage sind die in Abschnitt~\ref{sec:selfhosted} beschriebene selbstgehostete \ac{CE}-Instanz und die zugehörige \ac{CI}/\ac{CD}-Pipeline aus dem Anwendungsbeispiel.
+		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.
 
@@ -403,6 +408,7 @@ stages:
 		\subsection{Funktionalität}
 		
 		\subsection{Performanz}
+		\authornote{Christopher Schmitt}
 
 Die reine Nutzlast der \ac{CI}-Jobs im Anwendungsbeispiel ist winzig. Auf einem Entwicklungsrechner mit 32 Kernen, warmem npm-Cache und zuvor leerem \texttt{node\_modules} braucht \texttt{npm ci} für die 221 Pakete des Projekts rund eine Sekunde, \texttt{npm run lint} etwa 0,3 Sekunden und \texttt{npm test} etwa 0,8 Sekunden. Tabelle~\ref{tab:perf-local} listet diese lokalen Referenzwerte. Sie sind keine Runner-Zeiten und sollen nur die Grössenordnung der eigentlichen Arbeit zeigen.
 
@@ -438,7 +444,7 @@ Die ursprüngliche Konfiguration cacht das falsche Verzeichnis. Sie legt \texttt
 
 Zwei Korrekturen wurden gemessen. Ohne Cache entfällt das Sichern und Wiederherstellen, und der \texttt{lint}-Job sinkt von 10,5 auf 7,6 Sekunden, der \texttt{unit-test}-Job von 11,2 auf 7,8. Allein das Entfernen des unwirksamen Caches spart also rund drei Sekunden je Job. Die zweite Korrektur cacht statt \texttt{node\_modules} den npm-Paketspeicher unter \texttt{.npm} und ruft \texttt{npm ci} mit den Optionen \texttt{-{}-cache .npm} und \texttt{-{}-prefer-offline} auf. Bei einem Treffer installiert \texttt{npm ci} dann aus dem lokalen Speicher, die Installationszeit sinkt von rund zwei Sekunden auf knapp eine (981\,ms im Messlauf). Am Job ändert das hier kaum etwas, weil der eingesparte Download durch den Aufwand für den \texttt{.npm}-Cache wieder aufgewogen wird. Der Paket-Cache lohnt sich erst, wenn der Download die Installation bestimmt. Auf dieser Instanz mit schnellem Zugriff auf die Registry ist das nicht der Fall. Caches beschleunigen wiederholte Läufe also nicht von selbst. Sie sind zudem, anders als Artefakte, über Jobgrenzen hinweg nicht garantiert verfügbar \cite{cowell_automating_2023}.
 
-Der \ac{DAG} über das Schlüsselwort \texttt{needs} ist hier kaum ein Hebel. Die Demo-Pipeline läuft nahezu linear, erst \texttt{lint}, dann \texttt{test}, dann \texttt{deploy}, und bietet kaum Parallelität, die sich lohnt. Bei grösseren Pipelines sieht das anders aus. Dort ist die Parallelisierung serieller Stages der zentrale Hebel, und Zampetti et al.~\cite{zampetti_empirical_2020} führen serielle Stages, die parallel laufen könnten, als typischen Konfigurationsfehler. Den teuersten Einzelschritt bildet die Stage \texttt{deploy}. Der manuell ausgelöste \texttt{deploy:staging}-Job lief in 2,3 Sekunden durch, baut dabei aber das Docker-Image neu und installiert die Abhängigkeiten ein weiteres Mal im Image.
+Der \ac{DAG} über das Schlüsselwort \texttt{needs} ist hier kaum ein Hebel. Die Demo-Pipeline läuft nahezu linear, erst \texttt{lint}, dann \texttt{test}, dann \texttt{deploy}, und bietet kaum Parallelität, die sich lohnt. Bei grösseren Pipelines sieht das anders aus. Dort ist die Parallelisierung serieller Stages der zentrale Hebel, und Zampetti et al.~\cite{zampetti_empirical_2020} führen serielle Stages, die parallel laufen könnten, als typischen Konfigurationsfehler. Der \texttt{deploy:staging}-Job baut das Docker-Image neu. Das Image würde die Abhängigkeiten ein weiteres Mal installieren, doch der Docker-Layer-Cache hält den Abhängigkeits-Layer vor und überspringt diesen Schritt. So lief der Job im Messlauf in 2,3 Sekunden durch. Erst eine Änderung an \texttt{package.json} macht den Cache-Layer ungültig und löst die Installation erneut aus.
 
 		\subsection{Nachhaltigkeit}
 		
@@ -569,6 +575,7 @@ Der \ac{DAG} über das Schlüsselwort \texttt{needs} ist hier kaum ein Hebel. Di
 		\section{Ausblick}
 		
 		\section{Zusammenfassung}
+		\authornote{Christopher Schmitt}
 
 		\section*{Abkürzungsverzeichnis}
 		\begin{acronym}[Abkürzungsverzeichnis]