added structure of gitlab
parent
0addb859dd
commit
026c64041d
|
|
@ -113,9 +113,6 @@
|
|||
\label{tab:saas_plans}
|
||||
\end{table}
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Geschichte}
|
||||
|
||||
GitLab wurde von Sytse Sijbrandij und von Dmitriy Zaporozhets gegründet. Zaporozhets entwickelte GitLab 2011 als Hilfsmittel für seine eigenen Projekte. GitLab war zu dem Zeitpunkt eine private und freie Plattform zum eigenen Code-Hosting, entwickelt von Zaporozhets. Zaporozhets und Sijbrandij lernten sich auf der \href{https://thenextweb.com/conference}{The Next Web} Konferenz kennen. Nachdem Zaporozhets sich entschied den Quellcode von GitLab frei zugänglich zu machen, entstand die Partnerschaft mit Sijbrandij. Um den Einstieg in die Nutzung von GitLab zu erleichtern entschieden sich Sijbrandij GitLab als \ac{SaaS} unter der Domain \url{https://gitlab.com/} anzubieten. Der Quellcode von GitLab ist frei unter \url{https://gitlab.com/gitlab-org/gitlab} verfügbar \cite{degeler_gitlab_2014}. Der Quellcode des Konkurrenten GitHub ist nicht frei zugänglich. 2014 wurde GitLab erstmalig als Unternehmen eingetragen und erfuhr seitdem einen grossen Zuwachs an Mitarbeitern. Aktuell zählt GitLab mehr als 2600 Mitarbeiter, die über 65 Länder verteilt leben \cite{gitlab_about}. GitLab selbst besitzt keinen grossen ausgebauten Firmenhauptsitz, da Mitarbeiter hauptsächlich remote arbeiten und freie Verfügung über ihre Arbeitszeit besitzen. Der organisatorische Aufbau und der Ablauf interner Prozesse von GitLab, können in dem von GitLab öffentlichem Handbuch \url{https://handbook.gitlab.com/} nachgelesen werden \cite{choudhuryGitLabWorkWhere2020}.
|
||||
|
|
@ -132,15 +129,49 @@
|
|||
|
||||
\subsection{Aufbau}
|
||||
|
||||
Zusammenarbeit in GitLab ist in Form von Gruppen organisiert. Diese können in Subgruppen unterteilt werden. Gruppen und Subgruppen können Projekte und Mitarbeiter zugeordnet werden.
|
||||
Jedes Projekt besteht aus einer Issue-Seite, einem Wiki und einem Code-Repository. \cite{gitlab_gitlab_nodate}
|
||||
|
||||
% Vergleich von Features mit möglich
|
||||
|
||||
\subsection{Funktionalitäten}
|
||||
Zusammenarbeit in GitLab ist in Form von Gruppen organisiert. Diese können in Subgruppen unterteilt werden. Gruppen und Subgruppen können Projekte und Mitarbeiter zugeordnet werden.
|
||||
Jedes Projekt besteht aus einer Issue-Seite und einem Code-Repository. Für ein Projekt kann optional ein Wiki angelegt werden, um Informationen in Form von \ac{GLFM} zu dokumentieren \cite{gitlab_gitlab_nodate}. \ac{GLFM} ist eine spezielle Markdown-Spezifikation, welche die grundlegende Definition erweitert. Projekte besitzen folgende Sichtbarkeitsstufen:
|
||||
\begin{itemize}
|
||||
\item \textbf{Public} Als öffentlich zugängliche Ressourcen kann jedermann zugreifen. Ein Zugriff ist auch ohne einen GitLab Account möglich.
|
||||
\item \textbf{Internal} Nur GitLab-Nutzer können auf die als intern markierte Ressource zugreifen.
|
||||
\item \textbf{Private} Nur Nutzer die explizit als Mitarbeiter/Teilnehmer zu einem Projekt hinzugefügt wurden, können auf private Ressourcen zugreifen.
|
||||
\end{itemize}
|
||||
Ein Projekt wird immer unter einem Namensraum angelegt. In GitLab wird in 2 Typen von Namensräumen unterschieden:
|
||||
\begin{itemize}
|
||||
\item \textbf{Nutzer} Der Namensraum von einem Nutzer kann keine Subgruppen enthalten. Wird sich entschieden den Nutzernamen zu ändern, so ändert sich auch die URL des Namensraum
|
||||
\item \textbf{Gruppe} Innerhalb von Gruppen können Subgruppen erstellt werden, welche ihre Einstellungen vorerst von ihrer Elterngruppe erben.
|
||||
\end{itemize}
|
||||
Tabelle \ref{tab:namespaces} zeigt eine Auflistung beispielhafter Namensräume mit entsprechender URL für eine Gitlab-Instanz unter der Domain \texttt{domain.com}.
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tabular}{@{}lll@{}}
|
||||
\toprule
|
||||
Namensraum & URL & Beschreibung \\ \midrule
|
||||
\texttt{max} & https://domain.com/max & \makecell[cl]{Nutzer mit Namen \\ \texttt{max}} \\
|
||||
\texttt{team} & https://domain.com/team & \makecell[cl]{Gruppe mit Namen \\ \texttt{team}} \\
|
||||
\texttt{team/design} & https://domain.com.com/team/design & \makecell[cl]{Subgruppe \texttt{design}\\ der Gruppe \texttt{team}} \\ \bottomrule
|
||||
\end{tabular}%
|
||||
}
|
||||
\caption{Beispielhafte Namensräume von Projekten in GitLab}
|
||||
\label{tab:namespaces}
|
||||
\end{table}
|
||||
GitLab unterscheidet in folgende Nutzertypen, die auf eine GitLab Instanz zugreifen können \cite{gitlab_gitlab_nodate}:
|
||||
\begin{itemize}
|
||||
\item \textbf{Auditor} Ein Auditor besitzt nur Lese-Zugriff auf alle zur Verfügung stehenden Ressourcen. Auditoren werden in der Praxis meist verwendet um die Einhaltung von bspw. gesetzlichen Regularien und Richtlinien, die von einem Unternehmen erfüllt werden sollen, zu überprüfen. Auditoren sind nur innerhalb des selbstgehosten und dedizierten Lösung möglich.
|
||||
\item \textbf{External} Ein externer Nutzer besitzt eingeschränkten Zugriff auf private Ressourcen einer GitLab-Instanz. Diese müssen davor explizit als externe Nutzer hinzugefügt werden. Meistens werden externe Nutzer verwendet um Nutzern außerhalb eines Unternehmens spezifischen Zugriff auf ein Projekt oder eine Gruppe zu geben. Externe Nutzer sind nur innerhalb des selbstgehosten und dedizierten Lösung möglich.
|
||||
\item \textbf{Internal} Ein Interner Nutzer besitzt meist eingschränkten Zugriff und wird durch GitLab automatisch erstellt. Interne Nutzer können als Bots betrachtet werden, die automatisierte Prozesse durchführen, die durch normale Nutzer nicht ausgeführt werden können. Interne Nutzer sind für alle Lösungen von GitLab erhältlich.
|
||||
\item \textbf{Service} Service Accounts repräsentieren nicht menschliche Nutzer. Service Nutzer kommen bei der automatischen Ausführung von Prozessen und Pipelines zum Einsatz.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Selbstgehostete Lösung}
|
||||
|
||||
\subsection{Installation}
|
||||
|
||||
\subsection{Konfiguration}
|
||||
|
||||
\subsection{Betrieb}
|
||||
|
||||
\section{CI/CD}
|
||||
|
||||
|
|
@ -151,16 +182,7 @@
|
|||
\subsection{Jobs}
|
||||
\subsection{CICD-Komponenten}
|
||||
\subsection{GitLab vs. GitHub}
|
||||
|
||||
\section{Anwendungsbeispiel}
|
||||
|
||||
\subsection{Projekt}
|
||||
|
||||
%Projektvorstellung
|
||||
|
||||
\subsection{Konfiguration}
|
||||
|
||||
\subsection{Artefakte}
|
||||
\subsection{Anwendungsbeispiel}
|
||||
|
||||
\section{Evaluierung}
|
||||
|
||||
|
|
@ -188,6 +210,7 @@
|
|||
\acro{SaaS}{Software as a Service}
|
||||
\acro{CI}{Continuous Integration, kontinuierliche Integration}
|
||||
\acro{NASDAQ}{National Association of Securities Dealers Automated Quotations}
|
||||
\acro{GLFM}{Gitlab Flavored Markdown}
|
||||
\end{acronym}
|
||||
|
||||
\printbibliography
|
||||
|
|
|
|||
Loading…
Reference in New Issue