chore: Add CI section to docs

projektdokumentation/Abkuerzungen.tex

@@ -14,9 +14,12 @@
 % einen Platzhalter der die Breite der linken Spalte bestimmt.
 \begin{acronym}[WWWWW]
 	%\acro{API}{Application Programming Interface}
+	\acro{CI}{Continuous Integration}
+	\acro{CI/CD}{Continuous Integration/Continuous Deployment}
 	\acro{CLI}{Command Line Interface}
 	\acro{CRM}{Customer Relationship Management}
 	\acro{CRON}{Vorgangsausführung gemäß geplanten Zeitabläufen für UNIX Programme}
+	\acro{E2E}{End-to-End}
 	\acro{eCommerce}{Electronic Commerce}
 	\acro{ERM}{Entity-Relationship-Model}
 	\acro{GUI}{Graphical User Interface}

projektdokumentation/Inhalt.tex

@@ -1,2 +1,3 @@
 % !TEX root = Projektdokumentation.tex
 \input{Inhalt/Einleitung}
+\input{Inhalt/CI}

projektdokumentation/Inhalt/CI.tex

@@ -0,0 +1,53 @@
+% !TEX root = ../Projektdokumentation.tex
+\section{Continuous Integration}
+\label{sec:CI}
+
+Das Projekt verwendet Gitea Actions\footnote{Gitea Actions - \url{https://docs.gitea.com/usage/actions/overview}} als \ac{CI/CD}-Pipeline, welche vollständig kompatibel mit GitHub Actions ist.
+Entsprechend den Qualitätsanforderungen soll eine hohe Code-Qualität durch automatisierte Tests gewährleistet werden.
+
+\subsection{Aufbau der CI-Pipeline}
+\label{sec:ci-pipeline}
+
+Die Haupt-\ac{CI}-Pipeline wird durch die Datei \Datei{ci.yml} definiert und bei Pull Requests ausgelöst. Aufgrund der separaten Frontend- und Backend-Komponenten
+wurde eine \Fachbegriff{Change Detection} implementiert, welche nur relevante Tests für geänderte Bereiche ausführt.
+
+Ein initialer Job identifiziert geänderte Dateien und ermöglicht eine selektive Ausführung:
+\begin{itemize}
+	\item Backend-Änderungen: \Datei{backend/**}
+	\item Frontend-Änderungen: \Datei{frontend/**}
+	\item Workflow-Änderungen: \Datei{.gitea/workflows/**}
+\end{itemize}
+
+\subsubsection{Backend-Qualitätssicherung}
+Für Backend-Änderungen werden folgende Prüfungen durchgeführt:
+\begin{itemize}
+	\item \textbf{Unit Tests:} Ausführung mit \Eingabe{./gradlew test} in OpenJDK 23 Container
+	\item \textbf{Checkstyle:} Code-Style-Validierung mit Caching-Mechanismus
+	\item \textbf{Docker Build:} Überprüfung der Build-Funktionalität
+\end{itemize}
+
+\subsubsection{Frontend-Qualitätssicherung}
+Für Frontend-Änderungen wird eine umfassende Testsuite ausgeführt:
+\begin{itemize}
+	\item \textbf{ESLint:} Code-Qualitätsprüfung mit \Eingabe{bun run lint}
+	\item \textbf{Prettier:} Code-Formatierungsvalidierung
+	\item \textbf{Build-Test:} Produktions-Build-Validierung mit \Eingabe{bun run build}
+	\item \textbf{Playwright \ac{E2E} Tests:} End-to-End-Tests mit automatischem Backend-Start
+	\item \textbf{Docker Build:} Validierung der Container-Erstellung
+\end{itemize}
+
+\subsection{Release-Management}
+\label{sec:release-pipeline}
+
+Das Release-Management erfolgt automatisiert durch die \Datei{release.yml} Pipeline bei Pushes auf den \texttt{main}-Branch.
+Die Implementierung folgt \Fachbegriff{Semantic Versioning}\footnote{Semantic Versioning - \url{https://semver.org/}} und \Fachbegriff{Conventional Commits}\footnote{Conventional Commits - \url{https://www.conventionalcommits.org/}}.
+
+Die Release-Pipeline umfasst:
+\begin{enumerate}
+	\item \textbf{Semantic Release:} Automatische Versionierung basierend auf Commit-Nachrichten
+	\item \textbf{Docker Image Build:} Parallele Erstellung von Backend- und Frontend-Images
+	\item \textbf{Registry Push:} Upload zur privaten Gitea Docker Registry
+\end{enumerate}
+
+Die \ac{CI/CD}-Pipeline implementiert Performance-Optimierungen wie intelligentes Caching, Concurrency Control und selektive Job-Ausführung.
+Diese Automatisierung gewährleistet eine hohe Software-Qualität bei effizienten Entwicklungsprozessen.