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:

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.

3.8 KiB Raw Blame History