jank
59bb910f05
All checks were successful
CI / Get Changed Files (pull_request) Successful in 10s
CI / Backend Tests (pull_request) Has been skipped
CI / eslint (pull_request) Has been skipped
CI / Checkstyle Main (pull_request) Has been skipped
Pull Request Labeler / labeler (pull_request_target) Successful in 8s
CI / oxlint (pull_request) Has been skipped
CI / Docker frontend validation (pull_request) Has been skipped
CI / prettier (pull_request) Has been skipped
Label PRs based on size / Check PR size (pull_request) Successful in 13s
CI / Docker backend validation (pull_request) Has been skipped
CI / test-build (pull_request) Has been skipped
CI / Playwright (pull_request) Has been skipped
Claude PR Review / claude-code (pull_request) Successful in 1m29s
53 lines
2.9 KiB
TeX
53 lines
2.9 KiB
TeX
% !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.
|