Die Geschichte vom Rabenyx: Teil 2 – Entwicklung

23.02.2024 Daniela Grammlich

Rabenyx ist ein Akronym und bedeutet RAumBElegung bei syNYX. Zu Beginn wurde eine CLI auf Basis von Python entwickelt, welche Anfragen an die API der Nextcloud-Polls-App kapselt und die Möglichkeit bieten sollte, diese dann in einer Pipeline auszuführen.

~/rabenyx$ python3 rabenyx.py poll --help
usage: rabenyx.py poll [-h] [--delete] [--recover] [--votes] poll

positional arguments:
  poll           The poll id

optional arguments:
  -h, --help     show this help message and exit
  --delete, -d   Delete poll
  --recover, -r  Recover deleted poll
  --votes, -v    List votes from poll

Die Liste der Kommandozeilenargumente wurde nach und nach länger und deckte immer mehr Funktionalitäten ab. Damit automatisierten wir die wiederkehrenden Aufgaben mit Hilfe von zeitgesteuerten GitLab-Jobs:

Erstellen der 10 Umfragen (eine pro Werktag) für die kommenden zwei Wochen anhand einer Referenzumfrage, die wir kopierten und anpassten

for i in 0 1 2 3 4;
do
  POLL_ID=$(./rabenyx.py --clone-poll "$REFERENCE_POLL_ID" True)
  echo "Cloned poll has id $POLL_ID"
  NEXT_WEEK=$(date -d "next-monday +$i days" "+%A, %d.%m.%Y")
  ./rabenyx.py --update-poll-title "$POLL_ID" "Anwesenheit bei synyx am $NEXT_WEEK"
  TIMESTAMP_EXPIRE_DATE=$(date -d "20:00 next-monday +$i days" +%s)
  ./rabenyx.py --clone-options "$REFERENCE_POLL_ID" "$POLL_ID"
  ./rabenyx.py --update-poll-expire "$POLL_ID" "$TIMESTAMP_EXPIRE_DATE"
  ./rabenyx.py --update-poll-access "$POLL_ID" "open"
done

Eine Liste in Nextcloud mit generierten Polls.

Archivieren der Polls der vergangenen Woche

for i in 0 1 2 3 4;
do
  LAST_WEEK=$(date -d "09:00 last-monday +$i days" "+%A, %d.%m.%Y")
  echo "$LAST_WEEK"
  POLL_ID=$(./rabenyx.py --get-poll-by-title "Anwesenheit bei synyx am $LAST_WEEK")
  if [ "$POLL_ID" != "" ]; then
    ./rabenyx.py --update-poll-deleted "$POLL_ID" "$(date +%s)"
  else
    echo "No Poll found to archive --- skipping"
  fi
done

Um sicher zu gehen, dass Updates von Nextcloud oder der Polls-App nicht zu Fehlverhalten der Anwendung führten, konfigurierten wir die zeitgesteuerten GitLab-Jobs gegen unser Nextcloud-Testsystem. Schlugen diese nach Nextcloud-Updates fehl, konnten wir die Änderungen in Rabenyx überführen bevor wir das Update auf unserer produktiven Nextcloud durchführten.

Liste der scheduled Jobs von Rabenyx in GitLan.

Für jede Stage gab es die Möglichkeit, die scheduled Jobs von Rabenyx auszuführen.

Später erweiterte eine Webanwendung auf Basis des Microframeworks Flask Rabenyx um die Möglichkeit, Einträge hinzuzufügen und zu entfernen.

Die Benutzeroberfläche von Rabenyx mit der Möglichkeit, Stimmen hinzuzufügen und bereits abgegebene Stimmen wieder zu deaktivieren.

Motiviert hat uns neben dem Wert für das Office die Tatsache, dass wir an einer internen Anwendung alles durchspielen, ausprobieren und festigen konnten, was wir bereits kannten. Und natürlich haben wir auch Neues dazugelernt. Wir behandelten die Anwendung intern wie ein Open-Source-Projekt, jeder konnte etwas dazu beitragen. Und so entstanden nach und nach:

Testabdeckung in Form von Unit-Test und einem Validator gegen die Dokumentation im OpenAPI-Format
Dokumentation, speziell Entwicklerdokumentation. Eine Anwenderdokumentation hat leider gefehlt, was wir später auch spürten. Teilweise wurden Features nicht verstanden.
CI-Pipeline mit Tests, Build eines Images und Deployment der Web-App in ein Kubernetes-Cluster
Renovate-Bot

Rabenyx war eine wertvolle Unterstützung in der Hochphase der Pandemie. Inzwischen sind die Hygienemaßnahmen aufgehoben. Was aus Rabenyx wurde erzähle ich im dritten und letzten Teil.