From 30b760f405775eca722acc3689885c433ce9603a Mon Sep 17 00:00:00 2001 From: ChrPc Date: Fri, 22 May 2026 11:14:24 +0200 Subject: [PATCH 1/8] added pipeline and omnibus diagrams --- diagrams/omnibus_arch.tex | 55 ++++++++++++++++++++++++++++++++++++ diagrams/pipeline_stages.tex | 55 ++++++++++++++++++++++++++++++++++++ 2 files changed, 110 insertions(+) create mode 100644 diagrams/omnibus_arch.tex create mode 100644 diagrams/pipeline_stages.tex diff --git a/diagrams/omnibus_arch.tex b/diagrams/omnibus_arch.tex new file mode 100644 index 0000000..cf33eb9 --- /dev/null +++ b/diagrams/omnibus_arch.tex @@ -0,0 +1,55 @@ +% Architekturdiagramm der GitLab-Omnibus-Komponenten +% Einbinden im Hauptdokument: +% \usepackage{tikz} +% \usetikzlibrary{positioning,arrows.meta,fit,backgrounds} +% und an der gewünschten Stelle: +% \input{diagrams/omnibus_arch} + +\begin{figure}[H] + \centering + \resizebox{\columnwidth}{!}{% + \begin{tikzpicture}[ + node distance=6mm and 8mm, + font=\footnotesize\sffamily, + every node/.style={align=center}, + comp/.style={draw, rounded corners=2pt, minimum height=8mm, minimum width=20mm, fill=blue!5}, + store/.style={draw, rounded corners=2pt, minimum height=8mm, minimum width=20mm, fill=green!8}, + ext/.style={draw, dashed, rounded corners=2pt, minimum height=8mm, minimum width=20mm, fill=gray!5}, + arr/.style={-{Stealth[length=2mm]}, thick}, + ] + + % Ebene 1: Eingang + \node[comp] (browser) {Browser / git-Client}; + \node[comp, right=of browser] (nginx) {nginx\\(Reverse Proxy)}; + + % Ebene 2: Anwendungsschicht + \node[comp, below=of nginx] (puma) {Puma\\(Rails-App)}; + \node[comp, right=of puma] (sidekiq) {Sidekiq\\(Hintergrundjobs)}; + + % Ebene 3: Datenschicht + \node[store, below=of puma] (pg) {PostgreSQL\\(Daten)}; + \node[store, right=of pg] (redis) {Redis\\(Cache, Queue)}; + \node[store, left=of pg] (gitaly) {Gitaly\\(Repo-Storage)}; + + % Ebene 4: Add-Ons + \node[comp, below=of pg] (registry) {Container\\Registry}; + \node[ext, right=of registry] (runner) {GitLab Runner\\(extern)}; + \node[ext, left=of registry] (mail) {SMTP-Server\\(extern)}; + + % Verbindungen + \draw[arr] (browser) -- (nginx); + \draw[arr] (nginx) -- (puma); + \draw[arr] (puma) -- (pg); + \draw[arr] (puma) -- (redis); + \draw[arr] (puma.west) to[bend right=20] (gitaly.north); + \draw[arr] (sidekiq) -- (redis); + \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); + + \end{tikzpicture}% + } + \caption{Komponenten einer Self-Managed-Instanz im Omnibus-Paket. Gestrichelte Komponenten laufen ausserhalb des Omnibus-Pakets und werden separat angebunden.} + \label{fig:omnibus-arch} +\end{figure} diff --git a/diagrams/pipeline_stages.tex b/diagrams/pipeline_stages.tex new file mode 100644 index 0000000..5353f13 --- /dev/null +++ b/diagrams/pipeline_stages.tex @@ -0,0 +1,55 @@ +% Pipeline-Schema: Pipeline -> Stages -> Jobs mit needs/DAG-Pfeil +% Einbinden im Hauptdokument: +% \usepackage{tikz} +% \usetikzlibrary{positioning,arrows.meta,fit,backgrounds} +% und an der gewünschten Stelle: +% \input{diagrams/pipeline_stages} + +\begin{figure}[H] + \centering + \resizebox{\columnwidth}{!}{% + \begin{tikzpicture}[ + node distance=4mm and 6mm, + font=\footnotesize\sffamily, + every node/.style={align=center}, + stage/.style={draw, rounded corners=3pt, minimum width=22mm, minimum height=6mm, fill=blue!10, font=\bfseries\footnotesize\sffamily}, + job/.style={draw, rounded corners=2pt, minimum width=22mm, minimum height=6mm, fill=white}, + arr/.style={-{Stealth[length=2mm]}}, + dagarr/.style={-{Stealth[length=2mm]}, dashed, red!70!black, thick}, + ] + + % Stage-Header + \node[stage] (s1) {lint}; + \node[stage, right=12mm of s1] (s2) {test}; + \node[stage, right=12mm of s2] (s3) {build}; + \node[stage, right=12mm of s3] (s4) {deploy}; + + \draw[arr] (s1) -- (s2); + \draw[arr] (s2) -- (s3); + \draw[arr] (s3) -- (s4); + + % Jobs unter den Stages + \node[job, below=of s1] (j1) {eslint}; + + \node[job, below=of s2] (j2a) {unit}; + \node[job, below=of j2a] (j2b) {integration}; + + \node[job, below=of s3] (j3a) {bundle}; + \node[job, below=of j3a] (j3b) {container}; + + \node[job, below=of s4] (j4a) {staging}; + \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); + + % Pipeline-Klammer drumherum + \begin{pgfonlayer}{background} + \node[draw, dotted, rounded corners=4pt, fit=(s1)(s4)(j2b)(j3b)(j4b), inner sep=4mm, label={[anchor=north west, font=\small\bfseries]north west:Pipeline}] {}; + \end{pgfonlayer} + + \end{tikzpicture}% + } + \caption{Aufbau einer Pipeline aus Stages und Jobs. Durchgezogene Pfeile: starre Stage-Reihenfolge. Gestrichelter Pfeil: needs-Beziehung (\acs{DAG}-Modus), die unnötiges Warten verkürzt.} + \label{fig:pipeline-stages} +\end{figure} From 9fd01f88612bf052480b051f526050b798ad4210 Mon Sep 17 00:00:00 2001 From: ChrPc Date: Fri, 22 May 2026 11:14:24 +0200 Subject: [PATCH 2/8] added ci/cd and selfhosted sources --- literatur/dms.bib | 195 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 195 insertions(+) diff --git a/literatur/dms.bib b/literatur/dms.bib index 04a1320..b7c1fd2 100644 --- a/literatur/dms.bib +++ b/literatur/dms.bib @@ -164,6 +164,201 @@ file = {C:\Users\Roman\Zotero\storage\SHDE2M4E\viewer.html} } +@book{humble_continuous_2010, + title = {Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation}, + shorttitle = {Continuous Delivery}, + author = {Humble, Jez and Farley, David}, + year = {2010}, + publisher = {Addison-Wesley Professional}, + address = {Boston, MA}, + series = {Addison-Wesley Signature Series (Fowler)}, + isbn = {978-0-321-60191-9}, + pages = {512}, +} + +@book{duvall_continuous_2007, + title = {Continuous Integration: Improving Software Quality and Reducing Risk}, + shorttitle = {Continuous Integration}, + author = {Duvall, Paul M. and Matyas, Steve and Glover, Andrew}, + year = {2007}, + publisher = {Addison-Wesley}, + address = {Upper Saddle River, NJ}, + series = {Addison-Wesley Signature Series (Fowler)}, + isbn = {978-0-321-33638-5}, + pages = {336}, +} + +@misc{fowler_continuous_2006, + title = {Continuous Integration}, + author = {Fowler, Martin}, + year = {2006}, + month = may, + howpublished = {martinfowler.com}, + url = {https://martinfowler.com/articles/continuousIntegration.html}, + urldate = {2026-05-04}, +} + +@book{kim_devops_2022, + title = {Das {DevOps}-{Handbuch}: Teams, Tools und Infrastrukturen erfolgreich umgestalten}, + shorttitle = {Das {DevOps}-{Handbuch}}, + author = {Kim, Gene and Humble, Jez and Debois, Patrick and Willis, John and Forsgren, Nicole}, + year = {2022}, + edition = {2., aktualisierte und erweiterte Auflage}, + publisher = {O'Reilly / dpunkt.verlag}, + address = {Heidelberg}, + isbn = {978-3-96009-199-8}, + pages = {520}, +} + +@book{forsgren_accelerate_2018, + title = {Accelerate: The Science of Lean Software and {DevOps}. Building and Scaling High Performing Technology Organizations}, + shorttitle = {Accelerate}, + author = {Forsgren, Nicole and Humble, Jez and Kim, Gene}, + year = {2018}, + publisher = {IT Revolution Press}, + address = {Portland, OR}, + isbn = {978-1-942788-33-1}, +} + +@book{newman_building_2021, + title = {Building Microservices: Designing Fine-Grained Systems}, + shorttitle = {Building Microservices}, + author = {Newman, Sam}, + year = {2021}, + edition = {2nd}, + publisher = {O'Reilly Media}, + address = {Sebastopol, CA}, + isbn = {978-1-492-03402-5}, +} + +@book{bass_devops_2015, + title = {{DevOps}: A Software Architect's Perspective}, + shorttitle = {{DevOps}}, + author = {Bass, Len and Weber, Ingo and Zhu, Liming}, + year = {2015}, + publisher = {Addison-Wesley Professional}, + address = {Upper Saddle River, NJ}, + series = {SEI Series in Software Engineering}, + isbn = {978-0-13-404984-7}, +} + +@book{wolff_microservices_2018, + title = {Microservices: Grundlagen flexibler Softwarearchitekturen}, + shorttitle = {Microservices}, + author = {Wolff, Eberhard}, + year = {2018}, + edition = {2.}, + publisher = {dpunkt.verlag}, + address = {Heidelberg}, + isbn = {978-3-86490-555-1}, + pages = {374}, + url = {https://www.assets.dpunkt.de/openbooks/Wolff_Microservices.pdf}, +} + +@article{shahin_continuous_2017, + title = {Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices}, + shorttitle = {Continuous Integration, Delivery and Deployment}, + author = {Shahin, Mojtaba and Babar, Muhammad Ali and Zhu, Liming}, + year = {2017}, + journal = {IEEE Access}, + volume = {5}, + pages = {3909--3943}, + doi = {10.1109/ACCESS.2017.2685629}, +} + +@inproceedings{hilton_usage_2016, + title = {Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects}, + author = {Hilton, Michael and Tunnell, Timothy and Huang, Kai and Marinov, Darko and Dig, Danny}, + year = {2016}, + booktitle = {Proceedings of the 31st {IEEE}/{ACM} International Conference on Automated Software Engineering ({ASE} 2016)}, + address = {Singapore}, + pages = {426--437}, + doi = {10.1145/2970276.2970358}, +} + +@article{soares_effects_2022, + title = {The effects of continuous integration on software development: a systematic literature review}, + shorttitle = {The effects of continuous integration on software development}, + author = {Soares, Eliakim and Sizilio, Gustavo and Santos, Jadson and {da Costa}, Daniel Alencar and Kulesza, Uir{\'a}}, + year = {2022}, + journal = {Empirical Software Engineering}, + volume = {27}, + number = {3}, + pages = {78}, + doi = {10.1007/s10664-021-10114-1}, +} + +@article{zampetti_empirical_2020, + title = {An empirical characterization of bad practices in continuous integration}, + author = {Zampetti, Fiorella and Vassallo, Carmine and Panichella, Sebastiano and Canfora, Gerardo and Gall, Harald and {Di Penta}, Massimiliano}, + year = {2020}, + journal = {Empirical Software Engineering}, + volume = {25}, + number = {2}, + pages = {1095--1135}, + doi = {10.1007/s10664-019-09785-8}, +} + +@article{rostami_usage_2023, + title = {On the usage, co-usage and migration of {CI}/{CD} tools: A qualitative analysis}, + shorttitle = {On the usage, co-usage and migration of {CI}/{CD} tools}, + author = {{Rostami Mazrae}, Pooya and Mens, Tom and Golzadeh, Mehdi and Decan, Alexandre}, + year = {2023}, + journal = {Empirical Software Engineering}, + volume = {28}, + number = {2}, + pages = {52}, + doi = {10.1007/s10664-022-10285-5}, +} + +@inproceedings{golzadeh_rise_2022, + title = {On the Rise and Fall of {CI} Services in {GitHub}}, + author = {Golzadeh, Mehdi and Decan, Alexandre and Mens, Tom}, + year = {2022}, + booktitle = {Proceedings of the 2022 {IEEE} International Conference on Software Analysis, Evolution and Reengineering ({SANER} 2022)}, + address = {Honolulu, HI}, + pages = {662--672}, + doi = {10.1109/SANER53432.2022.00084}, +} + +@book{painter_practical_2024, + title = {Practical {GitLab} Services: A Complete {DevOps} Guide for Developers and Administrators}, + shorttitle = {Practical {GitLab} Services}, + author = {Painter, Jeffrey}, + year = {2024}, + publisher = {Apress (Springer Nature)}, + address = {Berkeley, CA}, + isbn = {979-8-8688-0426-7}, + doi = {10.1007/979-8-8688-0427-4}, + pages = {905}, +} + +@book{cowell_automating_2023, + title = {Automating {DevOps} with {GitLab} {CI}/{CD} Pipelines: Build efficient {CI}/{CD} pipelines to verify, secure, and deploy your code using real-life examples}, + shorttitle = {Automating {DevOps} with {GitLab} {CI}/{CD} Pipelines}, + author = {Cowell, Christopher and Lotz, Nicholas and Timberlake, Chris}, + year = {2023}, + publisher = {Packt Publishing}, + address = {Birmingham}, + isbn = {978-1-80323-300-0}, + pages = {348}, +} + +@misc{gitlab_s1_2021, + title = {Form {S}-1 Registration Statement}, + author = {{GitLab Inc.}}, + year = {2021}, + month = sep, + howpublished = {U.S. Securities and Exchange Commission, EDGAR Filing System}, + url = {https://www.sec.gov/Archives/edgar/data/1653482/000162828021018193/gitlabs-1.htm}, + urldate = {2026-05-04}, + note = {SEC-Anmeldung im Rahmen des Börsengangs am NASDAQ am 14.\,Oktober 2021}, +} + +% WARNUNG: Folgende Quelle (dcfmodeling.com) ist eine SEO-/Marketing-Seite mit +% deutlich AI-generiertem Inhalt (mehrere "defintely"-Tippfehler im Text). +% Vom Prof als problematisch eingestuft. Für den NASDAQ-IPO-Bezug stattdessen +% gitlab_s1_2021 (offizielles SEC S-1 Filing) verwenden. @misc{teamGitLabIncGTLB, title = {{{GitLab Inc}}. ({{GTLB}}): {{History}}, {{Ownership}}, {{Mission}}, {{How It Works}} \& {{Makes Money}}}, shorttitle = {{{GitLab Inc}}. ({{GTLB}})}, From 3b3870887ce2d5f8d3b1f1d1f678bfe586f925ac Mon Sep 17 00:00:00 2001 From: ChrPc Date: Fri, 22 May 2026 11:14:24 +0200 Subject: [PATCH 3/8] wrote ci/cd and selfhosted chapters --- DMS_paper15_gitlab.tex | 220 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 212 insertions(+), 8 deletions(-) diff --git a/DMS_paper15_gitlab.tex b/DMS_paper15_gitlab.tex index 853d282..5314c72 100644 --- a/DMS_paper15_gitlab.tex +++ b/DMS_paper15_gitlab.tex @@ -18,9 +18,43 @@ \usepackage{hyperref} \usepackage{amsmath} +\usepackage{xcolor} +\usepackage{listings} + +\usepackage{tikz} +\usetikzlibrary{positioning,arrows.meta,fit,backgrounds} \usepackage{biblatex} +% Lstlisting-Stil für YAML-Beispiele +\definecolor{lstbg}{rgb}{0.97,0.97,0.97} +\definecolor{lstkw}{rgb}{0.10,0.30,0.65} +\definecolor{lstcm}{rgb}{0.40,0.40,0.40} +\lstdefinelanguage{yaml}{ + keywords={true,false,null}, + keywordstyle=\color{lstkw}\bfseries, + sensitive=false, + comment=[l]{\#}, + commentstyle=\color{lstcm}\itshape, + morestring=[b]', + morestring=[b]", +} +\lstset{ + backgroundcolor=\color{lstbg}, + basicstyle=\ttfamily\footnotesize, + breaklines=true, + captionpos=b, + frame=single, + framesep=4pt, + rulecolor=\color{black!20}, + xleftmargin=4pt, + xrightmargin=4pt, + showstringspaces=false, +} + +% Markierung des Verfassers eines Kapitels (Pflicht laut Profvorgabe) +\newcommand{\authornote}[1]{\textit{\small Verfasst von: #1}\par\medskip} + \graphicspath{ {./bilder/} } \geometry{ @@ -169,22 +203,189 @@ Aufgrund der grösseren Nutzerbasis eignet sich GitHub mehr für eine kollaborative Zusammenarbeit an \ac{OSS}. Ein Projekt erreicht mehr Nutzer, die potenziell beitragen können. \section{CI/CD} - - %https://docs.gitlab.com/topics/build_your_application/ - + \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. + \subsection{GitLab Runner} + + Die GitLab-Instanz selbst führt keine \ac{CI}/\ac{CD}-Arbeit aus. Diese Aufgabe übernimmt ein separater Hilfsprozess, der \textbf{Runner} \cite{gitlab_gitlab_nodate}. Ein Runner registriert sich einmal mit einem Token bei der Instanz und holt sich danach selbständig offene Aufgaben ab. Durch diese Trennung kann die Ausführung horizontal skaliert werden. Plattformabhängige Aufgaben lassen sich gezielt auf der passenden Hardware ausführen \cite{painter_practical_2024}. Runner können auf drei unterschiedlichen Ebenen registriert werden: + \begin{itemize} + \item \textbf{Instanz} Auf Instanzebene registrierte Runner stehen allen Projekten der GitLab-Instanz zur Verfügung. Sie werden in der Regel von der Administration bereitgestellt. + \item \textbf{Gruppe} Auf Gruppenebene registrierte Runner nehmen Aufgaben aus sämtlichen Projekten innerhalb dieser Gruppe und ihrer Subgruppen an. Eingesetzt werden sie meistens dann, wenn eine Gruppe besondere Anforderungen an Hardware oder Software stellt. + \item \textbf{Projekt} Auf Projektebene registrierte Runner sind ausschliesslich an ein einzelnes Projekt gebunden. Diese Variante eignet sich für sensitive Projekte, bei denen kein gemeinsam genutzter Runner verwendet werden soll. + \end{itemize} + Wie ein Runner eine konkrete Aufgabe ausführt, hängt vom konfigurierten \textbf{Executor} ab. Der Executor entscheidet, in welcher Umgebung das vom Anwender hinterlegte Skript läuft. Tabelle~\ref{tab:executors} listet die in der Praxis am häufigsten verwendeten Executors auf. + \begin{table}[H] + \centering + \caption{Häufig verwendete Executors des GitLab Runners \cite{gitlab_gitlab_nodate}} + \label{tab:executors} + \resizebox{\columnwidth}{!}{% + \begin{tabular}{@{}lll@{}} + \toprule + Executor & Ausführungsumgebung & Typischer Einsatz \\ \midrule + \texttt{shell} & direkt auf dem Hostsystem & einfache Setups, Eigenbau-Server \\ + \texttt{docker} & je Aufgabe ein neuer Container & in der Praxis der Standardfall \\ + \texttt{docker-machine} & ephemere Cloud-VMs & elastische Skalierung \\ + \texttt{kubernetes} & ein Pod je Aufgabe & grosse Cluster, Autoskalierung \\ + \texttt{ssh} & entfernter Host über SSH & Legacy-Systeme \\ \bottomrule + \end{tabular}% + } + \end{table} + Die Wahl des Executors hat neben der technischen auch eine organisatorische Dimension. Nach Rostami Mazrae et al.~\cite{rostami_usage_2023} startet der \texttt{shell}-Executor zwar mit minimalem Aufwand, wird in produktiven Umgebungen aufgrund fehlender Isolation aber üblicherweise durch \texttt{docker} oder \texttt{kubernetes} ersetzt. Sicherheitsrisiken entstehen vor allem dann, wenn mehrere Projekte denselben \texttt{shell}-Runner verwenden und ein Skript das Hostsystem dauerhaft verändert. + \subsection{Pipelines} + + Eine \textbf{Pipeline} ist in GitLab die oberste Ebene der Automatisierung. Sie umfasst sämtliche Schritte, die als Reaktion auf ein Ereignis im Repository ablaufen \cite{gitlab_gitlab_nodate}. Ausgelöst wird eine Pipeline durch unterschiedliche Ereignisse. Dazu gehören ein Push, das Öffnen eines \textbf{Merge Requests}, ein hinterlegter Zeitplan, ein manueller Klick in der Weboberfläche oder das Ende einer anderen Pipeline \cite{cowell_automating_2023}. + + Innerhalb einer Pipeline werden die einzelnen Arbeitsschritte zu sogenannten \textbf{Stages} zusammengefasst. Alle Schritte einer Stage laufen parallel und müssen erfolgreich abgeschlossen sein, bevor die nächste Stage beginnt \cite{gitlab_gitlab_nodate}. Eine in der Praxis verbreitete Reihenfolge der Stages ist \texttt{lint}, \texttt{test}, \texttt{build} und \texttt{deploy}. Abbildung~\ref{fig:pipeline-stages} zeigt das Verhältnis von Pipeline, Stages und Jobs. + + \input{diagrams/pipeline_stages} + + Die gesamte Definition einer Pipeline liegt in einer einzigen Datei. Diese trägt den Namen \texttt{.gitlab-ci.yml} und befindet sich im Wurzelverzeichnis des Repositories \cite{gitlab_gitlab_nodate}. Damit folgt GitLab dem von Humble und Farley~\cite{humble_continuous_2010} eingeführten \textbf{Pipeline-as-Code}-Prinzip. Die Beschreibung des Build- und Auslieferungsprozesses wird wie Anwendungscode versioniert und im Review geprüft. Listing~\ref{lst:gitlabciyml} zeigt einen minimalen Aufbau mit drei Stages. + + \begin{lstlisting}[language=yaml,caption={Minimaler Aufbau einer .gitlab-ci.yml},label={lst:gitlabciyml}] +stages: + - test + - build + - deploy + +unit-test: + stage: test + script: + - npm ci + - npm test + +build-image: + stage: build + script: + - docker build -t app:$CI_COMMIT_SHA . + +deploy-staging: + stage: deploy + script: + - ssh user@host 'docker pull app' + only: + - 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. + \subsection{Jobs} - \subsection{CICD-Komponenten} + + Die eigentliche Arbeitseinheit innerhalb einer Pipeline ist der \textbf{Job}. Ein Job führt ein vom Anwender festgelegtes Skript in einer isolierten Umgebung aus und ist genau einer Stage zugeordnet \cite{gitlab_gitlab_nodate}. Jobs derselben Stage sind voneinander unabhängig und werden parallel auf den verfügbaren Runnern ausgeführt. Ob die Pipeline weiterläuft, hängt vom Ergebnis sämtlicher Jobs einer Stage ab. + + Mit dem Schlüsselwort \texttt{rules} wird pro Job festgelegt, unter welchen Bedingungen dieser ausgeführt wird. Beispiele sind die Beschränkung auf bestimmte Branches, die Ausführung nur bei Änderungen an bestimmten Dateien oder die Abhängigkeit vom Ergebnis vorheriger Jobs \cite{cowell_automating_2023}. Ein als \texttt{manual} markierter Job läuft erst nach einer expliziten Freigabe über die Weboberfläche. Diese Konstruktion wird häufig für Auslieferungen in produktive Umgebungen genutzt. + + Während ein Job läuft, entstehen häufig Dateien, die spätere Jobs weiterverarbeiten. Beispiele sind ein gebautes Bundle, ein Container-Image oder ein Testbericht. GitLab unterscheidet dafür zwei Mechanismen mit unterschiedlicher Lebensdauer \cite{gitlab_gitlab_nodate}: + \begin{itemize} + \item \textbf{Artefakte} Artefakte sind benannte Ergebnisse eines Jobs. Sie werden nach dem erfolgreichen Abschluss eines Jobs an die GitLab-Instanz hochgeladen, stehen dort zum Download bereit und werden an spätere Jobs der Pipeline weitergegeben. + \item \textbf{Caches} Caches dienen ausschliesslich dazu, wiederholte Ausführungen zu beschleunigen. Typisch ist das Zwischenspeichern heruntergeladener Abhängigkeiten zwischen Pipeline-Läufen. Über Jobgrenzen hinweg ist der Cache nicht garantiert verfügbar. + \end{itemize} + Das Ziel einer Auslieferung wird durch das Konzept der \textbf{Environments} beschrieben \cite{cowell_automating_2023}. Jedes Environment fasst alle Auslieferungen in eine bestimmte Zielumgebung zusammen. In der Weboberfläche wird zusätzlich protokolliert, welche Version dort gerade läuft. Einen Sonderfall bilden \textbf{Review-Apps}. Für jeden offenen Merge Request erzeugt GitLab automatisch eine isolierte, kurzlebige Auslieferung, in der die geänderte Anwendung vor dem Merge begutachtet werden kann \cite{gitlab_gitlab_nodate}. Nach Rostami Mazrae et al.~\cite{rostami_usage_2023} ist diese direkte Kopplung zwischen Review und laufender Vorschau eines der Merkmale, mit denen sich GitLab von alternativen Plattformen abgrenzt. + + Zampetti et al.~\cite{zampetti_empirical_2020} identifizieren in einer empirischen Untersuchung 79 wiederkehrende Anti-Muster in CI-Konfigurationen. Häufige Probleme sind unnötig sequentielle Stages, zu grobgranulare Jobs und das Vermischen von Cache und Artefakten. Lesbarkeit und Wartbarkeit der Pipeline-Definition sind damit ein eigenes Qualitätskriterium. + + \subsection{CICD-Komponenten}\label{subsec:komponenten} + + Mit dem Schlüsselwort \texttt{include} können bereits seit längerem ganze Pipeline-Fragmente aus anderen Repositories oder von einer entfernten \ac{URL} eingebunden werden \cite{gitlab_gitlab_nodate}. In der Praxis stellen sich dabei zwei wiederkehrende Probleme. Eingebundene Fragmente sind in den meisten Fällen weder versioniert noch besitzen sie eine eigene Schnittstelle. Eine Änderung am Fragment kann sämtliche Pipelines mit einbinden \cite{cowell_automating_2023}. + + Seit GitLab 16.0 lösen \textbf{CI/CD-Komponenten} dieses Problem. Eine Komponente ist ein versionierter und parametrisierbarer Pipeline-Baustein, der ähnlich wie eine Software-Bibliothek verwendet wird \cite{gitlab_gitlab_nodate}. Komponenten werden in einem dedizierten Projekt entwickelt und veröffentlicht. Drei Bestandteile sind dabei zwingend vorgesehen: + \begin{itemize} + \item \textbf{Manifest} In einer Datei \texttt{template.yml} beschreibt die Komponente ihre Eingabeparameter mit Datentyp und Defaultwert sowie die von ihr beigesteuerten Jobs. + \item \textbf{Versionsschild} Komponenten werden ausschliesslich über Git-Tags freigegeben. Ein Konsument referenziert eine Komponente immer mit einer konkreten Version. Damit kann sich der eingebundene Stand nicht unter dem Konsumenten verändern. + \item \textbf{Katalogeintrag} Ein Projekt, das den Status \textit{Components Project} erhält, erscheint im zentralen \textbf{Component Catalog} der GitLab-Instanz. Die Suche nach geeigneten Komponenten erfolgt dort, ohne dass Repository-Pfade auswendig bekannt sein müssen. + \end{itemize} + Listing~\ref{lst:component} zeigt die Einbindung einer beispielhaften Lint-Komponente in eine bestehende Pipeline. + + \begin{lstlisting}[language=yaml,caption={Einbindung einer CI/CD-Komponente},label={lst:component}] +include: + - component: $CI_SERVER_FQDN/team/lint@1.2.0 + inputs: + stage: lint + node-version: '20' + +stages: + - lint + - test +\end{lstlisting} + + Im Gegensatz zum klassischen \texttt{include} besitzt die Komponente damit eine echte Aufrufsignatur. Die Eingabewerte werden vom Aufrufer im Block \texttt{inputs} gesetzt und sind unter dem Präfix \texttt{\$[[ inputs. ]]} innerhalb der Komponente verfügbar \cite{gitlab_gitlab_nodate}. Nach Cowell et al.~\cite{cowell_automating_2023} ist diese Trennung zwischen Schnittstelle und Implementierung der wesentliche Schritt, der Pipeline-Logik in grösseren Organisationen wartbar hält. Die Anti-Muster, die Zampetti et al.~\cite{zampetti_empirical_2020} beschreiben, lassen sich auf diese Weise an einer einzigen Stelle korrigieren, ohne dass sämtliche Pipelines angefasst werden müssen. + \subsection{Anwendungsbeispiel} - \section{Selbstgehostete Lösung} + Zur praktischen Demonstration der vorhergehenden Konzepte wurde eine kleine Webanwendung auf der in Abschnitt~\ref{sec:selfhosted} beschriebenen selbstgehosteten Instanz aufgesetzt. Die Anwendung ist bewusst minimal gehalten. So liegt der Fokus auf der \ac{CI}/\ac{CD}-Konfiguration und nicht auf dem Anwendungscode. + + Die Demoanwendung ist ein \texttt{HTTP}-Dienst, der in \textbf{Node.js} mit dem Web-Framework \textbf{Express} geschrieben ist. Bereitgestellt wird ein einzelner Endpunkt \texttt{GET /}, der eine kurze HTML-Seite mit der Bezeichnung der aktuellen Umgebung und der im Build verbauten Versionskennung ausliefert. Beide Werte werden zur Laufzeit über Umgebungsvariablen aus dem Container gelesen und im jeweiligen Deploy-Job gesetzt. Eine kleine Testsuite mit dem Framework \texttt{vitest} prüft, dass der Endpunkt eine HTML-Antwort mit Statuscode~200 und der erwarteten Versionsangabe liefert. + + Die zugehörige \texttt{.gitlab-ci.yml} definiert drei Stages: \texttt{lint}, \texttt{test} und \texttt{deploy}. Die Stage \texttt{deploy} enthält dabei zwei Jobs, die sich gegenseitig ausschliessen. Tabelle~\ref{tab:demo-pipeline} fasst zusammen, welcher Schritt unter welchen Bedingungen ausgeführt wird und welches Environment er bedient. + \begin{table}[H] + \centering + \caption{Stages der Demo-Pipeline und ihre Auslöser} + \label{tab:demo-pipeline} + \resizebox{\columnwidth}{!}{% + \begin{tabular}{@{}llll@{}} + \toprule + Stage / Job & Auslöser & Ergebnis & Environment \\ \midrule + \texttt{lint} & jeder Push & Stilbericht & -- \\ + \texttt{unit-test} & jeder Push & Testbericht & -- \\ + \texttt{deploy:staging} & alle Branches ausser \texttt{main}, manuell & Container in Staging & \texttt{staging} \\ + \texttt{deploy:prod} & Push auf \texttt{main}, automatisch & Container in Produktion & \texttt{production} \\ \bottomrule + \end{tabular}% + } + \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. + \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 \textbf{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} - + + Für die selbstgehostete \ac{CE} bietet GitLab das sogenannte \textbf{Omnibus-Paket} an \cite{painter_practical_2024}. Im Paket enthalten sind sämtliche Komponenten, die GitLab im Betrieb benötigt. Dazu zählen der Webserver \texttt{nginx}, der Anwendungsserver \texttt{Puma}, die relationale Datenbank \texttt{PostgreSQL} und der Schlüssel-Wert-Speicher \texttt{Redis}. Weitere Hintergrundprozesse kommen hinzu \cite{gitlab_gitlab_nodate}. Abbildung~\ref{fig:omnibus-arch} zeigt das Zusammenspiel der einzelnen Bausteine. + + \input{diagrams/omnibus_arch} + + Der wesentliche Vorteil des Omnibus-Paketes ist, dass die einzelnen Komponenten nicht selbst installiert und aufeinander abgestimmt werden müssen. Ein einzelner Aufruf des Paketmanagers genügt. Auf debian-basierten Systemen wird das GitLab-Paketrepository einmalig hinzugefügt und anschliessend \texttt{apt install gitlab-ce} ausgeführt \cite{gitlab_gitlab_nodate}. + + Für diese Arbeit wurde GitLab \ac{CE} auf einem privaten Linux-Server installiert. Als Betriebssystem kam eine aktuelle LTS-Variante von Ubuntu zum Einsatz. GitLab empfiehlt für eine produktive Instanz mit bis zu 20 aktiven Nutzern mindestens vier Kerne und 8\,GiB Arbeitsspeicher \cite{gitlab_gitlab_nodate}. Da die verwendete Hardware diesen Richtwert beim Arbeitsspeicher nicht vollständig erreicht, wurde zusätzlich eine Swap-Datei eingerichtet, um Lastspitzen während des ersten \texttt{reconfigure}-Laufs aufzufangen. Die Installation selbst lief unauffällig. Das Paket wurde heruntergeladen und entpackt. Das mitgelieferte Skript \texttt{gitlab-ctl reconfigure} brachte die Instanz innerhalb weniger Minuten in einen lauffähigen Zustand. Eine erste Anmeldung über die Weboberfläche war direkt möglich. + + Eine Besonderheit des hier beschriebenen Aufbaus betrifft die Erreichbarkeit der Instanz. Anstatt die Instanz über eine öffentliche Domain freizugeben, wird die gesamte Kommunikation über ein privates Overlay-Netzwerk auf VPN-Basis abgewickelt. Der Webserver \texttt{nginx} bindet sich dadurch ausschliesslich an die lokale Schnittstelle. Externe Anfragen aus dem Overlay-Netzwerk werden über einen vorgelagerten Proxy entgegengenommen und auf den lokalen Port weitergereicht. Ein zugehöriges \ac{TLS}-Zertifikat wird vom Overlay-Dienst selbst bereitgestellt. Auf eine direkte Exposition der Ports 80 und 443 zum öffentlichen Internet wird auf diese Weise vollständig verzichtet. + \subsection{Konfiguration} - + + Eine Self-Managed-Instanz wird zentral über die Datei \texttt{/etc/gitlab/gitlab.rb} konfiguriert \cite{painter_practical_2024}. Sämtliche Komponenten des Omnibus-Pakets lesen ihre Einstellungen aus dieser Datei. Bei jedem Aufruf von \texttt{gitlab-ctl reconfigure} werden die Komponenten mit dem aktuellen Stand neu initialisiert. Tabelle~\ref{tab:gitlabrb} zeigt eine Auswahl der für den vorliegenden Aufbau relevanten Optionen. + \begin{table}[H] + \centering + \caption{Auswahl an Konfigurationsoptionen aus \texttt{gitlab.rb} \cite{gitlab_gitlab_nodate, painter_practical_2024}} + \label{tab:gitlabrb} + \resizebox{\columnwidth}{!}{% + \begin{tabular}{@{}lll@{}} + \toprule + Option & Wert & Zweck \\ \midrule + \texttt{external\_url} & \texttt{https://} & von aussen sichtbare \ac{URL} \\ + \texttt{nginx['listen\_addresses']} & \texttt{['127.0.0.1']} & nur lokales Binding \\ + \texttt{letsencrypt['enable']} & \texttt{false} & kein eigenes Zertifikat \\ + \texttt{registry['enable']} & \texttt{true/false} & Container Registry \\ + \texttt{gitlab\_rails['smtp\_*']} & Provider & Versand von Systemmails \\ + \texttt{puma['worker\_processes']} & \texttt{0--n} & Anzahl Anwendungsprozesse \\ + \texttt{sidekiq['max\_concurrency']} & \texttt{8--25} & Hintergrundjobs parallel \\ + \texttt{backup\_keep\_time} & in Sekunden & Aufbewahrungsdauer Backups \\ \bottomrule + \end{tabular}% + } + \end{table} + + Eine geführte Erstkonfiguration, wie sie die \ac{SaaS}-Variante bietet, existiert nicht. Nach der Installation läuft die Instanz zwar, befindet sich aber in einem generischen Standardzustand. Alles Projektspezifische muss selbst zusammengesucht werden. Im hier beschriebenen Aufbau war dies der zeitaufwendigste Teil der Bereitstellung. Die reine Paketinstallation war in unter zehn Minuten abgeschlossen. Das anschliessende Einrichten von Erreichbarkeit, Mailversand, Container Registry und Runnern beanspruchte mehrere Stunden, weil die Optionen in \texttt{gitlab.rb} ohne Vorwissen über die jeweiligen Komponenten schwer einzuordnen sind \cite{painter_practical_2024}. + \subsection{Betrieb} + + Im laufenden Betrieb wird GitLab über das Kommandozeilenwerkzeug \texttt{gitlab-ctl} gesteuert. Damit lassen sich die Hintergrunddienste starten, stoppen und überwachen \cite{painter_practical_2024}. Aktualisiert wird über den Paketmanager und das von GitLab vorgegebene Versionsschema. Beim Überspringen mehrerer Hauptversionen ist eine bestimmte Reihenfolge zwingend einzuhalten, da die enthaltenen Datenbankmigrationen aufeinander aufbauen. Ein direkter Sprung von einer alten auf eine deutlich neuere Version kann den Datenbestand inkonsistent zurücklassen \cite{gitlab_gitlab_nodate}. Sicherungen werden über den Befehl \texttt{gitlab-backup create} erzeugt und umfassen die \texttt{PostgreSQL}-Datenbank sowie alle Repositories und Artefakte. + + Welche Folgen ein nicht funktionierendes Backup haben kann, zeigt der bereits in Abschnitt~1.3 angesprochene \textit{GitLab.com Database Incident} aus dem Jahr 2017. Durch eine fehlerhafte manuelle Aktion gingen sechs Stunden Nutzerdaten verloren \cite{GitLabcomDatabaseIncident}. Betroffen war zwar die \ac{SaaS}-Instanz, das Beispiel ist aber auch für eine eigene Instanz von Bedeutung. Ein Backup, das nicht regelmässig in einem Restore-Test überprüft wird, ist im Ernstfall kein Backup. Painter~\cite{painter_practical_2024} weist zudem darauf hin, dass die eigentlichen Aufwände bei einer Self-Managed-Instanz nicht in der Erstinstallation, sondern über die Lebensdauer hinweg anfallen. Dazu zählen Sicherheitsaktualisierungen, regelmässige Restore-Tests und die Überwachung der Datenbankkonsistenz. + \section{Evaluierung} \subsection{Vorgehensweise} @@ -300,7 +501,7 @@ \section*{Abkürzungsverzeichnis} \begin{acronym}[Abkürzungsverzeichnis] \acro{IDE}{Integrated Development Environment} - \acro{CD}{Continous Delivery, kontinuierliche Auslieferung} + \acro{CD}{Continuous Delivery, kontinuierliche Auslieferung} \acro{SaaS}{Software as a Service} \acro{CI}{Continuous Integration, kontinuierliche Integration} \acro{NASDAQ}{National Association of Securities Dealers Automated Quotations} @@ -314,6 +515,9 @@ \acro{TFVC}{Team Foundation Version Control (TFVC)} \acro{CVS}{Concurrent Versions System} \acro{OSS}{Open Source Software} + \acro{TLS}{Transport Layer Security} + \acro{DAG}{Directed Acyclic Graph} + \acro{URL}{Uniform Resource Locator} \end{acronym} \printbibliography From 1841988dc9c80ae47f5f5a36455c9ec3231caac8 Mon Sep 17 00:00:00 2001 From: ChrPc Date: Fri, 22 May 2026 11:31:48 +0200 Subject: [PATCH 4/8] followed smits guideline: italic instead of bold, added matrikel number --- DMS_paper15_gitlab.tex | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/DMS_paper15_gitlab.tex b/DMS_paper15_gitlab.tex index 5314c72..61129a5 100644 --- a/DMS_paper15_gitlab.tex +++ b/DMS_paper15_gitlab.tex @@ -66,7 +66,7 @@ \author{ \begin{tabular}{ccc} \textbf{Roman Schöne} & \textbf{Christopher Schmitt}\\ - 2211275 & ???????\\ + 2211275 & 2023467\\ roman.schoene@stud.th-mannheim.de & christopher.schmitt@stud.th-mannheim.de \end{tabular}\\\\ Technische Hochschule Mannheim @@ -209,13 +209,13 @@ \subsection{GitLab Runner} - Die GitLab-Instanz selbst führt keine \ac{CI}/\ac{CD}-Arbeit aus. Diese Aufgabe übernimmt ein separater Hilfsprozess, der \textbf{Runner} \cite{gitlab_gitlab_nodate}. Ein Runner registriert sich einmal mit einem Token bei der Instanz und holt sich danach selbständig offene Aufgaben ab. Durch diese Trennung kann die Ausführung horizontal skaliert werden. Plattformabhängige Aufgaben lassen sich gezielt auf der passenden Hardware ausführen \cite{painter_practical_2024}. Runner können auf drei unterschiedlichen Ebenen registriert werden: + Die GitLab-Instanz selbst führt keine \ac{CI}/\ac{CD}-Arbeit aus. Diese Aufgabe übernimmt ein separater Hilfsprozess, der \emph{Runner} \cite{gitlab_gitlab_nodate}. Ein Runner registriert sich einmal mit einem Token bei der Instanz und holt sich danach selbständig offene Aufgaben ab. Durch diese Trennung kann die Ausführung horizontal skaliert werden. Plattformabhängige Aufgaben lassen sich gezielt auf der passenden Hardware ausführen \cite{painter_practical_2024}. Runner können auf drei unterschiedlichen Ebenen registriert werden: \begin{itemize} - \item \textbf{Instanz} Auf Instanzebene registrierte Runner stehen allen Projekten der GitLab-Instanz zur Verfügung. Sie werden in der Regel von der Administration bereitgestellt. - \item \textbf{Gruppe} Auf Gruppenebene registrierte Runner nehmen Aufgaben aus sämtlichen Projekten innerhalb dieser Gruppe und ihrer Subgruppen an. Eingesetzt werden sie meistens dann, wenn eine Gruppe besondere Anforderungen an Hardware oder Software stellt. - \item \textbf{Projekt} Auf Projektebene registrierte Runner sind ausschliesslich an ein einzelnes Projekt gebunden. Diese Variante eignet sich für sensitive Projekte, bei denen kein gemeinsam genutzter Runner verwendet werden soll. + \item \emph{Instanz} Auf Instanzebene registrierte Runner stehen allen Projekten der GitLab-Instanz zur Verfügung. Sie werden in der Regel von der Administration bereitgestellt. + \item \emph{Gruppe} Auf Gruppenebene registrierte Runner nehmen Aufgaben aus sämtlichen Projekten innerhalb dieser Gruppe und ihrer Subgruppen an. Eingesetzt werden sie meistens dann, wenn eine Gruppe besondere Anforderungen an Hardware oder Software stellt. + \item \emph{Projekt} Auf Projektebene registrierte Runner sind ausschliesslich an ein einzelnes Projekt gebunden. Diese Variante eignet sich für sensitive Projekte, bei denen kein gemeinsam genutzter Runner verwendet werden soll. \end{itemize} - Wie ein Runner eine konkrete Aufgabe ausführt, hängt vom konfigurierten \textbf{Executor} ab. Der Executor entscheidet, in welcher Umgebung das vom Anwender hinterlegte Skript läuft. Tabelle~\ref{tab:executors} listet die in der Praxis am häufigsten verwendeten Executors auf. + Wie ein Runner eine konkrete Aufgabe ausführt, hängt vom konfigurierten \emph{Executor} ab. Der Executor entscheidet, in welcher Umgebung das vom Anwender hinterlegte Skript läuft. Tabelle~\ref{tab:executors} listet die in der Praxis am häufigsten verwendeten Executors auf. \begin{table}[H] \centering \caption{Häufig verwendete Executors des GitLab Runners \cite{gitlab_gitlab_nodate}} @@ -236,13 +236,13 @@ \subsection{Pipelines} - Eine \textbf{Pipeline} ist in GitLab die oberste Ebene der Automatisierung. Sie umfasst sämtliche Schritte, die als Reaktion auf ein Ereignis im Repository ablaufen \cite{gitlab_gitlab_nodate}. Ausgelöst wird eine Pipeline durch unterschiedliche Ereignisse. Dazu gehören ein Push, das Öffnen eines \textbf{Merge Requests}, ein hinterlegter Zeitplan, ein manueller Klick in der Weboberfläche oder das Ende einer anderen Pipeline \cite{cowell_automating_2023}. + Eine \emph{Pipeline} ist in GitLab die oberste Ebene der Automatisierung. Sie umfasst sämtliche Schritte, die als Reaktion auf ein Ereignis im Repository ablaufen \cite{gitlab_gitlab_nodate}. Ausgelöst wird eine Pipeline durch unterschiedliche Ereignisse. Dazu gehören ein Push, das Öffnen eines \emph{Merge Requests}, ein hinterlegter Zeitplan, ein manueller Klick in der Weboberfläche oder das Ende einer anderen Pipeline \cite{cowell_automating_2023}. - Innerhalb einer Pipeline werden die einzelnen Arbeitsschritte zu sogenannten \textbf{Stages} zusammengefasst. Alle Schritte einer Stage laufen parallel und müssen erfolgreich abgeschlossen sein, bevor die nächste Stage beginnt \cite{gitlab_gitlab_nodate}. Eine in der Praxis verbreitete Reihenfolge der Stages ist \texttt{lint}, \texttt{test}, \texttt{build} und \texttt{deploy}. Abbildung~\ref{fig:pipeline-stages} zeigt das Verhältnis von Pipeline, Stages und Jobs. + Innerhalb einer Pipeline werden die einzelnen Arbeitsschritte zu sogenannten \emph{Stages} zusammengefasst. Alle Schritte einer Stage laufen parallel und müssen erfolgreich abgeschlossen sein, bevor die nächste Stage beginnt \cite{gitlab_gitlab_nodate}. Eine in der Praxis verbreitete Reihenfolge der Stages ist \texttt{lint}, \texttt{test}, \texttt{build} und \texttt{deploy}. Abbildung~\ref{fig:pipeline-stages} zeigt das Verhältnis von Pipeline, Stages und Jobs. \input{diagrams/pipeline_stages} - Die gesamte Definition einer Pipeline liegt in einer einzigen Datei. Diese trägt den Namen \texttt{.gitlab-ci.yml} und befindet sich im Wurzelverzeichnis des Repositories \cite{gitlab_gitlab_nodate}. Damit folgt GitLab dem von Humble und Farley~\cite{humble_continuous_2010} eingeführten \textbf{Pipeline-as-Code}-Prinzip. Die Beschreibung des Build- und Auslieferungsprozesses wird wie Anwendungscode versioniert und im Review geprüft. Listing~\ref{lst:gitlabciyml} zeigt einen minimalen Aufbau mit drei Stages. + Die gesamte Definition einer Pipeline liegt in einer einzigen Datei. Diese trägt den Namen \texttt{.gitlab-ci.yml} und befindet sich im Wurzelverzeichnis des Repositories \cite{gitlab_gitlab_nodate}. Damit folgt GitLab dem von Humble und Farley~\cite{humble_continuous_2010} eingeführten \emph{Pipeline-as-Code}-Prinzip. Die Beschreibung des Build- und Auslieferungsprozesses wird wie Anwendungscode versioniert und im Review geprüft. Listing~\ref{lst:gitlabciyml} zeigt einen minimalen Aufbau mit drei Stages. \begin{lstlisting}[language=yaml,caption={Minimaler Aufbau einer .gitlab-ci.yml},label={lst:gitlabciyml}] stages: @@ -273,16 +273,16 @@ deploy-staging: \subsection{Jobs} - Die eigentliche Arbeitseinheit innerhalb einer Pipeline ist der \textbf{Job}. Ein Job führt ein vom Anwender festgelegtes Skript in einer isolierten Umgebung aus und ist genau einer Stage zugeordnet \cite{gitlab_gitlab_nodate}. Jobs derselben Stage sind voneinander unabhängig und werden parallel auf den verfügbaren Runnern ausgeführt. Ob die Pipeline weiterläuft, hängt vom Ergebnis sämtlicher Jobs einer Stage ab. + Die eigentliche Arbeitseinheit innerhalb einer Pipeline ist der \emph{Job}. Ein Job führt ein vom Anwender festgelegtes Skript in einer isolierten Umgebung aus und ist genau einer Stage zugeordnet \cite{gitlab_gitlab_nodate}. Jobs derselben Stage sind voneinander unabhängig und werden parallel auf den verfügbaren Runnern ausgeführt. Ob die Pipeline weiterläuft, hängt vom Ergebnis sämtlicher Jobs einer Stage ab. Mit dem Schlüsselwort \texttt{rules} wird pro Job festgelegt, unter welchen Bedingungen dieser ausgeführt wird. Beispiele sind die Beschränkung auf bestimmte Branches, die Ausführung nur bei Änderungen an bestimmten Dateien oder die Abhängigkeit vom Ergebnis vorheriger Jobs \cite{cowell_automating_2023}. Ein als \texttt{manual} markierter Job läuft erst nach einer expliziten Freigabe über die Weboberfläche. Diese Konstruktion wird häufig für Auslieferungen in produktive Umgebungen genutzt. Während ein Job läuft, entstehen häufig Dateien, die spätere Jobs weiterverarbeiten. Beispiele sind ein gebautes Bundle, ein Container-Image oder ein Testbericht. GitLab unterscheidet dafür zwei Mechanismen mit unterschiedlicher Lebensdauer \cite{gitlab_gitlab_nodate}: \begin{itemize} - \item \textbf{Artefakte} Artefakte sind benannte Ergebnisse eines Jobs. Sie werden nach dem erfolgreichen Abschluss eines Jobs an die GitLab-Instanz hochgeladen, stehen dort zum Download bereit und werden an spätere Jobs der Pipeline weitergegeben. - \item \textbf{Caches} Caches dienen ausschliesslich dazu, wiederholte Ausführungen zu beschleunigen. Typisch ist das Zwischenspeichern heruntergeladener Abhängigkeiten zwischen Pipeline-Läufen. Über Jobgrenzen hinweg ist der Cache nicht garantiert verfügbar. + \item \emph{Artefakte} sind benannte Ergebnisse eines Jobs. Sie werden nach dem erfolgreichen Abschluss eines Jobs an die GitLab-Instanz hochgeladen, stehen dort zum Download bereit und werden an spätere Jobs der Pipeline weitergegeben. + \item \emph{Caches} dienen ausschliesslich dazu, wiederholte Ausführungen zu beschleunigen. Typisch ist das Zwischenspeichern heruntergeladener Abhängigkeiten zwischen Pipeline-Läufen. Über Jobgrenzen hinweg ist der Cache nicht garantiert verfügbar. \end{itemize} - Das Ziel einer Auslieferung wird durch das Konzept der \textbf{Environments} beschrieben \cite{cowell_automating_2023}. Jedes Environment fasst alle Auslieferungen in eine bestimmte Zielumgebung zusammen. In der Weboberfläche wird zusätzlich protokolliert, welche Version dort gerade läuft. Einen Sonderfall bilden \textbf{Review-Apps}. Für jeden offenen Merge Request erzeugt GitLab automatisch eine isolierte, kurzlebige Auslieferung, in der die geänderte Anwendung vor dem Merge begutachtet werden kann \cite{gitlab_gitlab_nodate}. Nach Rostami Mazrae et al.~\cite{rostami_usage_2023} ist diese direkte Kopplung zwischen Review und laufender Vorschau eines der Merkmale, mit denen sich GitLab von alternativen Plattformen abgrenzt. + Das Ziel einer Auslieferung wird durch das Konzept der \emph{Environments} beschrieben \cite{cowell_automating_2023}. Jedes Environment fasst alle Auslieferungen in eine bestimmte Zielumgebung zusammen. In der Weboberfläche wird zusätzlich protokolliert, welche Version dort gerade läuft. Einen Sonderfall bilden \emph{Review-Apps}. Für jeden offenen Merge Request erzeugt GitLab automatisch eine isolierte, kurzlebige Auslieferung, in der die geänderte Anwendung vor dem Merge begutachtet werden kann \cite{gitlab_gitlab_nodate}. Nach Rostami Mazrae et al.~\cite{rostami_usage_2023} ist diese direkte Kopplung zwischen Review und laufender Vorschau eines der Merkmale, mit denen sich GitLab von alternativen Plattformen abgrenzt. Zampetti et al.~\cite{zampetti_empirical_2020} identifizieren in einer empirischen Untersuchung 79 wiederkehrende Anti-Muster in CI-Konfigurationen. Häufige Probleme sind unnötig sequentielle Stages, zu grobgranulare Jobs und das Vermischen von Cache und Artefakten. Lesbarkeit und Wartbarkeit der Pipeline-Definition sind damit ein eigenes Qualitätskriterium. @@ -290,11 +290,11 @@ deploy-staging: Mit dem Schlüsselwort \texttt{include} können bereits seit längerem ganze Pipeline-Fragmente aus anderen Repositories oder von einer entfernten \ac{URL} eingebunden werden \cite{gitlab_gitlab_nodate}. In der Praxis stellen sich dabei zwei wiederkehrende Probleme. Eingebundene Fragmente sind in den meisten Fällen weder versioniert noch besitzen sie eine eigene Schnittstelle. Eine Änderung am Fragment kann sämtliche Pipelines mit einbinden \cite{cowell_automating_2023}. - Seit GitLab 16.0 lösen \textbf{CI/CD-Komponenten} dieses Problem. Eine Komponente ist ein versionierter und parametrisierbarer Pipeline-Baustein, der ähnlich wie eine Software-Bibliothek verwendet wird \cite{gitlab_gitlab_nodate}. Komponenten werden in einem dedizierten Projekt entwickelt und veröffentlicht. Drei Bestandteile sind dabei zwingend vorgesehen: + Seit GitLab 16.0 lösen \emph{CI/CD-Komponenten} dieses Problem. Eine Komponente ist ein versionierter und parametrisierbarer Pipeline-Baustein, der ähnlich wie eine Software-Bibliothek verwendet wird \cite{gitlab_gitlab_nodate}. Komponenten werden in einem dedizierten Projekt entwickelt und veröffentlicht. Drei Bestandteile sind dabei zwingend vorgesehen: \begin{itemize} - \item \textbf{Manifest} In einer Datei \texttt{template.yml} beschreibt die Komponente ihre Eingabeparameter mit Datentyp und Defaultwert sowie die von ihr beigesteuerten Jobs. - \item \textbf{Versionsschild} Komponenten werden ausschliesslich über Git-Tags freigegeben. Ein Konsument referenziert eine Komponente immer mit einer konkreten Version. Damit kann sich der eingebundene Stand nicht unter dem Konsumenten verändern. - \item \textbf{Katalogeintrag} Ein Projekt, das den Status \textit{Components Project} erhält, erscheint im zentralen \textbf{Component Catalog} der GitLab-Instanz. Die Suche nach geeigneten Komponenten erfolgt dort, ohne dass Repository-Pfade auswendig bekannt sein müssen. + \item \emph{Manifest} In einer Datei \texttt{template.yml} beschreibt die Komponente ihre Eingabeparameter mit Datentyp und Defaultwert sowie die von ihr beigesteuerten Jobs. + \item \emph{Versionsschild} Komponenten werden ausschliesslich über Git-Tags freigegeben. Ein Konsument referenziert eine Komponente immer mit einer konkreten Version. Damit kann sich der eingebundene Stand nicht unter dem Konsumenten verändern. + \item \emph{Katalogeintrag} Ein Projekt, das den Status \textit{Components Project} erhält, erscheint im zentralen \emph{Component Catalog} der GitLab-Instanz. Die Suche nach geeigneten Komponenten erfolgt dort, ohne dass Repository-Pfade auswendig bekannt sein müssen. \end{itemize} Listing~\ref{lst:component} zeigt die Einbindung einer beispielhaften Lint-Komponente in eine bestehende Pipeline. @@ -316,7 +316,7 @@ stages: Zur praktischen Demonstration der vorhergehenden Konzepte wurde eine kleine Webanwendung auf der in Abschnitt~\ref{sec:selfhosted} beschriebenen selbstgehosteten Instanz aufgesetzt. Die Anwendung ist bewusst minimal gehalten. So liegt der Fokus auf der \ac{CI}/\ac{CD}-Konfiguration und nicht auf dem Anwendungscode. - Die Demoanwendung ist ein \texttt{HTTP}-Dienst, der in \textbf{Node.js} mit dem Web-Framework \textbf{Express} geschrieben ist. Bereitgestellt wird ein einzelner Endpunkt \texttt{GET /}, der eine kurze HTML-Seite mit der Bezeichnung der aktuellen Umgebung und der im Build verbauten Versionskennung ausliefert. Beide Werte werden zur Laufzeit über Umgebungsvariablen aus dem Container gelesen und im jeweiligen Deploy-Job gesetzt. Eine kleine Testsuite mit dem Framework \texttt{vitest} prüft, dass der Endpunkt eine HTML-Antwort mit Statuscode~200 und der erwarteten Versionsangabe liefert. + Die Demoanwendung ist ein \texttt{HTTP}-Dienst, der in \emph{Node.js} mit dem Web-Framework \emph{Express} geschrieben ist. Bereitgestellt wird ein einzelner Endpunkt \texttt{GET /}, der eine kurze HTML-Seite mit der Bezeichnung der aktuellen Umgebung und der im Build verbauten Versionskennung ausliefert. Beide Werte werden zur Laufzeit über Umgebungsvariablen aus dem Container gelesen und im jeweiligen Deploy-Job gesetzt. Eine kleine Testsuite mit dem Framework \texttt{vitest} prüft, dass der Endpunkt eine HTML-Antwort mit Statuscode~200 und der erwarteten Versionsangabe liefert. Die zugehörige \texttt{.gitlab-ci.yml} definiert drei Stages: \texttt{lint}, \texttt{test} und \texttt{deploy}. Die Stage \texttt{deploy} enthält dabei zwei Jobs, die sich gegenseitig ausschliessen. Tabelle~\ref{tab:demo-pipeline} fasst zusammen, welcher Schritt unter welchen Bedingungen ausgeführt wird und welches Environment er bedient. \begin{table}[H] @@ -341,11 +341,11 @@ stages: \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 \textbf{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. + 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. \subsection{Installation} - Für die selbstgehostete \ac{CE} bietet GitLab das sogenannte \textbf{Omnibus-Paket} an \cite{painter_practical_2024}. Im Paket enthalten sind sämtliche Komponenten, die GitLab im Betrieb benötigt. Dazu zählen der Webserver \texttt{nginx}, der Anwendungsserver \texttt{Puma}, die relationale Datenbank \texttt{PostgreSQL} und der Schlüssel-Wert-Speicher \texttt{Redis}. Weitere Hintergrundprozesse kommen hinzu \cite{gitlab_gitlab_nodate}. Abbildung~\ref{fig:omnibus-arch} zeigt das Zusammenspiel der einzelnen Bausteine. + Für die selbstgehostete \ac{CE} bietet GitLab das sogenannte \emph{Omnibus-Paket} an \cite{painter_practical_2024}. Im Paket enthalten sind sämtliche Komponenten, die GitLab im Betrieb benötigt. Dazu zählen der Webserver \texttt{nginx}, der Anwendungsserver \texttt{Puma}, die relationale Datenbank \texttt{PostgreSQL} und der Schlüssel-Wert-Speicher \texttt{Redis}. Weitere Hintergrundprozesse kommen hinzu \cite{gitlab_gitlab_nodate}. Abbildung~\ref{fig:omnibus-arch} zeigt das Zusammenspiel der einzelnen Bausteine. \input{diagrams/omnibus_arch} From 924a1a9927a8759217aee94292fb3c7ab7fafeea Mon Sep 17 00:00:00 2001 From: ChrPc Date: Fri, 22 May 2026 20:14:19 +0200 Subject: [PATCH 5/8] 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} From ea222361a9c6456846be27313bbc2695e79a4e2b Mon Sep 17 00:00:00 2001 From: 2211275 <2211275@stud.hs-mannheim.de> Date: Sun, 7 Jun 2026 22:31:46 +0200 Subject: [PATCH 6/8] added application security seetings --- DMS_paper15_gitlab.tex | 18 +- literatur/dms.bib | 462 ++++++++++++++++++++++------------------- 2 files changed, 260 insertions(+), 220 deletions(-) diff --git a/DMS_paper15_gitlab.tex b/DMS_paper15_gitlab.tex index 8275b63..f53e181 100644 --- a/DMS_paper15_gitlab.tex +++ b/DMS_paper15_gitlab.tex @@ -202,8 +202,8 @@ 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}. Aufgrund der grösseren Nutzerbasis eignet sich GitHub mehr für eine kollaborative Zusammenarbeit an \ac{OSS}. Ein Projekt erreicht mehr Nutzer, die potenziell beitragen können. GitLab und GitHub teilen sich neben demselben Namenspräfix, ähnliche Mechanismen \cite{gitlab_gitlab_nodate}.\\\\ - \ac{CI}/\ac{CD} ist für jeweils beide Plattformen erhältlich. Unter GitHub bieten \textit{GitHub Actions} die Möglichkeit Build-, Test- und Deploymentprozesse zu automatisieren. In GitHub sind diese Abläufe in Form von \textit{Workflows} organisiert. Ein \textit{Workflow} wird durch ein Ereignis ausgelöst. Ein \textit{Workflow} ist in \textit{Jobs} aufgegliedert. \textit{Jobs} beinhalten Anweisungen bspw. in Form von Kommandozeilenskripts, die sequentiell ausgeführt werden. Eine \textit{Action} beschreibt eine Menge an wiederverwendbaren \textit{Jobs}. \textit{Workflows} werden auf einem Server bzw. einem \textit{Runner} ausgeführt. Für GitHub ist auch das eigene Hosten eines \textit{Runners} möglich. Die Verwendung von eigens gehosteten Runnern, sowie der von GitHub bereitgestellten Runnern ist für öffentliche Repositories kostenlos. Für private Repositories existiert ein Zeitbudget.\\\\ - Beide Plattformen bieten KI-Assistenten an. Für GitHub existiert \textit{GitHub Copilot} und für GitLab \textit{GitLab Duo Agent}. Aktuell kann \textit{GitHub Copilot} mit einem eingeschränkten Zugriff auf Funktionalitäten, kostenlos verwendet werden. Im Gegensatz ist aktuell eine kostenfreie Nutzung von \textit{GitLab Duo Agent} nicht möglich. Copilot beschränkt sich auf alle Artefakte, die in einem Code-Repository liegen. \textit{GitLab Duo Agent} besitzt einen größeren Kontext, zu dem zusätzlich Dokumentation, Planung und Sicherheit gehören. Aufgrund der Aneignung von \textit{Visual Studio Code} durch Microsoft ist \textit{GitHub Copilot} nativ enthalten. Eine Unterstützung für \textit{GitLab Duo Agent} muss über die offizielle \href{https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow}{Erweiterung} ergänzt werden. Interaktionen mit \textit{GitHub Copilot} werden standardmässig von GitHub zum trainieren und verbessern von KI-Modellen verwendet. UM eine Weiterverarbeitung der Daten zu verhindern muss manuell widersprochen werden. Für beide KI-Assistenten kann das unterliegende Modell variiert werden.\\\\ + \ac{CI}/\ac{CD} ist für jeweils beide Plattformen erhältlich. Unter GitHub bieten \textit{GitHub Actions} die Möglichkeit Build-, Test- und Deploymentprozesse zu automatisieren. In GitHub sind diese Abläufe in Form von \textit{Workflows} organisiert. Ein \textit{Workflow} wird durch ein Ereignis ausgelöst. Ein \textit{Workflow} ist in \textit{Jobs} aufgegliedert. \textit{Jobs} beinhalten Anweisungen bspw. in Form von Kommandozeilenskripts, die sequentiell ausgeführt werden. Eine \textit{Action} beschreibt eine Menge an wiederverwendbaren \textit{Jobs}. \textit{Workflows} werden auf einem Server bzw. einem \textit{Runner} ausgeführt. Für GitHub ist auch das eigene Hosten eines \textit{Runners} möglich. Die Verwendung von eigens gehosteten Runnern, sowie der von GitHub bereitgestellten Runnern ist für öffentliche Repositories kostenlos. Für private Repositories existiert ein Zeitbudget. \cite{GitHubcomHelpDocumentation} \cite{gitlab_gitlab_nodate}\\\\ + Beide Plattformen bieten KI-Assistenten an. Für GitHub existiert \textit{GitHub Copilot} und für GitLab \textit{GitLab Duo Agent}. Aktuell kann \textit{GitHub Copilot} mit einem eingeschränkten Zugriff auf Funktionalitäten, kostenlos verwendet werden. Im Gegensatz ist aktuell eine kostenfreie Nutzung von \textit{GitLab Duo Agent} nicht möglich. Copilot beschränkt sich auf alle Artefakte, die in einem Code-Repository liegen. \textit{GitLab Duo Agent} besitzt einen größeren Kontext, zu dem zusätzlich Dokumentation, Planung und Sicherheit gehören. Aufgrund der Aneignung von \textit{Visual Studio Code} durch Microsoft ist \textit{GitHub Copilot} nativ enthalten. Eine Unterstützung für \textit{GitLab Duo Agent} muss über die offizielle \href{https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow}{Erweiterung} ergänzt werden. Interaktionen mit \textit{GitHub Copilot} werden standardmässig von GitHub zum trainieren und verbessern von KI-Modellen verwendet. UM eine Weiterverarbeitung der Daten zu verhindern muss manuell widersprochen werden. Für beide KI-Assistenten kann das unterliegende Modell variiert werden. \cite{GitHubcomHelpDocumentation} \cite{gitlab_gitlab_nodate}\\\\ 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} @@ -404,6 +404,16 @@ stages: \subsection{Sicherheit} + 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} + \item Anwendungseinstellungen + \item \acs{CI}/\acs{CD} Einstellungen + \item Konfigurationseinstellungen + \item Betriebssystemeinstellungen + \end{itemize} + Innerhalb der Anwendungseinstellungen können Push-Regeln festgelegt werden, sodass unverifizierte Nutzer keinen Code hochladen können. Es kann sichergestellt werden, dass geheime Dateien nicht versehentlich gepusht werden. Ebenso sollen projektspezifische Keys/Schlüssel für Deployment-Prozesse eingerichtet werden. Die Sichtbarkeit von Gruppen, Snippets und Projekten soll als \textit{privat} gesetzt werden. Benutzer können gezwungen werden komplexere Passwörter für ihren GitLab Account zu wählen. Eine 2-Faktor Authentifizierung kann eingerichtet werden. Die Kommunikation mit aussenstehenden Systemen kann konkret festgelegt werden, indem externe Systeme zuerst anhand ihrer IP-Adresse für ausgehende anfragen in GitLab eingetragen werden müssen. Für die GitLab-Instanz kann ein Rate-Limit, mit Ausnahmen für bestimmte Nutzer, eingestellt werden \cite{gitlab_gitlab_nodate}. + \subsection{Kompatibilität} 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. @@ -522,6 +532,10 @@ stages: \acro{TLS}{Transport Layer Security} \acro{DAG}{Directed Acyclic Graph} \acro{URL}{Uniform Resource Locator} + \acro{SP}{Special Publication} + \acro{NIST}{National Institute of Standards and Technology} + \acro{ISO}{Internationale Organisation für Normung} + \acro{IEC}{International Electrotechnical Commission} \end{acronym} \printbibliography diff --git a/literatur/dms.bib b/literatur/dms.bib index b7c1fd2..496eb95 100644 --- a/literatur/dms.bib +++ b/literatur/dms.bib @@ -2,9 +2,8 @@ title = {2025 {{Stack Overflow Developer Survey}}}, urldate = {2026-04-18}, abstract = {The 2025 Developer Survey is the definitive report on the state of software development. In its fifteenth year, Stack Overflow received over 49,000+ responses from 177 countries across 62 questions focused on 314 different technologies, including new focus on AI agent tools, LLMs and community platforms. This annual Developer Survey provides a crucial snapshot into the needs of the global developer community, focusing on the tools and technologies they use or want to learn more about.}, - howpublished = {https://survey.stackoverflow.co/2025/}, langid = {english}, - file = {C:\Users\Roman\Zotero\storage\VL48NTTS\2025.html} + file = {C:\Users\Roman\Zotero\storage\29SDLBQ5\2025.html} } @article{arefeen_continuous_2019, @@ -23,8 +22,19 @@ keywords = {agile,continuous integration,GitLab,software testing} } +@book{bass_devops_2015, + title = {{{DevOps}}: A Software Architect's Perspective}, + shorttitle = {{{DevOps}}}, + author = {Bass, Len and Weber, Ingo and Zhu, Liming}, + year = 2015, + series = {{{SEI}} Series in Software Engineering}, + publisher = {Addison-Wesley Professional}, + address = {Upper Saddle River, NJ}, + isbn = {978-0-13-404984-7} +} + @article{choudhuryGitLabWorkWhere2020, - title = {{{GitLab}}: Work Where You Want, When You Want}, + title = {{{GitLab}}: {{Work}} Where You Want, When You Want}, shorttitle = {{{GitLab}}}, author = {Choudhury, Prithwiraj and Crowston, Kevin and Dahlander, Linus and Minervini, Marco S. and Raghuram, Sumita}, year = 2020, @@ -39,7 +49,18 @@ abstract = {GitLab is a software company that works ``all remote'' at the scale of more than 1000 employees located in more than 60 countries. GitLab has no physical office and its employees can work from anywhere they choose. Any step of the organizational life of a GitLab employee (e.g., hiring, onboarding and firing) is performed remotely, except for a yearly companywide gathering. GitLab strongly relies on asynchronous coordination, allowing employees to work anytime they want. After highlighting some of the main practices implemented by GitLab to effectively work all remotely and asynchronously, I asked renowned organizational scientists their thoughts on this interesting case and to question the generalizability of the all remote asynchronous model. Understanding whether and under what conditions this model can succeed can be of guidance for organizational designers that are now considering different remote models in response of the COVID-19 shock and its aftermath.}, langid = {english}, keywords = {All remote,COVID-19,New forms of organizing,Organizational design,Remote work,Virtual organizations}, - file = {C:\Users\Roman\Zotero\storage\IT677T3E\Choudhury et al. - 2020 - GitLab work where you want, when you want.pdf} + file = {C:\Users\Roman\Zotero\storage\HUKLD34S\Choudhury et al. - 2020 - GitLab work where you want, when you want.pdf} +} + +@book{cowell_automating_2023, + title = {Automating {{DevOps}} with {{GitLab CI}}/{{CD Pipelines}}: {{Build}} Efficient {{CI}}/{{CD}} Pipelines to Verify, Secure, and Deploy Your Code Using Real-Life Examples}, + shorttitle = {Automating {{DevOps}} with {{GitLab CI}}/{{CD}} Pipelines}, + author = {Cowell, Christopher and Lotz, Nicholas and Timberlake, Chris}, + year = 2023, + pages = {348}, + publisher = {Packt Publishing}, + address = {Birmingham}, + isbn = {978-1-80323-300-0} } @misc{degeler_gitlab_2014, @@ -52,6 +73,18 @@ langid = {english} } +@book{duvall_continuous_2007, + title = {Continuous Integration: {{Improving}} Software Quality and Reducing Risk}, + shorttitle = {Continuous Integration}, + author = {Duvall, Paul M. and Matyas, Steve and Glover, Andrew}, + year = 2007, + series = {Addison-Wesley Signature Series (Fowler)}, + pages = {336}, + publisher = {Addison-Wesley}, + address = {Upper Saddle River, NJ}, + isbn = {978-0-321-33638-5} +} + @inproceedings{fairbanksAnalyzingEffectsCI2023, title = {Analyzing the {{Effects}} of {{CI}}/{{CD}} on {{Open Source Repositories}} in {{GitHub}} and {{GitLab}}}, booktitle = {2023 {{IEEE}}/{{ACIS}} 21st {{International Conference}} on {{Software Engineering Research}}, {{Management}} and {{Applications}} ({{SERA}})}, @@ -64,27 +97,53 @@ urldate = {2026-04-17}, abstract = {Numerous articles emphasize the benefits of implementing Continuous Integration and Delivery (CI/CD) pipelines in software development. These pipelines are expected to improve a project's reputation and decrease the number of commits and issues in the repository. Although CI/CD adoption may be slow initially, it is believed to accelerate service delivery and deployment in the long run. This study aims to investigate the impact of CI/CD on commit velocity and issue counts in two open-source repositories, GitLab and GitHub. By analyzing more than 12,000 repositories and recording every commit and issue, it was discovered that CI/CD enhances commit velocity by 141.19\% but also increases the number of issues by 321.21\%.}, keywords = {CI/CD,Codes,Mining Repositories,Open-Source Software,Pipelines,Recording,Software,Software development management,Software engineering,Software Engineering}, - file = {C:\Users\Roman\Zotero\storage\EW4K6L72\Fairbanks et al. - 2023 - Analyzing the Effects of CICD on Open Source Repositories in GitHub and GitLab.pdf} + file = {C:\Users\Roman\Zotero\storage\ZVGXIL24\Fairbanks et al. - 2023 - Analyzing the Effects of CICD on Open Source Repositories in GitHub and GitLab.pdf} +} + +@book{forsgren_accelerate_2018, + title = {Accelerate: {{The}} Science of Lean Software and {{DevOps}}. {{Building}} and Scaling High Performing Technology Organizations}, + shorttitle = {Accelerate}, + author = {Forsgren, Nicole and Humble, Jez and Kim, Gene}, + year = 2018, + publisher = {IT Revolution Press}, + address = {Portland, OR}, + isbn = {978-1-942788-33-1} +} + +@misc{fowler_continuous_2006, + title = {Continuous Integration}, + author = {Fowler, Martin}, + year = 2006, + month = may, + urldate = {2026-05-04}, + howpublished = {martinfowler.com} +} + +@misc{GitHubcomHelpDocumentation, + title = {{{GitHub}}.Com {{Help Documentation}}}, + journal = {GitHub Docs}, + urldate = {2026-06-07}, + abstract = {Get started, troubleshoot, and make the most of GitHub. Documentation for new users, developers, administrators, and all of GitHub's products.}, + howpublished = {https://docs-internal.github.com/en}, + langid = {english}, + file = {C:\Users\Roman\Zotero\storage\CBUZVQLS\en.html} } @misc{GitHubInnovationGraph, title = {{{GitHub Innovation Graph}}}, urldate = {2026-05-19}, abstract = {Explore a universe of data about how the world is building software together on GitHub.}, - howpublished = {https://innovationgraph.github.com}, langid = {english}, - file = {C:\Users\Roman\Zotero\storage\FIN8TZSR\innovationgraph.github.com.html} + file = {C:\Users\Roman\Zotero\storage\EBU9LPUD\innovationgraph.github.com.html} } @misc{gitlab_about, title = {About {{Gitlab}}}, - author = {Gitlab}, - journal = {about.gitlab.com}, + author = {{Gitlab}}, urldate = {2026-04-17}, abstract = {Your intelligent orchestration platform for DevSecOps}, - howpublished = {https://about.gitlab.com/}, langid = {american}, - file = {C:\Users\Roman\Zotero\storage\T886BE4A\about.gitlab.com.html} + file = {C:\Users\Roman\Zotero\storage\KG655MR3\about.gitlab.com.html} } @misc{gitlab_gitlab_nodate, @@ -93,14 +152,81 @@ urldate = {2026-04-16} } +@misc{gitlab_s1_2021, + title = {Form {{S-1}} Registration Statement}, + author = {{GitLab Inc.}}, + year = 2021, + month = sep, + urldate = {2026-05-04}, + howpublished = {U.S. Securities and Exchange Commission, EDGAR Filing System} +} + +@misc{GitLab16522166, + title = {{{GitLab}} 1652216-6}, + urldate = {2026-06-07}, + howpublished = {https://certificate-directory-v2-9z7a0xjllzon1iz8.s3.amazonaws.com/14921/GitLab\%201652216-6.pdf?X-Amz-Security-Token=IQoJb3JpZ2luX2VjENr\%2F\%2F\%2F\%2F\%2F\%2F\%2F\%2F\%2F\%2FwEaCXVzLWVhc3QtMSJHMEUCIAzg2qbnPWjF8ANiP85mhwOssqnFk9NRY4FZSgSwUBFQAiEA0y0GOUV6dDKowIVpqPJWBeGMdqtJlOcSbeOa0DyiAdcqhgQIo\%2F\%2F\%2F\%2F\%2F\%2F\%2F\%2F\%2F\%2F\%2FARAAGgw4MzU4NTczNjE3NDAiDKUVvC\%2FRBunDtasKzSraA7HJRbCduWk09yPpaUUglYHlfaN0\%2B0nGdnBT6q2OcFf1C7d\%2F5A8Z7Ogtcnyu3Hs4UyxFq8tkBj7mt52NlqnHGXG2SX31PNa7kN9tYNbpS\%2BM\%2Fpf2yGGC3yEeNfJYZn4ZL9q\%2FDXMpetx\%2B8cQt3Umt3VSvr\%2Fb\%2FXbYZokMQS\%2BJ7\%2F1HN39\%2BHJaYQP6RqSVpHQvFnp\%2F17od3vQaJRGteA7\%2Fao\%2FnYH2eeqNpvdYSDpo3mValWYrQdT4xaPFFcIAQB3CEiyo4SgtxyXLhyJwtXLhXpb4Y7VsdT4y72IC5hD0Y57fE7HiPSJYiefi4keRQpH9Ia\%2Bp\%2BhbvwdnCHhpmiQEinu4ZsrC5s0ebGV\%2FszfWQIYhr6BPt8QgoUhjwvvZAdqSoykwoTdUQ2UAoN0wgfDH2dmaYJCKB6I7FmSOpW2\%2Fbl5iLe35pAmTbB9aWMIUHoK3Ld1U\%2FmARNxUWSC1fQR\%2Bp3s4QDbBf7mk2BlyhdtVPBWlyNLGHX\%2BSLDt9ZkqVpYCNeh2uNxam0weP\%2F5gDIYP1yplLkvCIY2j6NZMfV\%2FRAMCDU\%2Fb0hUX6uBA2nwcuo7ZnuM1YDimdyPDG9hXexUygAJ8pJgEJRp00n6nPPL\%2F9uAinVoO4bqWy7\%2Fk87oMasJ1hDD\%2F3ZbRBjqlARwki9a6twsl5UVDOnOk\%2BwV3FkfNcYOtHRRzhQSHXeUzg8bFUGaAdTQz6a08ugI\%2FJPHz1MCIlFHSrMijL\%2BTacILY8TVeEaA9DdiJXGks\%2FjC\%2B6KArZIjEHPDel80HrGFwi99p\%2Fssdba1eWw9XrVEAyJKvkCX2PGI663\%2BmpmfS1vgHH12l5QI9LJGSsvJdYA3AB15FycyJSx5jVAywgWK7EOQEBWhH2g\%3D\%3D\&X-Amz-Algorithm=AWS4-HMAC-SHA256\&X-Amz-Date=20260607T195034Z\&X-Amz-SignedHeaders=host\&X-Amz-Credential=ASIA4FHH3FNGHFS3J34L\%2F20260607\%2Fus-east-1\%2Fs3\%2Faws4\_request\&X-Amz-Expires=900\&X-Amz-Signature=fab520a96bdce151deb3dc36a7bde5bd42c32105ff15fe58dee07bc5f542679d}, + file = {C:\Users\Roman\Zotero\storage\XSV4JT3D\GitLab 1652216-6.pdf} +} + @misc{GitLabcomDatabaseIncident, title = {{{GitLab}}.Com Database Incident}, - journal = {about.gitlab.com}, urldate = {2026-04-17}, abstract = {Yesterday we had a serious incident with one of our databases. We lost six hours of database data (issues, merge requests, users, comments, snippets, etc.) for GitLab.com.}, - howpublished = {https://about.gitlab.com/blog/gitlab-dot-com-database-incident/}, langid = {american}, - file = {C:\Users\Roman\Zotero\storage\LBYJ7RZX\gitlab-dot-com-database-incident.html} + file = {C:\Users\Roman\Zotero\storage\PIAEFUHX\gitlab-dot-com-database-incident.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)}, + author = {Golzadeh, Mehdi and Decan, Alexandre and Mens, Tom}, + year = 2022, + pages = {662--672}, + address = {Honolulu, HI}, + doi = {10.1109/SANER53432.2022.00084} +} + +@inproceedings{hilton_usage_2016, + title = {Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects}, + booktitle = {Proceedings of the 31st {{IEEE}}/{{ACM}} International Conference on Automated Software Engineering ({{ASE}} 2016)}, + author = {Hilton, Michael and Tunnell, Timothy and Huang, Kai and Marinov, Darko and Dig, Danny}, + year = 2016, + pages = {426--437}, + address = {Singapore}, + doi = {10.1145/2970276.2970358} +} + +@misc{HowGitLabCan, + title = {How {{GitLab}} Can Support Your {{ISO}} 27001 Compliance Journey}, + journal = {GitLab}, + urldate = {2026-06-07}, + abstract = {As a strategic partner, GitLab's software security features can help support your ISO 27001 compliance.}, + howpublished = {https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey/}, + langid = {american}, + file = {C:\Users\Roman\Zotero\storage\ITFPQ5DP\how-gitlab-can-support-your-iso-compliance-journey.html} +} + +@book{humble_continuous_2010, + title = {Continuous Delivery: {{Reliable}} Software Releases through Build, Test, and Deployment Automation}, + shorttitle = {Continuous Delivery}, + author = {Humble, Jez and Farley, David}, + year = 2010, + series = {Addison-Wesley Signature Series (Fowler)}, + pages = {512}, + publisher = {Addison-Wesley Professional}, + address = {Boston, MA}, + isbn = {978-0-321-60191-9} +} + +@misc{ISOIEC27017, + title = {{{ISO}}/{{IEC}} 27017:2015}, + shorttitle = {{{ISO}}/{{IEC}} 27017}, + journal = {ISO}, + urldate = {2026-06-07}, + abstract = {Information technology --- Security techniques --- Code of practice for information security controls based on ISO/IEC 27002 for cloud services}, + howpublished = {https://www.iso.org/standard/43757.html}, + langid = {english}, + file = {C:\Users\Roman\Zotero\storage\GHQLR68Z\43757.html} } @misc{jrHowThis33yearold2018, @@ -108,13 +234,34 @@ author = {Jr, Tom Huddleston}, year = 2018, month = jun, - journal = {CNBC}, urldate = {2026-05-19}, abstract = {Chris Wanstrath co-founded GitHub in 2008, three years after dropping out of college.}, chapter = {Make It - Entrepreneurs}, - howpublished = {https://www.cnbc.com/2018/06/04/chris-wanstrath-co-founded-github-which-microsoft-bought-for-billions.html}, langid = {english}, - file = {C:\Users\Roman\Zotero\storage\MMCY9JZL\chris-wanstrath-co-founded-github-which-microsoft-bought-for-billions.html} + file = {C:\Users\Roman\Zotero\storage\KMZMLM2U\chris-wanstrath-co-founded-github-which-microsoft-bought-for-billions.html} +} + +@book{kim_devops_2022, + title = {Das {{DevOps-Handbuch}}: {{Teams}}, Tools Und Infrastrukturen Erfolgreich Umgestalten}, + shorttitle = {Das {{DevOps-Handbuch}}}, + author = {Kim, Gene and Humble, Jez and Debois, Patrick and Willis, John and Forsgren, Nicole}, + year = 2022, + edition = {2., aktualisierte und erweiterte Auflage}, + pages = {520}, + publisher = {O'Reilly / dpunkt.verlag}, + address = {Heidelberg}, + isbn = {978-3-96009-199-8} +} + +@book{newman_building_2021, + title = {Building Microservices: {{Designing}} Fine-Grained Systems}, + shorttitle = {Building Microservices}, + author = {Newman, Sam}, + year = 2021, + edition = {2}, + publisher = {O'Reilly Media}, + address = {Sebastopol, CA}, + isbn = {978-1-4920-3402-5} } @misc{onlineGitHubVsGitLab2024, @@ -122,12 +269,10 @@ author = {{online}, heise}, year = 2024, month = feb, - journal = {Tipps-Tricks}, urldate = {2026-05-19}, abstract = {GitHub und GitLab klingen \"ahnlich und sie bieten \"Ahnliches: Source Code Management und Hosting auf git-Basis. Wo liegen die Unterschiede?}, - howpublished = {https://www.heise.de/tipps-tricks/GitHub-vs-GitLab-4597154.html}, langid = {ngerman}, - file = {C:\Users\Roman\Zotero\storage\AKG9RL5W\GitHub-vs-GitLab-4597154.html} + file = {C:\Users\Roman\Zotero\storage\EQGIJ525\GitHub-vs-GitLab-4597154.html} } @misc{onlineMicrosoftKauftGitHub2018, @@ -135,12 +280,10 @@ author = {{online}, heise}, year = 2018, month = jun, - journal = {heise online}, urldate = {2026-05-19}, abstract = {Was sich bereits angedeutet hat, wurde nun best\"atigt: Der US-amerikanische Softwarekonzern Microsoft kauft GitHub und legt daf\"ur stolze 7,5 Milliarden US-Dollar auf den Tisch.}, - howpublished = {https://www.heise.de/news/Microsoft-kauft-GitHub-fuer-7-5-Milliarden-US-Dollar-4067633.html}, langid = {ngerman}, - file = {C:\Users\Roman\Zotero\storage\Z7KBN2TI\Microsoft-kauft-GitHub-fuer-7-5-Milliarden-US-Dollar-4067633.html} + file = {C:\Users\Roman\Zotero\storage\VIM5UJ9L\Microsoft-kauft-GitHub-fuer-7-5-Milliarden-US-Dollar-4067633.html} } @misc{onlineVersionsverwaltungGitLabRudert2022, @@ -149,224 +292,107 @@ author = {{online}, heise}, year = 2022, month = aug, - journal = {Developer}, urldate = {2026-04-17}, abstract = {Die Pl\"ane, brach liegende Repositories komplett zu l\"oschen, sind laut einem Tweet von GitLab vorerst auf Eis gelegt. Stattdessen sollen sie archiviert werden.}, - howpublished = {https://www.heise.de/news/Versionsverwaltung-GitLab-rudert-beim-Loeschen-inaktiver-Repositories-zurueck-7203006.html}, langid = {ngerman}, - file = {C:\Users\Roman\Zotero\storage\3N8Y75DY\Versionsverwaltung-GitLab-rudert-beim-Loeschen-inaktiver-Repositories-zurueck-7203006.html} + file = {C:\Users\Roman\Zotero\storage\C88PQIJJ\Versionsverwaltung-GitLab-rudert-beim-Loeschen-inaktiver-Repositories-zurueck-7203006.html} +} + +@book{painter_practical_2024, + title = {Practical {{GitLab}} Services: A Complete {{DevOps}} Guide for Developers and Administrators}, + shorttitle = {Practical {{GitLab}} Services}, + author = {Painter, Jeffrey}, + year = 2024, + pages = {905}, + publisher = {Apress (Springer Nature)}, + address = {Berkeley, CA}, + doi = {10.1007/979-8-8688-0427-4}, + isbn = {979-8-8688-0426-7} } @misc{Q4FY2026GitLab, title = {Q4 {{FY2026 GitLab Overview Investor Presentation}} - {{Q4-FY2026-GitLab-Overview-Investor-Presentation}}.Pdf}, urldate = {2026-05-19}, - howpublished = {https://ir.gitlab.com/js/pdf-js/web/viewer.html?file=https://s204.q4cdn.com/984476563/files/doc\_financials/2026/q4/Q4-FY2026-GitLab-Overview-Investor-Presentation.pdf}, - file = {C:\Users\Roman\Zotero\storage\SHDE2M4E\viewer.html} + file = {C:\Users\Roman\Zotero\storage\ET483VJP\viewer.html} } -@book{humble_continuous_2010, - title = {Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation}, - shorttitle = {Continuous Delivery}, - author = {Humble, Jez and Farley, David}, - year = {2010}, - publisher = {Addison-Wesley Professional}, - address = {Boston, MA}, - series = {Addison-Wesley Signature Series (Fowler)}, - isbn = {978-0-321-60191-9}, - pages = {512}, -} - -@book{duvall_continuous_2007, - title = {Continuous Integration: Improving Software Quality and Reducing Risk}, - shorttitle = {Continuous Integration}, - author = {Duvall, Paul M. and Matyas, Steve and Glover, Andrew}, - year = {2007}, - publisher = {Addison-Wesley}, - address = {Upper Saddle River, NJ}, - series = {Addison-Wesley Signature Series (Fowler)}, - isbn = {978-0-321-33638-5}, - pages = {336}, -} - -@misc{fowler_continuous_2006, - title = {Continuous Integration}, - author = {Fowler, Martin}, - year = {2006}, - month = may, - howpublished = {martinfowler.com}, - url = {https://martinfowler.com/articles/continuousIntegration.html}, - urldate = {2026-05-04}, -} - -@book{kim_devops_2022, - title = {Das {DevOps}-{Handbuch}: Teams, Tools und Infrastrukturen erfolgreich umgestalten}, - shorttitle = {Das {DevOps}-{Handbuch}}, - author = {Kim, Gene and Humble, Jez and Debois, Patrick and Willis, John and Forsgren, Nicole}, - year = {2022}, - edition = {2., aktualisierte und erweiterte Auflage}, - publisher = {O'Reilly / dpunkt.verlag}, - address = {Heidelberg}, - isbn = {978-3-96009-199-8}, - pages = {520}, -} - -@book{forsgren_accelerate_2018, - title = {Accelerate: The Science of Lean Software and {DevOps}. Building and Scaling High Performing Technology Organizations}, - shorttitle = {Accelerate}, - author = {Forsgren, Nicole and Humble, Jez and Kim, Gene}, - year = {2018}, - publisher = {IT Revolution Press}, - address = {Portland, OR}, - isbn = {978-1-942788-33-1}, -} - -@book{newman_building_2021, - title = {Building Microservices: Designing Fine-Grained Systems}, - shorttitle = {Building Microservices}, - author = {Newman, Sam}, - year = {2021}, - edition = {2nd}, - publisher = {O'Reilly Media}, - address = {Sebastopol, CA}, - isbn = {978-1-492-03402-5}, -} - -@book{bass_devops_2015, - title = {{DevOps}: A Software Architect's Perspective}, - shorttitle = {{DevOps}}, - author = {Bass, Len and Weber, Ingo and Zhu, Liming}, - year = {2015}, - publisher = {Addison-Wesley Professional}, - address = {Upper Saddle River, NJ}, - series = {SEI Series in Software Engineering}, - isbn = {978-0-13-404984-7}, -} - -@book{wolff_microservices_2018, - title = {Microservices: Grundlagen flexibler Softwarearchitekturen}, - shorttitle = {Microservices}, - author = {Wolff, Eberhard}, - year = {2018}, - edition = {2.}, - publisher = {dpunkt.verlag}, - address = {Heidelberg}, - isbn = {978-3-86490-555-1}, - pages = {374}, - url = {https://www.assets.dpunkt.de/openbooks/Wolff_Microservices.pdf}, -} - -@article{shahin_continuous_2017, - title = {Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices}, - shorttitle = {Continuous Integration, Delivery and Deployment}, - author = {Shahin, Mojtaba and Babar, Muhammad Ali and Zhu, Liming}, - year = {2017}, - journal = {IEEE Access}, - volume = {5}, - pages = {3909--3943}, - doi = {10.1109/ACCESS.2017.2685629}, -} - -@inproceedings{hilton_usage_2016, - title = {Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects}, - author = {Hilton, Michael and Tunnell, Timothy and Huang, Kai and Marinov, Darko and Dig, Danny}, - year = {2016}, - booktitle = {Proceedings of the 31st {IEEE}/{ACM} International Conference on Automated Software Engineering ({ASE} 2016)}, - address = {Singapore}, - pages = {426--437}, - doi = {10.1145/2970276.2970358}, -} - -@article{soares_effects_2022, - title = {The effects of continuous integration on software development: a systematic literature review}, - shorttitle = {The effects of continuous integration on software development}, - author = {Soares, Eliakim and Sizilio, Gustavo and Santos, Jadson and {da Costa}, Daniel Alencar and Kulesza, Uir{\'a}}, - year = {2022}, - journal = {Empirical Software Engineering}, - volume = {27}, - number = {3}, - pages = {78}, - doi = {10.1007/s10664-021-10114-1}, -} - -@article{zampetti_empirical_2020, - title = {An empirical characterization of bad practices in continuous integration}, - author = {Zampetti, Fiorella and Vassallo, Carmine and Panichella, Sebastiano and Canfora, Gerardo and Gall, Harald and {Di Penta}, Massimiliano}, - year = {2020}, - journal = {Empirical Software Engineering}, - volume = {25}, - number = {2}, - pages = {1095--1135}, - doi = {10.1007/s10664-019-09785-8}, +@misc{researcherISO27001Vs2025, + title = {{{ISO}} 27001 vs. {{NIST}} 800-53: {{Key Differences Explained}}}, + shorttitle = {{{ISO}} 27001 vs. {{NIST}} 800-53}, + author = {Researcher, Security, Zakaria Sahnoune}, + year = 2025, + month = mar, + journal = {Security Compass}, + urldate = {2026-06-07}, + abstract = {ISO 27001 and NIST 800-53 are two widely recognized cybersecurity frameworks that help organizations manage security risks and comply with regulatory requirements.}, + langid = {american}, + file = {C:\Users\Roman\Zotero\storage\NDHZP2Y8\iso-27001-vs-nist-800-53.html} } @article{rostami_usage_2023, - title = {On the usage, co-usage and migration of {CI}/{CD} tools: A qualitative analysis}, - shorttitle = {On the usage, co-usage and migration of {CI}/{CD} tools}, - author = {{Rostami Mazrae}, Pooya and Mens, Tom and Golzadeh, Mehdi and Decan, Alexandre}, - year = {2023}, - journal = {Empirical Software Engineering}, - volume = {28}, - number = {2}, - pages = {52}, - doi = {10.1007/s10664-022-10285-5}, + title = {On the Usage, Co-Usage and Migration of {{CI}}/{{CD}} Tools: {{A}} Qualitative Analysis}, + shorttitle = {On the Usage, Co-Usage and Migration of {{CI}}/{{CD}} Tools}, + author = {Rostami Mazrae, Pooya and Mens, Tom and Golzadeh, Mehdi and Decan, Alexandre}, + year = 2023, + journal = {Empirical Software Engineering}, + volume = {28}, + number = {2}, + pages = {52}, + doi = {10.1007/s10664-022-10285-5} } -@inproceedings{golzadeh_rise_2022, - title = {On the Rise and Fall of {CI} Services in {GitHub}}, - author = {Golzadeh, Mehdi and Decan, Alexandre and Mens, Tom}, - year = {2022}, - booktitle = {Proceedings of the 2022 {IEEE} International Conference on Software Analysis, Evolution and Reengineering ({SANER} 2022)}, - address = {Honolulu, HI}, - pages = {662--672}, - doi = {10.1109/SANER53432.2022.00084}, +@article{shahin_continuous_2017, + title = {Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices}, + shorttitle = {Continuous Integration, Delivery and Deployment}, + author = {Shahin, Mojtaba and Babar, Muhammad Ali and Zhu, Liming}, + year = 2017, + journal = {IEEE access : practical innovations, open solutions}, + volume = {5}, + pages = {3909--3943}, + doi = {10.1109/ACCESS.2017.2685629} } -@book{painter_practical_2024, - title = {Practical {GitLab} Services: A Complete {DevOps} Guide for Developers and Administrators}, - shorttitle = {Practical {GitLab} Services}, - author = {Painter, Jeffrey}, - year = {2024}, - publisher = {Apress (Springer Nature)}, - address = {Berkeley, CA}, - isbn = {979-8-8688-0426-7}, - doi = {10.1007/979-8-8688-0427-4}, - pages = {905}, +@article{soares_effects_2022, + title = {The Effects of Continuous Integration on Software Development: A Systematic Literature Review}, + shorttitle = {The Effects of Continuous Integration on Software Development}, + author = {Soares, Eliakim and Sizilio, Gustavo and Santos, Jadson and {da Costa}, Daniel Alencar and Kulesza, Uir{\'a}}, + year = 2022, + journal = {Empirical Software Engineering}, + volume = {27}, + number = {3}, + pages = {78}, + doi = {10.1007/s10664-021-10114-1} } -@book{cowell_automating_2023, - title = {Automating {DevOps} with {GitLab} {CI}/{CD} Pipelines: Build efficient {CI}/{CD} pipelines to verify, secure, and deploy your code using real-life examples}, - shorttitle = {Automating {DevOps} with {GitLab} {CI}/{CD} Pipelines}, - author = {Cowell, Christopher and Lotz, Nicholas and Timberlake, Chris}, - year = {2023}, - publisher = {Packt Publishing}, - address = {Birmingham}, - isbn = {978-1-80323-300-0}, - pages = {348}, -} - -@misc{gitlab_s1_2021, - title = {Form {S}-1 Registration Statement}, - author = {{GitLab Inc.}}, - year = {2021}, - month = sep, - howpublished = {U.S. Securities and Exchange Commission, EDGAR Filing System}, - url = {https://www.sec.gov/Archives/edgar/data/1653482/000162828021018193/gitlabs-1.htm}, - urldate = {2026-05-04}, - note = {SEC-Anmeldung im Rahmen des Börsengangs am NASDAQ am 14.\,Oktober 2021}, -} - -% WARNUNG: Folgende Quelle (dcfmodeling.com) ist eine SEO-/Marketing-Seite mit -% deutlich AI-generiertem Inhalt (mehrere "defintely"-Tippfehler im Text). -% Vom Prof als problematisch eingestuft. Für den NASDAQ-IPO-Bezug stattdessen -% gitlab_s1_2021 (offizielles SEC S-1 Filing) verwenden. @misc{teamGitLabIncGTLB, title = {{{GitLab Inc}}. ({{GTLB}}): {{History}}, {{Ownership}}, {{Mission}}, {{How It Works}} \& {{Makes Money}}}, shorttitle = {{{GitLab Inc}}. ({{GTLB}})}, - author = {model {team}, dcf}, - journal = {AI-Powered Discounted Cash Flow Model Templates}, + author = {{model team}, dcf}, urldate = {2026-04-19}, abstract = {With GitLab Inc. (GTLB) reporting a full fiscal year 2025 revenue of over \$759.2 million, up 31\% year-over-year, do you defintely understand how this all-remote powerhouse built the most comprehensive DevSecOps platform? The company's shift to an AI-powered platform is clearly paying off, evidenced by the 29\% year-over-year growth in customers spending over \$100,000 in Annual Recurring Revenue (ARR), but what does its open-source mission-to empower everyone to contribute-really mean for its valuation? You need to see the full picture, from its mixed ownership structure, which includes institutional giants like BlackRock, to the mechanics of how its single-application model actually makes money, so let's break down the history and the financial engine that drives it. GitLab Inc. (GTLB) History You want to understand how GitLab Inc. went from a side project to a DevSecOps powerhouse, and honestly, the journey is a masterclass in open-source monetization and strategic focus. The direct takeaway is that two key decisions-going all-remote and committing to a single-application DevSecOps platform-are responsible for its current scale, which saw it achieve \$759.2 million in revenue for its fiscal year 2025. GitLab Inc.'s Founding Timeline Year established The original open-source project was established in 2011 by Dmytro Zaporozhets. GitLab Inc., the company, was formally incorporated in September 2014, moving the project from a community effort to a commercial venture. Original location The first version of the software was created by Dmytro Zaporozhets from his home in Ukraine. The company later established its headquarters in San Francisco, United States, but famously maintained its all-remote structure from the start. Founding team members The project's creator was Dmytro Zaporozhets, a Ukrainian developer. The co-founder who joined in 2012 to build a business around the open-source code was Sytse 'Sid' Sijbrandij, a Dutch developer who would become the company's long-time CEO. Initial capital/funding The project was initially bootstrapped, meaning it was self-funded and grew organically without external capital. The first significant funding came in 2015, with a \$1.5 million seed round, followed by a \$4 million Series A round from Khosla Ventures later that year. GitLab Inc.'s Evolution Milestones Year Key Event Significance 2011 Initial Open-Source Creation Ukrainian developer Dmytro Zaporozhets created the first version as a side project, establishing the open-source foundation. 2014 GitLab Inc. Incorporation Sytse Sijbrandij formalized the business, leading to the creation of the all-remote company and the adoption of the open-core business model. 2016 Shift to Single-Application DevOps A critical pivot from being just a Git repository manager to a comprehensive DevOps platform, integrating Continuous Integration/Continuous Delivery (CI/CD). 2018 Achieved Unicorn Status Raised \$100 million in Series D funding, valuing the company at \$1.1 billion, validating its expansive DevSecOps strategy. 2021 Initial Public Offering (IPO) Began trading on the NASDAQ under the ticker GTLB on October 14, 2021, marking a major financial milestone and liquidity event. FY 2025 Revenue Surpasses \$750M Reported full fiscal year revenue of \$759.2 million, a 31\% year-over-year increase, showing strong enterprise adoption. GitLab Inc.'s Transformative Moments The company's trajectory wasn't just about incremental growth; it was shaped by a few defintely bold, high-stakes decisions that changed its market position. The Single-Application Vision: Moving beyond simple Git repository management to offer a complete DevSecOps platform in a single application was a game-changer. This integration of development, security, and operations tools reduced the common problem of tool sprawl for customers and became a core differentiator. The All-Remote Mandate: The decision to operate as a fully remote company from its inception allowed GitLab Inc. to hire top talent globally, lower overhead costs, and build a unique, highly transparent culture documented in its public handbook. This model proved to be a massive competitive advantage, especially post-2020. Embracing AI-Native Capabilities: The strategic focus in fiscal year 2025 on AI/ML integration, particularly with the launch of the GitLab Duo features, is the latest transformative move. This shift is designed to automate workflows and boost developer productivity by an estimated 40-50\% for early adopters, positioning the platform for the next wave of software development. This relentless focus on a single, integrated platform has been key to expanding its enterprise customer base, where customers with more than \$1 million in Annual Recurring Revenue (ARR) grew to 123 in FY 2025. You can dig deeper into the financial mechanics of this growth by Breaking Down GitLab Inc. (GTLB) Financial Health: Key Insights for Investors. GitLab Inc. (GTLB) Ownership Structure GitLab Inc. (GTLB) operates with a highly concentrated ownership structure, where institutional investors hold the vast majority of the company's shares, a common trait for high-growth, publicly-traded software companies. This structure means that while co-founder influence is still present, the company's stock price and strategic direction are defintely heavily influenced by the trading decisions of large asset managers like BlackRock and Vanguard Group Inc. Given Company's Current Status GitLab Inc. is a publicly traded company on the NASDAQ Global Select Market under the ticker symbol GTLB. It completed its initial public offering (IPO) in October 2021. As of November 2025, the company maintains a significant market capitalization, which was approximately \$7.39 billion just prior to its Q3 Fiscal Year 2026 earnings release, reflecting its standing as a leader in the DevSecOps platform space. Given Company's Ownership Breakdown The company's ownership profile is dominated by institutional capital, which provides both stability and a strong mandate for financial performance. This is a crucial detail for any investor Exploring GitLab Inc. (GTLB) Investor Profile: Who's Buying and Why?. Here is the breakdown of the common stock ownership as of the most recent filings near November 2025, based on the total shares outstanding. Shareholder Type Ownership, \% Notes Institutional Investors 88.72\% Includes major asset managers like Vanguard Group Inc. (holding \textasciitilde 9.16\%) and BlackRock, Inc. (holding \textasciitilde 4.89\%). Insider Ownership 3.75\% Represents shares held by executives and board members, including co-founder Sytse Sijbrandij. Retail/Individual Investors 7.53\% This is the remaining float, calculated as 100\% minus the institutional and insider holdings. Here's the quick math: when nearly 90\% of the stock is in the hands of institutions, their collective buying or selling can move the share price quickly, so tracking their 13F filings is a must. Given Company's Leadership The management team steering GitLab Inc. is a blend of long-time leaders and recent strategic hires, reflecting the company's focus on scaling its DevSecOps platform and integrating artificial intelligence (AI) capabilities. The executive leadership team, as of November 2025, includes: Bill Staples: Chief Executive Officer (CEO). James Shen: Interim Chief Financial Officer (CFO). He was appointed to this role in September 2025 following the departure of Brian Robins. Manav Khurana: Chief Product and Marketing Officer. Sabrina Farmer: Chief Technology Officer (CTO). Ian Steward: Chief Revenue Officer (CRO). Manu Narayan: Chief Information Officer (CIO). The recent appointment of an Interim CFO in September 2025 shows a focus on maintaining financial stability during a transition, which is typical when a key executive departs for a competitor like Snowflake. Interim appointments like this signal that the board is taking its time to find a long-term fit to drive the next phase of sustainable growth and profitability. GitLab Inc. (GTLB) Mission and Values GitLab Inc.'s purpose extends beyond its impressive financial metrics-like the \$759.2 million in revenue for fiscal year 2025-by focusing on a deeply collaborative and transparent culture that fundamentally changes how software is created. This cultural DNA, built on six core values, is what drives their platform-first strategy and their commitment to open contribution. GitLab Inc.'s Core Purpose You're looking for a company that stands on solid ground, and for GitLab Inc., that foundation is their mission to make all creative work accessible and modifiable, not just read-only. This is a powerful, almost philosophical stance for a software company, and it directly translates into their open-core business model (offering a free, open-source version alongside paid tiers). Official Mission Statement The company's mission is simple but ambitious: to enable everyone to contribute to and co-create the software that powers our world. This isn't just about code; it's about breaking down the barriers between development, security, and operations (DevSecOps) teams, plus all the other stakeholders. Enable everyone to contribute to and co-create the software that powers our world. Vision Statement Their vision is a clear roadmap for achieving that mission, aiming to be the singular platform that facilitates global digital transformation. Honestly, a single, integrated platform is what enterprises are demanding right now to cut down on tool sprawl and complexity. Be the platform that empowers everyone to contribute to all digital transformation. GitLab Inc. Slogan/Tagline While they don't use a punchy, one-word slogan, their positioning is crystal clear, especially as they integrate more artificial intelligence (AI) into their offerings, which is a key growth driver for the business. This focus helped them generate \$120.0 million in Non-GAAP Adjusted Free Cash Flow in FY2025. The most comprehensive AI-powered DevSecOps platform for software innovation. Start shipping better software faster. Core Values (CREDIT) GitLab Inc. is famously an all-remote company, and their six core values-which conveniently spell out CREDIT-act as a distributed decision-making framework for their global workforce. This level of transparency is defintely rare, with over 5,000 pages of their internal processes being public. You can see how these values directly support their mission. Collaboration: Prioritizing asynchronous communication and assuming good intent. Results: Focusing on output and measurable business outcomes. Efficiency: Working smarter, not just harder, to deliver value quickly. Diversity, Inclusion \& Belonging (DIB): A commitment to a global, all-remote team. Iteration: Doing the smallest thing possible and shipping it quickly; small, continuous improvements. Transparency: Making information public by default, which builds trust with users and investors. For a deeper dive into how these principles underpin their financial performance, check out Breaking Down GitLab Inc. (GTLB) Financial Health: Key Insights for Investors. GitLab Inc. (GTLB) How It Works GitLab Inc. operates by delivering the most comprehensive, AI-powered DevSecOps platform as a single application, allowing software teams to manage the entire software development lifecycle-from planning code to deployment and monitoring-in one place. This unified approach eliminates the friction and security gaps that come from stitching together disparate, best-of-breed tools, helping organizations ship more secure software faster. GitLab Inc.'s Product/Service Portfolio The company's offerings are structured around a tiered, subscription-based model that scales with the size and complexity of the customer's needs, driving revenue growth through a clear 'land and expand' strategy. For the fiscal year 2025, this strategy helped drive total revenue to \$759.2 million. Product/Service Target Market Key Features Free/Community Edition Individual Developers, Small Teams, Open Source Projects Core Git repository management, basic CI/CD (Continuous Integration/Continuous Delivery), and issue tracking. It is the foundation of the open-core model. Premium Mid-Market \& Scaling Teams (e.g., 9,893 customers with {$>\$$}5K ARR) Enhanced workflow management, enterprise-grade support (24/7), advanced CI/CD features, and compliance controls. Focuses on improving team efficiency and collaboration. Ultimate (including GitLab Duo) Large Enterprises \& Highly Regulated Industries (e.g., 1,229 customers with {$>\$$}100K ARR) Full DevSecOps capabilities: Advanced security testing (SAST, DAST), compliance, portfolio management, and GitLab Duo (AI-powered code generation and assistance). GitLab Inc.'s Operational Framework GitLab's operational framework is built on a few core principles that translate directly into value creation for customers. Honestly, it's all about consolidation and efficiency. They are the only cloud-agnostic, model-neutral DevSecOps platform, meaning you can run it anywhere, which is a huge draw for large companies. The company's revenue growth, which hit 31\% for FY 2025, is primarily driven by this 'land and expand' motion, where customers start with lower tiers and expand to Premium or Ultimate as they consolidate their toolchains. Single Application Approach: Instead of integrating 10+ disparate tools for planning, coding, testing, securing, and deploying, GitLab provides a single codebase and unified data model. This cuts down on integration costs and context switching for developers. Open-Core Business Model: The free, open-source Community Edition drives widespread adoption and a massive user base (over 50 million registered users), which acts as a powerful top-of-funnel for their paid Premium and Ultimate subscriptions. AI-Driven Development: A key FY25 investment theme was enabling AI/ML efficiencies across DevSecOps, with GitLab Duo moving from 'AI-assisted' to 'AI-driven' to boost developer productivity and ensure security and compliance for AI-generated code. You can see how this operational focus aligns with their core beliefs: Mission Statement, Vision, \& Core Values of GitLab Inc. (GTLB). GitLab Inc.'s Strategic Advantages The company's market success comes down to three clear advantages: platform completeness, a superior economic model, and their commitment to AI-native security. What this estimate hides, though, is the intense competition from Microsoft's GitHub, still the primary risk. Toolchain Consolidation: The single DevSecOps platform is a major differentiator against competitors like Microsoft Corporation's GitHub, which often requires users to integrate third-party tools for security and operations. This consolidation saves time and money for enterprise customers. Exceptional Unit Economics: GitLab maintains a very high gross profit margin, sitting at about 88.52\% as of late 2025, giving them significant capital flexibility to invest in their AI platform. High Customer Expansion: Their dollar-based net retention rate (DBNRR) was a strong 123\% in Q4 FY25, meaning existing customers spent 23\% more on average than they did the previous year. This shows the 'expand' part of their strategy is working defintely well. Financial Strength and Efficiency: For the full fiscal year 2025, the company achieved a non-GAAP operating margin of 10\% and a non-GAAP adjusted free cash flow of \$120.0 million, demonstrating a focus on profitable growth, which is rare in the high-growth software sector. GitLab Inc. (GTLB) How It Makes Money GitLab Inc. (GTLB) primarily generates revenue by selling subscriptions to its comprehensive DevSecOps platform, which is offered as both a cloud-based Software-as-a-Service (SaaS) and a self-managed solution. The company's financial engine is built on recurring subscription fees, meaning predictable, high-margin revenue from customers who pay per user to access its integrated development, security, and operations tools. GitLab Inc.'s Revenue Breakdown You need to see where the money is actually coming from, not just the top-line number. For the second quarter of fiscal year 2026 (ended July 31, 2025), GitLab's revenue was \$236.0 million, and the breakdown confirms the dominance of the subscription model. Revenue Stream \% of Total (Q2 FY2026) Growth Trend Subscription (SaaS \& Self-Managed) 90.13\% Increasing Professional Services \& Other 9.87\% Increasing That 90.13\% from subscriptions is the core of their business model, a classic high-quality SaaS revenue stream. The Subscription revenue of \$212.7 million in Q2 FY2026 was the main driver of the overall 29\% year-over-year revenue growth. Business Economics The real story here is how GitLab is monetizing its customer base, and that means looking beyond the initial sale. Their business economics are shifting toward a hybrid model to capture more value from heavy users, especially with the rise of AI-powered development. High Retention: The Dollar-Based Net Retention Rate (DBNRR) was 121\% in Q2 FY2026. This means existing customers, on average, spent 21\% more this year than last year. That's a huge lever for growth. Gross Margin Strength: Non-GAAP Gross Margin stood at a very healthy 90\% in Q2 FY2026. This high margin shows the platform's efficiency and scalability, proving that selling another user seat costs the company very little. Hybrid Pricing Model: GitLab is transitioning from a purely seat-based subscription to a seat-plus-usage model. This lets them charge for the base access and for consumption of high-value features, like their AI agent, GitLab Duo, which is priced at \$19 per month per user. This is defintely a smart move to monetize the AI productivity boom. Here's the quick math: a 121\% DBNRR means they grow revenue even if they don't add a single new customer, just by getting existing ones to expand their usage or upgrade their tier. GitLab Inc.'s Financial Performance The financial trend is clear: strong growth is being paired with a rapid move toward operational efficiency, which is what you want to see in a maturing software company. For more detail on the structural health of the business, you should check out Breaking Down GitLab Inc. (GTLB) Financial Health: Key Insights for Investors. Annual Revenue: Total revenue for the full fiscal year 2025 reached \$759.2 million, marking a robust 31\% increase year-over-year. Operating Profitability: The non-GAAP Operating Margin has seen massive expansion, moving from 10\% for the full FY2025 to 17\% in the more recent Q2 FY2026. This indicates serious operational leverage as the company scales. Cash Flow Generation: GitLab is generating substantial free cash flow (FCF), a sign of financial health. Non-GAAP Adjusted Free Cash Flow for FY2025 was \$120.0 million. In Q2 FY2026 alone, it was \$46.5 million. Enterprise Customer Growth: The most valuable customers are expanding quickly. The number of customers with over \$100,000 in Annual Recurring Revenue (ARR) grew 25\% year-over-year in Q2 FY2026, reaching 1,344 customers. These large contracts underpin the revenue stability. GitLab Inc. (GTLB) Market Position \& Future Outlook GitLab Inc. is defintely positioned as the leading integrated DevSecOps platform, aggressively challenging the incumbent toolchain model by consolidating the entire software development lifecycle (SDLC) into a single application. The company's focus on AI-driven security and compliance positions it to capture a larger share of the enterprise market, targeting an estimated full-year Fiscal Year 2025 revenue of approximately \$753 million. You're looking at a company that's not just selling a tool, but a platform philosophy-so its near-term success hinges on converting customers from fragmented toolchains (like Jira + Jenkins + GitHub) to its all-in-one solution. Competitive Landscape The DevOps market, valued at around \$16.13 billion in 2025, is a battleground between integrated platforms and best-of-breed toolchains. GitLab's primary competition comes from Microsoft-owned GitHub and the Atlassian ecosystem, each dominating different parts of the SDLC. Here's the quick math on the relative market positioning as of late 2025, based on platform adoption and CI/CD tool usage: Company Market Share, \% Key Advantage GitLab Inc. 12\% Single, integrated DevSecOps platform; strong self-managed/compliance features. GitHub (Microsoft) 55\% Dominant code hosting, largest developer community, expansive third-party Actions ecosystem. Atlassian (Bitbucket) 18.61\% Deep integration with Jira and Confluence; strong presence in the Continuous Integration/Continuous Delivery (CI/CD) tools market. Opportunities \& Challenges GitLab's strategic initiatives for late 2025 and into 2026 center on AI and enterprise compliance, but still face headwinds from established competitors and a complex regulatory environment. Opportunities Risks AI-Native DevSecOps: Monetizing GitLab Duo (AI orchestration platform) to accelerate development by an early-reported 50\%. AI Competition \& Pricing Pressure: Aggressive AI product launches from Microsoft (GitHub Copilot) and other cloud vendors. Enterprise Consolidation: Driving adoption of the Ultimate tier, which focuses on security and compliance, to increase the Dollar-Based Net Retention Rate (DBNRR), which was 121\% in Q2 FY2026. Macroeconomic Spending Slowdown: Enterprise customers optimizing cloud and software budgets, which can delay platform migration decisions. Regulated/Sovereign Cloud: Expanding the GitLab Dedicated offering via the partnership with Amazon Web Services Inc. (AWS) to capture highly regulated industries requiring data residency. Leadership Transition: CFO Brian Robins' departure in September 2025 introduces a minor, but real, operational risk during a critical growth phase. Industry Position GitLab is a clear leader in the DevSecOps platform category, often recognized for its completeness over competitors who rely on assembling toolchains. The company's unique all-remote structure also gives it an edge in talent acquisition and operational efficiency. Win the Platform War: The strategy is to win on platform completeness, offering a single data model for the entire SDLC, which eliminates context switching and tool sprawl friction. Ultimate Tier Focus: Continued investment in security, compliance, and governance features drives higher average selling prices (ASPs) and targets the large enterprise market. Investor Confidence: The company's guidance for Fiscal Year 2026 revenue of \$936 million to \$942 million suggests strong confidence in sustaining momentum. This aggressive push into AI and compliance is why you should be watching their customer adoption metrics closely. You can find more details on institutional holdings and investment theses here: Exploring GitLab Inc. (GTLB) Investor Profile: Who's Buying and Why?}, - howpublished = {https://dcfmodeling.com/blogs/history/gtlb-history-mission-ownership}, langid = {english}, - file = {C:\Users\Roman\Zotero\storage\C5XVTVNI\gtlb-history-mission-ownership.html} + file = {C:\Users\Roman\Zotero\storage\GEFBWV3L\gtlb-history-mission-ownership.html} +} + +@book{wolff_microservices_2018, + title = {Microservices: {{Grundlagen}} Flexibler Softwarearchitekturen}, + shorttitle = {Microservices}, + author = {Wolff, Eberhard}, + year = 2018, + edition = {2.}, + pages = {374}, + publisher = {dpunkt.verlag}, + address = {Heidelberg}, + isbn = {978-3-86490-555-1} +} + +@article{zampetti_empirical_2020, + title = {An Empirical Characterization of Bad Practices in Continuous Integration}, + author = {Zampetti, Fiorella and Vassallo, Carmine and Panichella, Sebastiano and Canfora, Gerardo and Gall, Harald and Di Penta, Massimiliano}, + year = 2020, + journal = {Empirical Software Engineering}, + volume = {25}, + number = {2}, + pages = {1095--1135}, + doi = {10.1007/s10664-019-09785-8} } From 61a27274956404bfa40eed6e3ff04b709df5f363 Mon Sep 17 00:00:00 2001 From: 2211275 <2211275@stud.hs-mannheim.de> Date: Mon, 8 Jun 2026 22:18:05 +0200 Subject: [PATCH 7/8] pipeline security --- DMS_paper15_gitlab.tex | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/DMS_paper15_gitlab.tex b/DMS_paper15_gitlab.tex index f53e181..42f2261 100644 --- a/DMS_paper15_gitlab.tex +++ b/DMS_paper15_gitlab.tex @@ -412,7 +412,9 @@ stages: \item Konfigurationseinstellungen \item Betriebssystemeinstellungen \end{itemize} - Innerhalb der Anwendungseinstellungen können Push-Regeln festgelegt werden, sodass unverifizierte Nutzer keinen Code hochladen können. Es kann sichergestellt werden, dass geheime Dateien nicht versehentlich gepusht werden. Ebenso sollen projektspezifische Keys/Schlüssel für Deployment-Prozesse eingerichtet werden. Die Sichtbarkeit von Gruppen, Snippets und Projekten soll als \textit{privat} gesetzt werden. Benutzer können gezwungen werden komplexere Passwörter für ihren GitLab Account zu wählen. Eine 2-Faktor Authentifizierung kann eingerichtet werden. Die Kommunikation mit aussenstehenden Systemen kann konkret festgelegt werden, indem externe Systeme zuerst anhand ihrer IP-Adresse für ausgehende anfragen in GitLab eingetragen werden müssen. Für die GitLab-Instanz kann ein Rate-Limit, mit Ausnahmen für bestimmte Nutzer, eingestellt werden \cite{gitlab_gitlab_nodate}. + Innerhalb der Anwendungseinstellungen können Push-Regeln festgelegt werden, sodass unverifizierte Nutzer keinen Code hochladen können. Es kann sichergestellt werden, dass geheime Dateien nicht versehentlich gepusht werden. Ebenso sollen projektspezifische Keys/Schlüssel für Deployment-Prozesse eingerichtet werden. Die Sichtbarkeit von Gruppen, Snippets und Projekten soll als \textit{privat} gesetzt werden. Benutzer können gezwungen werden komplexere Passwörter für ihren GitLab Account zu wählen. Eine 2-Faktor Authentifizierung kann eingerichtet werden. Die Kommunikation mit aussenstehenden Systemen kann konkret festgelegt werden, indem externe Systeme zuerst anhand ihrer IP-Adresse für ausgehende anfragen in GitLab eingetragen werden müssen. Für die GitLab-Instanz kann ein Rate-Limit, mit Ausnahmen für bestimmte Nutzer, eingestellt werden \cite{gitlab_gitlab_nodate}.\\\\ + Für \acs{CI}/\acs{CD}-Pipelines besteht die Möglichkeit sensitive Daten wie bspw. Passwörter oder Tokens in Form von \textit{Secrets} zu speichern. \textit{Secrets} werden durch externe Dienstleister gespeichert. Neben \textit{Secrets} besteht die weniger empfohlene Variante Daten in Form von \textit{CI/CD Variablen} zu speichern. Eine solche Variable kann maskiert werden und wird damit in Logs durch einen definierten Platzhalter ersetzt. Zusätzlich zu einer Maskierung erlaubt GitLab \textit{CI/CD Variablen} verstecken. Die Variable wird nicht mehr auf der Einstellungsseite für \acs{CI}/\acs{CD} angezeigt. Ebenso kann eine Variable geschützt werden, sodass nur auf geschützten Branches Zugriff besteht \cite{gitlab_gitlab_nodate}.\\\\ + \subsection{Kompatibilität} From 9177a6e6244d732036a030f17191fa09cdd5e4fa Mon Sep 17 00:00:00 2001 From: 2211275 <2211275@stud.hs-mannheim.de> Date: Tue, 9 Jun 2026 14:27:54 +0200 Subject: [PATCH 8/8] application and os security --- DMS_paper15_gitlab.tex | 10 +++++++--- literatur/dms.bib | 23 +++++++++++++++++++++++ 2 files changed, 30 insertions(+), 3 deletions(-) diff --git a/DMS_paper15_gitlab.tex b/DMS_paper15_gitlab.tex index 42f2261..74c921b 100644 --- a/DMS_paper15_gitlab.tex +++ b/DMS_paper15_gitlab.tex @@ -412,9 +412,10 @@ stages: \item Konfigurationseinstellungen \item Betriebssystemeinstellungen \end{itemize} - Innerhalb der Anwendungseinstellungen können Push-Regeln festgelegt werden, sodass unverifizierte Nutzer keinen Code hochladen können. Es kann sichergestellt werden, dass geheime Dateien nicht versehentlich gepusht werden. Ebenso sollen projektspezifische Keys/Schlüssel für Deployment-Prozesse eingerichtet werden. Die Sichtbarkeit von Gruppen, Snippets und Projekten soll als \textit{privat} gesetzt werden. Benutzer können gezwungen werden komplexere Passwörter für ihren GitLab Account zu wählen. Eine 2-Faktor Authentifizierung kann eingerichtet werden. Die Kommunikation mit aussenstehenden Systemen kann konkret festgelegt werden, indem externe Systeme zuerst anhand ihrer IP-Adresse für ausgehende anfragen in GitLab eingetragen werden müssen. Für die GitLab-Instanz kann ein Rate-Limit, mit Ausnahmen für bestimmte Nutzer, eingestellt werden \cite{gitlab_gitlab_nodate}.\\\\ - Für \acs{CI}/\acs{CD}-Pipelines besteht die Möglichkeit sensitive Daten wie bspw. Passwörter oder Tokens in Form von \textit{Secrets} zu speichern. \textit{Secrets} werden durch externe Dienstleister gespeichert. Neben \textit{Secrets} besteht die weniger empfohlene Variante Daten in Form von \textit{CI/CD Variablen} zu speichern. Eine solche Variable kann maskiert werden und wird damit in Logs durch einen definierten Platzhalter ersetzt. Zusätzlich zu einer Maskierung erlaubt GitLab \textit{CI/CD Variablen} verstecken. Die Variable wird nicht mehr auf der Einstellungsseite für \acs{CI}/\acs{CD} angezeigt. Ebenso kann eine Variable geschützt werden, sodass nur auf geschützten Branches Zugriff besteht \cite{gitlab_gitlab_nodate}.\\\\ - + Innerhalb der Anwendungseinstellungen können Push-Regeln festgelegt werden, sodass unverifizierte Nutzer keinen Code hochladen können. Es kann sichergestellt werden, dass geheime Dateien nicht versehentlich gepusht werden. Ebenso sollen projektspezifische Keys/Schlüssel für Deployment-Prozesse eingerichtet werden. Die Sichtbarkeit von Gruppen, Snippets und Projekten soll als \textit{privat} gesetzt werden. Benutzer können gezwungen werden komplexere Passwörter für ihren GitLab Account zu wählen. Eine 2-Faktor Authentifizierung kann eingerichtet werden. Die Kommunikation mit aussenstehenden Systemen kann konkret festgelegt werden, indem externe Systeme zuerst anhand ihrer IP-Adresse für ausgehende anfragen in GitLab eingetragen werden müssen. Für die GitLab-Instanz kann ein Rate-Limit, mit Ausnahmen für bestimmte Nutzer, eingestellt werden \cite{gitlab_gitlab_nodate}.\\ + Für \acs{CI}/\acs{CD}-Pipelines besteht die Möglichkeit sensitive Daten wie bspw. Passwörter oder Tokens in Form von \textit{Secrets} zu speichern. \textit{Secrets} werden durch externe Dienstleister gespeichert. Neben \textit{Secrets} besteht die weniger empfohlene Variante Daten in Form von \textit{CI/CD Variablen} zu speichern. Eine solche Variable kann maskiert werden und wird damit in Logs durch einen definierten Platzhalter ersetzt. Zusätzlich zu einer Maskierung erlaubt GitLab \textit{CI/CD Variablen} verstecken. Die Variable wird nicht mehr auf der Einstellungsseite für \acs{CI}/\acs{CD} angezeigt. Ebenso kann eine Variable geschützt werden, sodass nur auf geschützten Branches Zugriff besteht \cite{gitlab_gitlab_nodate}.\\ + Eine GitLab-Instanz kann konfiguriert werden, sodass Nutzer per \ac{SSH} oder über \ac{HTTPS} zugreifen können \cite{gitlab_gitlab_nodate}. Ein Zugang kann auf eine der beiden Protokolle beschränkt werden. \ac{HTTPS} ist meist zugänglicher für Nutzer, da wenig Konfiguration vorgenommen werden muss. Allerdings wird die Authentifizierung per Nutzername und \textit{Access Token} oder Passwort vorgenommen, welche häufig erneut abgefragt werden. \ac{SSH} bietet eine höhere Sicherheit. Es ist sichergestellt, dass keine Daten während der Übertragung unbemerkt verändert werden. Die Konfiguration ist komplexer. \ac{SSH} basiert auf einer \textit{Public-Key}-Infrastruktur, wobei der öffentliche Schlüssel auf GitLab zuvor hinterlegt werden muss \cite{marijanSSHVsHTTPS2025}. GitLab kann ebenso E-Mails versenden und empfangen. Versendete E-mails können mit \ac{S/MIME} versendet signiert werden, um deren Legitimität zu sichern \cite{gitlab_gitlab_nodate}. \ac{S/MIME} ist ein Verschlüsselungsstandard für E-Mails.\\ + Die GitLab-Dokumentation bietet zusätzlich Konfigurationen für das unterliegende Betriebssystem, wie \ac{SSH}-Konfiguration, Firewall Einstellungen und Änderungen am Kernel \cite{gitlab_gitlab_nodate}. \subsection{Kompatibilität} @@ -538,6 +539,9 @@ stages: \acro{NIST}{National Institute of Standards and Technology} \acro{ISO}{Internationale Organisation für Normung} \acro{IEC}{International Electrotechnical Commission} + \acro{HTTPS}{Hypertext Transfer Protocol Secure} + \acro{SSH}{Secure Shell} + \acro{S/MIME}{Secure/Multipurpose Internet Mail Extensions} \end{acronym} \printbibliography diff --git a/literatur/dms.bib b/literatur/dms.bib index 496eb95..4ee4bf4 100644 --- a/literatur/dms.bib +++ b/literatur/dms.bib @@ -6,6 +6,16 @@ file = {C:\Users\Roman\Zotero\storage\29SDLBQ5\2025.html} } +@misc{AdvantagesSSHGit, + title = {Advantages of {{SSH}} for {{Git}} Operations}, + journal = {GitLab, Inc.}, + urldate = {2026-06-09}, + abstract = {Advantages of SSH for Git operationsOverviewGitLab supports performing Git operations using both HTTPS and SSH. There are many advantages of using SSH instead of HTTPS, particularly in relation to ...}, + howpublished = {https://support.gitlab.com/hc/en-us/articles/21476152234524-Advantages-of-SSH-for-Git-operations}, + langid = {american}, + file = {C:\Users\Roman\Zotero\storage\8YRVJ3L5\21476152234524-Advantages-of-SSH-for-Git-operations.html} +} + @article{arefeen_continuous_2019, title = {Continuous {{Integration Using Gitlab}}}, author = {Arefeen, Mohammed Shamsul and Schiller, Michael}, @@ -253,6 +263,19 @@ isbn = {978-3-96009-199-8} } +@misc{marijanSSHVsHTTPS2025, + title = {{{SSH}} vs. {{HTTPS}} for {{Git}}: {{Which One Should You Use}}?}, + shorttitle = {{{SSH}} vs. {{HTTPS}} for {{Git}}}, + author = {Marijan, Bosko}, + year = 2025, + month = dec, + journal = {Knowledge Base by phoenixNAP}, + urldate = {2026-06-09}, + abstract = {SSH and HTTPS are network protocols that secure the connection to a remote Git repository. Learn the difference and choose the one for you.}, + langid = {american}, + file = {C:\Users\Roman\Zotero\storage\7U225IS9\git-ssh-vs-https.html} +} + @book{newman_building_2021, title = {Building Microservices: {{Designing}} Fine-Grained Systems}, shorttitle = {Building Microservices},