From 924a1a9927a8759217aee94292fb3c7ab7fafeea Mon Sep 17 00:00:00 2001 From: ChrPc Date: Fri, 22 May 2026 20:14:19 +0200 Subject: [PATCH] corrections --- DMS_paper15_gitlab.tex | 12 ++++++------ diagrams/omnibus_arch.tex | 2 +- diagrams/pipeline_stages.tex | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/DMS_paper15_gitlab.tex b/DMS_paper15_gitlab.tex index 61129a5..6cfd865 100644 --- a/DMS_paper15_gitlab.tex +++ b/DMS_paper15_gitlab.tex @@ -205,7 +205,7 @@ \section{CI/CD} \authornote{Christopher Schmitt} - Die Begriffe \ac{CI}, \ac{CD} und Continuous Deployment werden in der Literatur nicht einheitlich verwendet. Shahin et al.~\cite{shahin_continuous_2017} grenzen sie folgendermassen ab. \ac{CI} bezeichnet das automatische Übersetzen und Testen jeder Codeänderung gegen den gemeinsamen Hauptzweig. \ac{CD} ergänzt diesen Vorgang um die Eigenschaft, dass jeder geprüfte Stand jederzeit in eine produktionsnahe Umgebung ausgeliefert werden kann. Continuous Deployment automatisiert zusätzlich den letzten Schritt in die produktive Umgebung. GitLab deckt alle drei Stufen mit denselben Bausteinen ab: Runner, Pipelines und Jobs. Gesteuert werden diese zentral über eine einzelne Konfigurationsdatei im Repository \cite{cowell_automating_2023}. Die folgenden Abschnitte beschreiben die drei Bausteine im Einzelnen. + Die Begriffe \ac{CI}, \ac{CD} und Continuous Deployment werden in der Literatur nicht einheitlich verwendet. Shahin et al.~\cite{shahin_continuous_2017} grenzen sie klar ab. \ac{CI} bezeichnet das automatische Übersetzen und Testen jeder Codeänderung gegen den gemeinsamen Hauptzweig. \ac{CD} ergänzt diesen Vorgang um die Eigenschaft, dass jeder geprüfte Stand jederzeit in eine produktionsnahe Umgebung ausgeliefert werden kann. Der Schritt in die Produktion bleibt dabei eine bewusste, manuelle Freigabe. Continuous Deployment automatisiert auch diesen letzten Schritt. Alle drei Stufen bildet GitLab mit denselben Bausteinen ab: Runner, Pipelines und Jobs. Gesteuert werden sie zentral über eine einzige Konfigurationsdatei im Repository \cite{cowell_automating_2023}. \subsection{GitLab Runner} @@ -269,7 +269,7 @@ deploy-staging: - main \end{lstlisting} - Aus der starren Stage-Reihenfolge kann mit dem Schlüsselwort \texttt{needs} ein gerichteter azyklischer Graph (\acs{DAG}) gemacht werden. Ein Schritt darf dann starten, sobald seine konkret benannten Vorgänger fertig sind. Unnötige Wartezeiten entfallen \cite{cowell_automating_2023}. Wiederkehrende Pipeline-Bausteine können über das Schlüsselwort \texttt{include} aus anderen Repositories nachgeladen werden \cite{gitlab_gitlab_nodate}. Mit den in Abschnitt~\ref{subsec:komponenten} beschriebenen CI/CD-Komponenten existiert seit GitLab 16.0 ein weitergehender Mechanismus zur Wiederverwendung von Pipeline-Logik. + Aus der starren Stage-Reihenfolge lässt sich mit dem Schlüsselwort \texttt{needs} ein gerichteter azyklischer Graph bilden, ein sogenannter \ac{DAG}. Ein Schritt darf dann starten, sobald seine konkret benannten Vorgänger fertig sind. Unnötige Wartezeiten entfallen \cite{cowell_automating_2023}. Wiederkehrende Pipeline-Bausteine können über das Schlüsselwort \texttt{include} aus anderen Repositories nachgeladen werden \cite{gitlab_gitlab_nodate}. Mit den in Abschnitt~\ref{subsec:komponenten} beschriebenen CI/CD-Komponenten existiert seit GitLab 16.0 ein weitergehender Mechanismus zur Wiederverwendung von Pipeline-Logik. \subsection{Jobs} @@ -336,12 +336,12 @@ stages: \end{table} Die ersten beiden Stages werden bei jedem Push auf jeden Branch ausgeführt. Sie entsprechen den klassischen \ac{CI}-Schritten nach Duvall et al.~\cite{duvall_continuous_2007} und Fowler~\cite{fowler_continuous_2006} und sollen ein schnelles, automatisches Feedback auf jeden Codestand erzeugen. Die Stage \texttt{deploy} deckt den Continuous-Delivery-Anteil ab. Auf einem Feature-Branch steht der Job \texttt{deploy:staging} als manueller Schritt in der Pipeline-Übersicht bereit. Eine Änderung kann so bei Bedarf in einer laufenden Vorschau begutachtet werden, bevor sie in den Hauptzweig wandert. Ein Push auf \texttt{main} liefert automatisch nach \texttt{production} aus. Nach der Begriffsabgrenzung von Shahin et al.~\cite{shahin_continuous_2017} entspricht der Pfad nach \texttt{main} damit Continuous Deployment, der manuelle Pfad nach Staging klassischem Continuous Delivery. - Im Rahmen der Live-Präsentation wird der Lebenszyklus einer Codeänderung in drei Schritten gezeigt. Im ersten Schritt 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. Im zweiten Schritt 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. Im dritten Schritt wird der Merge Request gegen \texttt{main} akzeptiert. Eine neue Pipeline auf \texttt{main} durchläuft \texttt{lint} und \texttt{unit-test} und löst anschliessend automatisch \texttt{deploy:prod} aus. Die neue Version ist ohne weiteren manuellen Eingriff in der produktiven Umgebung erreichbar. An diesem Ablauf wird der Übergang von \ac{CI} über \ac{CD} bis Continuous Deployment nach Shahin et al.~\cite{shahin_continuous_2017} an einem laufenden System sichtbar. + 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 ist damit ohne weiteren manuellen Eingriff in der produktiven Umgebung erreichbar. \section{Selbstgehostete Lösung}\label{sec:selfhosted} \authornote{Christopher Schmitt} - GitLab kann nicht nur als \ac{SaaS} bezogen, sondern auch auf eigener Hardware selbst betrieben werden. 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. + 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. \subsection{Installation} @@ -405,8 +405,8 @@ stages: 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. + \item \emph{keine Wirtschaftlichkeit}, da zu hohe Wartungskosten oder zu wenig Kunden auf die Technologien setzen + \item \emph{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] diff --git a/diagrams/omnibus_arch.tex b/diagrams/omnibus_arch.tex index cf33eb9..62a6810 100644 --- a/diagrams/omnibus_arch.tex +++ b/diagrams/omnibus_arch.tex @@ -46,7 +46,7 @@ \draw[arr] (sidekiq.south) to[bend left=15] (pg.east); \draw[arr] (puma.south) to[bend left=10] (registry.north); \draw[arr, dashed] (runner.north) to[bend left=15] (puma.east); - \draw[arr, dashed] (puma.west) to[bend left=20] (mail.north); + \draw[arr, dashed] (puma.west) to[out=180, in=160, looseness=1.1] (mail.west); \end{tikzpicture}% } diff --git a/diagrams/pipeline_stages.tex b/diagrams/pipeline_stages.tex index 5353f13..85f5930 100644 --- a/diagrams/pipeline_stages.tex +++ b/diagrams/pipeline_stages.tex @@ -41,7 +41,7 @@ \node[job, below=of j4a] (j4b) {prod (manual)}; % needs/DAG: container braucht nur bundle, nicht alle vorigen - \draw[dagarr] (j3a.east) to[bend left=10] node[above, midway, font=\tiny\itshape] {needs} (j3b.west); + \draw[dagarr] (j3a.east) to[bend left=55] node[midway, right=1pt, font=\tiny\itshape] {needs} (j3b.east); % Pipeline-Klammer drumherum \begin{pgfonlayer}{background}