Add a CI/CD workflow graph (#585)

.gitignore

@@ -244,3 +244,4 @@ secrets*.json
 remote.json
 requirements.txt
 /documentations/seminararbeiten/DevOps/seminararbeit/dev-ops.pdf
+.$*.drawio.bkp

documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md

@@ -854,11 +854,11 @@ Eine Schritt-für-Schritt-Beschreibung verdeutlicht den Prozess:
 Die Workflows werden für Pushes und PRs aus dem entsprechenden Branch heraus ausgeführt.
 
 Bei Pushen und PRs werden die Workflows aus dem entsprechenden Branch verwendet.
-GitHub Actions führen alle `jobs` parallel aus, im Gegensatz zu sequentiellen Abläufen bei anderen CI/CD-Tools wie z.B. Jenkins.
-GitHub Actions ermöglichen parametrisierte Matrix Builds.
+GitHub-Actions führen alle `jobs` parallel aus, im Gegensatz zu sequentiellen Abläufen bei anderen CI/CD-Tools wie z.B. Jenkins.
+GitHub-Actions ermöglichen parametrisierte Matrix Builds.
 
 Sie müssen in den Repository-Einstellungen unter `Actions` aktiviert werden.
-Eine vollständige Schemabeschreibung für GitHub `workflows` findet sich [hier](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions).
+Eine vollständige Schemabeschreibung für GitHub-`workflows` findet sich [hier](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions).
 
 #### Implementierte Workflows
 
@@ -890,10 +890,10 @@ Für dieses Projekt wurden folgende Workflows implementiert:
   - Für verschiedene Docker-Container gibt es spezifische Abhängigkeitsdefinitionen in unserem Poetry-Python-Projekt, die pro `target` in der Dockerfile nachinstalliert werden.
 
 - **Documentation-Action**:
-  - Baut die Dokumentation mit `sphinx` und lädt sie als GitHub Pages hoch.
+  - Baut die Dokumentation mit `sphinx` und lädt sie als GitHub-Pages hoch.
   - Der Dokumentationsbau erstellt eine HTML-Webseite mit Sphinx.
   - Die Dokumentation wird nur in Pull Requests oder auf dem `main`-Branch bereitgestellt und kann heruntergeladen werden.
-  - Die Bereitstellung der Dokumentation erfolgt nur auf dem `main`-Branch und wird als externe Webseite auf den GitHub Pages veröffentlicht.
+  - Die Bereitstellung der Dokumentation erfolgt nur auf dem `main`-Branch und wird als externe Webseite auf den GitHub-Pages veröffentlicht.
 
 
 #### Self-Hosted Act-Runner
@@ -907,9 +907,9 @@ Die Einrichtung gemäß der GitHub-Anleitung war relativ einfach, stieß jedoch
 4. Einige KI-Modelle lassen sich auf dem Raspberry Pi nicht ausführen, da er nicht genügend RAM hat.
 5. Geringe Parallelisierung und langsame Prozessoren führen zu langen Wartezeiten bei Tests und Linting-Ergebnissen.
 6. Das Risiko, von GitHub aufgrund zu vieler Downloads gesperrt zu werden, ist geringer.
-7. GitHub Actions sind für Open-Source-Projekte kostenlos, weshalb es relativ wenig Dokumentation zum Hosting eigener Runner gibt.
+7. GitHub-Actions sind für Open-Source-Projekte kostenlos, weshalb es relativ wenig Dokumentation zum Hosting eigener Runner gibt.
 
-Letztendlich wurde uns jedoch die Nutzung von GitHub Actions über den FH-SWF-Account ermöglicht, sodass der self-hosted Runner nicht zum Einsatz kommen musste.
+Letztendlich wurde uns jedoch die Nutzung von GitHub-Actions über den FH-SWF-Account ermöglicht, sodass der self-hosted Runner nicht zum Einsatz kommen musste.
 Zur Zeit Nutze ich persönlich den Gitea's Act Runner welcher ein Fork von GitHubs self-hosted Runner ist.
 Es ist also möglich diesen zu Nutzen.
 Dies hat aber eindeutige Grenzen und ist bei weitem nicht so komfortabel, ist aber mit nicht ARM32/64 Geräten gut möglich.
@@ -932,9 +932,9 @@ Dependabot, der GitHub OWASP-Scanner, ermöglicht es, den Standard-Branch eines
 Abhängig von der Konfiguration kann Dependabot Handlungsempfehlungen aussprechen oder automatisch Pull Requests erstellen, um Sicherheitslücken zu schließen.
 Für unser Projekt ist der Einsatz von Dependabot aktuell nicht geplant.
 Dies liegt daran, dass es mit `pip-audit` redundant wäre und erst nach Abschluss der aktiven Entwicklungsphase des Projekts Vorteile bietet.
-Dependabot kann Routineaufgaben übernehmen, insbesondere, wenn GitHub Actions implementiert sind und vorgeschlagene Änderungen sofort testen.
+Dependabot kann Routineaufgaben übernehmen, insbesondere, wenn GitHub-Actions implementiert sind und vorgeschlagene Änderungen sofort testen.
 Dependabot unterstützt eine Vielzahl von Programmiersprachen und Tools zur Abhängigkeitsverwaltung.
-Es ermöglicht nicht nur Scans von Python-Abhängigkeiten, sondern auch das Scannen und Aktualisieren von GitHub Actions.
+Es ermöglicht nicht nur Scans von Python-Abhängigkeiten, sondern auch das Scannen und Aktualisieren von GitHub-Actions.
 
 Natürlich wäre es einfach möglich nur Dependabot zu nutzen. Da ich aber im beruflichen Kontext `pip-audit` verwende, war dies einfacher.
 
@@ -1082,6 +1082,34 @@ Daher wurde bei der Präsentation dieser Werkzeuge die Zustimmung des Teams für
 
 Die Zustimmung wurde erteilt, und ein erster Entwurf der Pipelines und Tools wurde in Betrieb genommen.
 
+### Übersicht über den CI/CD Workflow
+
+Das folgende Diagramm zeigt den CI/CD und DevOps Arbeitsfluss.
+
+```{eval-rst}
+.. drawio-figure:: workflow.drawio
+   :format: png
+   :page-index: 1
+```
+
+Zu sehen sind 4 verschiedene Git-Branches.
+Die oberen beiden Zeilen stellen die lokale Entwicklung eines neuen Features oder eines Bugfixes dar.
+Dabei wird neuer Code und Tests geschrieben. Dies wird durch PyCharm und VS-Code visualisiert.
+Dieses wird dann in einen neuen Branch committed.
+Hier wird dieser `New Feature/local` genannt.
+Diese wird für jeden Commit, hier als Node eingezeichnet, durch pre-commit mit `ruff`, `mypy`, `black` und 28 weiteren Werkzeugen validiert.
+In dem oben dargestellten Beispiel wird nach einem zweiten Commit auf GitHub gepusht.
+Hier durch einen grünen Pfeil dargestellt. Dieser Push wird dann von GitHub getestet.
+In dem Beispielarbeitsfluss wird noch ein weiterer Commit nachgelegt und hinterher gepusht.
+Anschließend wird ein Merge-Request erstellt. Um diese zu mergen, müssen sowohl die GitHub Actions passen als auch ein Review erfolgen.
+Der so neue Merge-Commit auf dem `main`-Branch von GitHub triggerd noch einmal die Tests und baut sowohl neue Docker Images als auch eine neue Dokumentation via Sphinx.
+Die Docker-Images werden dann vom Portainer auf dem `jupiter.fh-swf.de`-Server gepulled und deployed.
+Die Dokumentation wird als neue Projektdokumentation auf den GitHub-Pages gebaut.
+Die Deployments sind hier durch blaue Pfeile dargestellt.
+Zuletzt kann die so neue Version vom `main`-Branch wieder auf den lokalen Server gepulled werden.
+Dabei installiert `pre-commit` eventuell neue Dependencies via `poetry`.
+Damit ist die Entwicklung eines neuen Features abgeschlossen und der Arbeitszyklus kann für ein neues Feature oder einen Bugfix neu begonnen werden.
+
 ### Fazit
 
 Es gibt zahlreiche hilfreiche Werkzeuge für die Softwareentwicklung.