# DevOps - in der Nutzung (Philipp Horstenkamp)

Die meisten Aspekte von DevOps und CI/CD wurden bereits zur Zwischenpräsentation ausführlich beschrieben.
Hier konzentriere ich mich auf Änderungen seit der Präsentation und teile Erfahrungsberichte aus dem Team.

## Poetry

Poetry kam erfolgreich zum Einsatz.
Wir nutzten Abhängigkeitsgruppen wie `root`, lint, test, doc und develop.
Dabei enthält nur die `root`-Gruppe Laufzeitabhängigkeiten.
Zusätzlich wurden Extras wie `ingest`, `transformation` und `webserver` verwendet.

- `ingest` umfasst Abhängigkeiten, die ausschließlich für das Data-Mining benötigt werden.
- `transformation` beinhaltet Werkzeuge zur Weiterverarbeitung, wie Sentimentanalysen und `rapidfuzz` für das Matching von Firmennamen.
- `webserver` umfasst Abhängigkeiten, die nur für die Darstellung von Ergebnissen auf dem Webserver eingesetzt werden.

Unser Ziel war es, Ressourcen bei Ausführung und Installation zu schonen.

## GitHub

### Dependabot

Wir setzten zusätzlich zu den GitHub Workflows Dependabot ein.
Ich bin weiterhin der Meinung, dass es für das aktiv entwickelte Projekt nicht essenziell war.
Allerdings wollte ich den Umgang damit erlernen und aktivierte es daher zusätzlich.
Die benötigte Konfiguration war wie folgt:
```yaml
version: 2
updates:
- package-ecosystem: github-actions
  directory: /
  schedule:
    interval: daily
  open-pull-requests-limit: 10
- package-ecosystem: pip
  directory: /
  schedule:
    interval: daily
  open-pull-requests-limit: 5
  ignore:
  - dependency-name: '*'
    update-types: ['version-update:semver-major']
```

Die erstellten PRs müssen vom Nutzer nur noch überprüft und gemerged werden.

### Zusätzliche Workflows

Während der Entwicklung des Projektes wurden die folgenden `workflows` hinzugefügt:

- **Dependabot-auto-merge**\
  aktiviert das automatische Mergen von PRs durch Dependabot und `github-actions[bot]`, sobald Änderungen genehmigt werden.
  Dieser Workflow wurde erstellt, um die GitHub-Berechtigungen besser zu verstehen.
- **Auto Maintenance Cycle**\
  ist ein täglich ausgeführter Workflow, der routinemäßige Arbeiten verrichtet:
  - Löschen alter Docker Images, deren Tags überschrieben wurden.
  - Aktualisieren von `pre-commit` zur Nutzung aktueller Linter.

Die ursprünglichen Workflows wurden konzeptionell nur minimal verändert.
Installierte Gruppen, Caching und Ausführungstrigger wurden optimiert, um die Ausführung zu verbessern.

## Code Qualität

Die Einarbeitung in Linter und automatisierte Tests stellte für einige Teammitglieder eine große Herausforderung dar.
Dies lag insbesondere daran, dass ganze Programmteile in Jupyter-Notebooks erstellt wurden und die Code-Struktur überdacht und angepasst werden musste.
Das nachträgliche Hinzufügen von Tests war anfangs eine Hürde.
Für Teammitglieder ohne CI/CD-Erfahrung war dies besonders frustrierend.
Nach dem ersten Beitrag zur zentralen Codebasis und der Überführung von Jupyter-Code auf den `main`-Branch verbesserte sich dies jedoch.
In der Rückmeldung wurde betont, dass die Werkzeuge zur Qualitätssicherung nach einer Eingewöhnungsphase als lernfördernd empfunden wurden.
Besonders die Erfahrung, wann Einwände von `ruff` oder `mypy` übergangen werden müssen, war wertvoll.
Mit zunehmender Erfahrung wurden einzelne Entwicklungsstränge kürzer und besser integriert.
Es wurde berichtet, dass `ruff` durch das Durchsetzen von Code-Standards in einigen Situationen Sicherheit bot.
Tools wie `mypy` waren besonders hilfreich, wo Code von verschiedenen Teammitgliedern verzahnt wurde.
Es ist schwer zu sagen, wie die Situation ohne diese Werkzeuge gewesen wäre.
Ein nachträgliches Hinzufügen von Lintern wäre jedoch nicht möglich gewesen.

Ein Versuch, ChatGPT als Code-Reviewer für Pull Requests einzusetzen, scheiterte.