add pdf to gitignore

Reviewed-on: #306
Reviewed-by: Phan Huy Tran <ptran@noreply.localhost>
Reviewed-by: Constantin Simonis <constantin@simonis.lol>

projektdokumentation/.gitignore

@@ -6,7 +6,7 @@
 *.fls
 *.out
 *.toc
-
+*.pdf
 ## Intermediate documents:
 *.dvi
 *-converted-to.*

projektdokumentation/Abkuerzungen.tex

@@ -13,10 +13,13 @@
 % Die Option (in den eckigen Klammern) enthält das längste Label oder
 % einen Platzhalter der die Breite der linken Spalte bestimmt.
 \begin{acronym}[WWWWW]
-	%\acro{API}{Application Programming Interface}
+	\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}
@@ -32,4 +35,6 @@
 	\acro{URL}{Uniform Resource Locator}\acused{URL}
 	\acro{VM}{Virtual Machine}
 	\acro{XML}{Extensible Markup Language}
+	\acro{API}{Application Programming Interface}
+	\acro{JWT}{JSON Web Token}
 \end{acronym}

projektdokumentation/Deckblatt.tex

@@ -2,7 +2,7 @@
 \begin{titlepage}
 
 	\begin{center}
-\includegraphics[scale=0.25]{LogoIHK.pdf}\\[1ex]
+		\includegraphics[scale=0.25]{hitec-logo.png}\\[1ex]
 
 		\Large{\ausbildungsberuf}\\
 		\LARGE{\betreff}\\[4ex]

projektdokumentation/Inhalt.tex

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

projektdokumentation/Inhalt/Auth.tex

@@ -0,0 +1,9 @@
+\section{Authentifizierung}
+\label{sec:Authentifizierung}
+Die Authentifizierung gegenüber der \acs{API} erfolgt über einen \acs{JWT}-Token, der dem Frontend nach Erfolgreicher Authentifizierung übergeben wird.
+Authentifizierung läuft über zwei verschiedene Wege ab:
+\begin{itemize}
+    \item \textbf{Registrierung mit username/password:} Der Nutzer füllt ein Registrierungs-Formular aus, welches die Anmeldedaten an die \acs{API} sendet. Diese validitert die Anmeldedaten und legt bei Erfolg einen neuen Nutzer an. Anschließend wird eine E-Mail-Verifizierungs-Mail gesendet. Bis der Link in der Verifizierungs-Mail nicht angeklickt wurde, ist der Nutzer nicht aktiv und kann sich nicht anmelden. Nach dem Klick auf den Link wird der Nutzer aktiviert und kann sich anmelden.
+    \item \textbf{Login mit username/password:} Der Nutzer füllt ein Anmelde-Formular, welches die Anmeldedaten an die \acs{API} sendet. Diese prüft die Anmeldedaten und gibt bei Erfolg einen \acs{JWT}-Token zurück. Falls kein Nutzer mit den Anmeldedaten existiert, wird der Nutzer aufgefordert einen Account zu erstellen.  
+    \item \textbf{Login über Oauth (Open Authorization):} Der Nutzer meldet sich mit einem Oauth-Provider an, in unserem Fall Google oder Github. Das Backend leitet den Nutzer zum Oauth-Provider weiter, der die Anmeldedaten prüft und bei Erfolg den Nutzer auf die Applikation weiterleitet und einen Authorization-Code zurück gibt. Mit diesem Code holt sich die \acs{API} einen \acs{JWT} vom jeweiligen Provider und holt sich Nutzer-Informationen. Mit diesen wird dann ein existierender Nutzer eingeloggt, oder registriert falls der Nutzer noch kein Konto hatte. Anschließend wird von der \acs{API} ein \acs{JWT} generiert und an das Frontend weitergegeben. 
+\end{itemize}

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.

projektdokumentation/Inhalt/Projektarchitektur.tex

@@ -0,0 +1,40 @@
+% !TEX root = ../Projektdokumentation.tex
+\section{Projektarchitektur}
+\label{sec:Projektarchitektur}
+
+\subsection{Überblick}
+Das Casino Gaming Platform Projekt folgt einer klassischen Client-Server-Architektur mit einer klaren Trennung zwischen Frontend und Backend. Diese Architektur wurde gewählt, um eine saubere Separation of Concerns zu gewährleisten und die Wartbarkeit sowie Erweiterbarkeit des Systems zu fördern. Die Kommunikation zwischen den beiden Schichten erfolgt über REST-\acs{API}s, die \acs{JSON}-Daten austauschen.
+
+\subsection{Technologie-Stack}
+
+\subsubsection{Frontend-Technologien}
+Für die Entwicklung der Benutzeroberfläche wurde Angular\footnote{Angular - \url{https://angular.io/}} als Framework gewählt. Angular bietet eine robuste Basis für Single Page Applications und ermöglicht eine komponentenbasierte Entwicklung. Als Package Manager kommt Bun\footnote{Bun - \url{https://bun.sh/}} zum Einsatz, welcher sowohl die Paketinstallation als auch das Bundling übernimmt. Für das Styling wird Tailwind CSS\footnote{Tailwind CSS - \url{https://tailwindcss.com/}} verwendet, welches eine konsistente und effiziente Gestaltung der Benutzeroberfläche ermöglicht.
+
+Für die Qualitätssicherung werden \acs{E2E}-Tests mit Playwright\footnote{Playwright - \url{https://playwright.dev/}} durchgeführt. Diese Tests stellen sicher, dass die gesamte Anwendung aus Benutzersicht korrekt funktioniert.
+
+\subsubsection{Backend-Technologien}
+Das Backend basiert auf Spring Boot, einem Java-Framework, das eine schnelle Entwicklung von produktionsreifen Anwendungen ermöglicht. Spring Boot wurde gewählt, da es umfangreiche Funktionalitäten out-of-the-box bietet und sich durch eine starke Community-Unterstützung auszeichnet. Als Build-Tool kommt Gradle zum Einsatz, welches flexiblere Konfigurationsmöglichkeiten als Maven bietet.
+
+Für die Datenpersistierung wird PostgreSQL\footnote{PostgreSQL - \url{https://www.postgresql.org/}} verwendet.
+
+\subsection{Systemarchitektur}
+
+\subsubsection{Frontend-Architektur}
+Das Frontend wurde als Single Page Application (SPA) konzipiert, um eine flüssige Benutzererfahrung zu gewährleisten. Die Architektur folgt Angulars modularem Ansatz und gliedert sich in verschiedene Bereiche: Feature-Module organisieren die Funktionalitäten nach Geschäftsbereichen wie Spiele und Einzahlungen. Wiederverwendbare UI-Komponenten wurden in einem Shared-Bereich zusammengefasst, um Code-Duplikation zu vermeiden.
+
+Services übernehmen die Kommunikation mit dem Backend und kapseln die Geschäftslogik. \acs{HTTP}-Interceptors behandeln globale Aspekte wie Fehlerbehandlung zentral.
+
+\subsubsection{Backend-Architektur}
+Das Backend implementiert eine klassische mehrschichtige Architektur, die eine klare Trennung der Verantwortlichkeiten gewährleistet. Die Controller-Schicht stellt die REST-\acs{API}-Endpunkte bereit und behandelt \acs{HTTP}-Anfragen. Die Service-Schicht enthält die Geschäftslogik und orchestriert verschiedene Use Cases.
+
+Die Repository-Schicht abstrahiert den Datenzugriff und verwendet Spring Data JPA für die Kommunikation mit der Datenbank. Entity-Klassen repräsentieren die Domain-Modelle und bilden die Datenbankstrukturen ab.
+
+\subsection{Datenarchitektur}
+Die Datenbank folgt einem relationalen Design mit klar definierten Entitätsbeziehungen. Das Schema gliedert sich in mehrere Hauptbereiche: Der User Management Bereich verwaltet Benutzerkonten und Benutzerprofile. Spielbezogene Daten wie Spielstände, Wetten und Ergebnisse werden in separaten Tabellen gespeichert, um die Integrität der Spiellogik zu gewährleisten.
+
+Der Financial Bereich behandelt alle monetären Transaktionen, Guthaben und Einzahlungen mit entsprechenden Audit-Trails für Compliance-Zwecke. Das Loot System verwaltet Lootboxen, deren Belohnungen und die zugehörigen Wahrscheinlichkeitsverteilungen, wobei besonderer Wert auf Transparenz und Fairness gelegt wird.
+
+\subsection{Deployment-Strategie}
+Die Deployment-Strategie wurde so konzipiert, dass sie sowohl lokale Entwicklung als auch produktive Umgebungen unterstützt. Für die lokale Entwicklung wird Docker Compose\footnote{Docker Compose - \url{https://docs.docker.com/compose/}} eingesetzt, welches eine konsistente Entwicklungsumgebung über verschiedene Entwicklerrechner hinweg gewährleistet.
+
+Frontend und Backend können unabhängig voneinander gebaut und deployed werden, was eine flexible Entwicklung und Wartung ermöglicht. Diese Entkopplung erlaubt es verschiedenen Teams, parallel zu arbeiten, ohne sich gegenseitig zu blockieren. Verschiedene Umgebungskonfigurationen durch Profile stellen sicher, dass entwicklungs- und produktionsspezifische Einstellungen sauber getrennt sind und automatisiert angewendet werden können.

projektdokumentation/Meta.tex

@@ -7,7 +7,7 @@
 
 \newcommand{\autorName}{Phan Huy Tran}
 
-\newcommand{\betriebLogo}{LogoBetrieb.pdf}
+\newcommand{\betriebLogo}{hitec-logo.png}
 
 \newcommand{\ausbildungsberuf}{Fachinformatiker für Anwendungsentwicklung}
 \newcommand{\betreff}{Dokumentation}