From 58a6c340996b5f05c9b4abb58848a23e452ff9a1 Mon Sep 17 00:00:00 2001 From: Philipp Horstenkamp Date: Wed, 24 Jan 2024 19:44:04 +0100 Subject: [PATCH 1/5] Added a CI/CD Graph --- .gitignore | 1 + .../PhHo/workflow.drawio | 278 ++++++++++++++++++ 2 files changed, 279 insertions(+) create mode 100644 documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/workflow.drawio diff --git a/.gitignore b/.gitignore index 693392d..91ee24a 100644 --- a/.gitignore +++ b/.gitignore @@ -244,3 +244,4 @@ secrets*.json remote.json requirements.txt /documentations/seminararbeiten/DevOps/seminararbeit/dev-ops.pdf +.$*.drawio.bkp diff --git a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/workflow.drawio b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/workflow.drawio new file mode 100644 index 0000000..8a86966 --- /dev/null +++ b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/workflow.drawio @@ -0,0 +1,278 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From 253393a29f48a5760879b287f5f51d42e16523b1 Mon Sep 17 00:00:00 2001 From: Philipp Horstenkamp Date: Wed, 24 Jan 2024 20:15:22 +0100 Subject: [PATCH 2/5] Reworked the diagramm a bit and added it into the documentation with a short text. --- .../PhHo/dev-ops.md | 46 +++++++++++++++---- .../PhHo/workflow.drawio | 18 ++++---- 2 files changed, 46 insertions(+), 18 deletions(-) diff --git a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md index 0623cb1..cde3cc3 100644 --- a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md +++ b/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. Hierdurch 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 vielen 28 anderen 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. diff --git a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/workflow.drawio b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/workflow.drawio index 8a86966..dfe819e 100644 --- a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/workflow.drawio +++ b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/workflow.drawio @@ -1,16 +1,16 @@ - + - + - + @@ -88,9 +88,6 @@ - - - @@ -161,19 +158,19 @@ - + - + - + @@ -272,6 +269,9 @@ + + + From 28f6b573b30c2683e77c83c00aebc3f9a3359998 Mon Sep 17 00:00:00 2001 From: Philipp Horstenkamp Date: Wed, 24 Jan 2024 21:15:59 +0100 Subject: [PATCH 3/5] Update documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md Co-authored-by: Tristan Nolde --- .../Zwischenbericht_und_Praesentation/PhHo/dev-ops.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md index cde3cc3..2e41256 100644 --- a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md +++ b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md @@ -1094,7 +1094,7 @@ Das folgende diagramm zeigt den CI/CD und DevOps Arbeitsfluss. 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. Hierdurch wird durch PyCharm und VS-Code visualisiert. +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 vielen 28 anderen Werkzeugen validiert. From 23a019c16f8c6c685564e885c8ddbd8e35ae865b Mon Sep 17 00:00:00 2001 From: Philipp Horstenkamp Date: Wed, 24 Jan 2024 21:16:08 +0100 Subject: [PATCH 4/5] Update documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md Co-authored-by: Tristan Nolde --- .../Zwischenbericht_und_Praesentation/PhHo/dev-ops.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md index 2e41256..cffcf24 100644 --- a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md +++ b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md @@ -1084,7 +1084,7 @@ Die Zustimmung wurde erteilt, und ein erster Entwurf der Pipelines und Tools wur ### Übersicht über den CI/CD Workflow -Das folgende diagramm zeigt den CI/CD und DevOps Arbeitsfluss. +Das folgende Diagramm zeigt den CI/CD und DevOps Arbeitsfluss. ```{eval-rst} .. drawio-figure:: workflow.drawio From 27e97e177fd6ff5136f82b03d0cbe0b201189109 Mon Sep 17 00:00:00 2001 From: Philipp Horstenkamp Date: Wed, 24 Jan 2024 21:16:37 +0100 Subject: [PATCH 5/5] Update documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md Co-authored-by: Tristan Nolde --- .../Zwischenbericht_und_Praesentation/PhHo/dev-ops.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md index cffcf24..cffbb7e 100644 --- a/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md +++ b/documentations/Ergebnisse/Zwischenbericht_und_Praesentation/PhHo/dev-ops.md @@ -1097,7 +1097,7 @@ Die oberen beiden Zeilen stellen die lokale Entwicklung eines neuen Features ode 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 vielen 28 anderen Werkzeugen validiert. +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.