RadVIS ist eine Client-Server-Anwendung zur Erfassung und Verwaltung der Radverkehrsinfrastruktur. Das System wurde 2021 vom Ministerium für Verkehr Baden-Württemberg in Auftrag gegeben und seither stetig weiterentwickelt. Weitere Informationen und Hintergründe finden Sie auf der Projekt-Seite zu aktivmobil BW.
In diesem Repository wird das Handbuch zu RadVIS gepflegt. Das Dokument wird aus den Markdown-Dateien im Ordner docs mit Docusaurus 2 gebaut.
Um das Handbuch zu erweitern wird ein Texteditor mit Markdown-Unterstützung empfohlen. Alle *.md Dateien im Verzeichnis docs stellen Hauptkapitel des Handbuchs dar. Über folgenden Kommentar kann die Reihenfolge der Kapitel definiert werden:
---
sidebar_position: 7
---
Die Hauptüberschrift mit einem # bestimmt auch die Überschrift in der Hauptnavigationsleiste links.
Überschriften mit ## generieren eine Überschrift in der Navigationsleiste rechts, die für die jeweiligen Artikel ist.
Bilder können in den üblichen Dateiformaten im Ordner docs/<kapitel>/ abgelegt werden. Unterordner können beliebig angelegt werden. Innerhalb der Dokumente werden Bilder ausgehend vom Kapitel-Ordner referenziert, z.B.:
Um das Handbuch lokal zu generieren und im Browser anzuschauen wird eine aktuelle LTS Version von Node auf dem Rechner benötigt.
Initial muss einmal folgender Befehl im Verzeichnis des Handbuchs ausgeführt werden, um benötigte Bibliotheken herunterzuladen:
npm installAnschließend kann mit diesem Befehl das Handbuch gebaut werden:
npm run startDas Handbuch wird unter http://localhost:3000/manual bereitgestellt und wird automatisch im Standardwebbrowser geöffnet.
Bei Editieren der Markdown-Dateien im docs Ordner lädt sich die Seite automatisch neu und zeigt die Änderungen an.
Das gebaute Handbuch wird in einen einfachen Docker-Container kopiert. Dieser kopiert beim Starten die Dateien in den Ordner /handbuch,
welcher über ein gemeinsam genutztes Volume mit der Spring-Boot Anwendung geteilt werden sollte.
Änderungen sollten immer auf dem Branch development stattfinden. Jeden Commit bitte mit den Überschriften der 1. und 2. Ebene beginnen, dessen
Abschnitte bearbeitet wurden. Änderungen auf dem Branch sind sofort auf der DEV-Umgebung sichtbar.
Änderungen, die sich auf Abschnitte beziehen, die Funktionen beschreiben, die bereits auf der Produktivumgebung aktiv sind, bitte per Rebase, Merge oder Cherry-Pick
auch auf den Branch productive überführen. Damit die Änderungen auf einer Umgebung sichtbar werden, muss auf dem Branch aber noch ein Tag erstellt werden und
in der Tag-Pipeline der entsprechende Job zum Deployment gestartet werden.
Synchronisation passiert automatisch in der Pipeline vom public Branch.
Der Stand dieses Branches wird auf GitHub auf den Branch main gepusht.
Änderungen aus GitHub werden dabei ggf. überschrieben, es wird also nicht gemerged!
Am einfachsten geht es über den Pipeline-Schritt create_mr_into_public (Definition im ci-template-Repo), der nur beim Schedule angezeigt wird. Läuft der also durch, sollte es einen automatischen MR geben.
Alternativ selbst einen MR von development in public anlegen.
Man muss darauf achten den source-Branch (also development) nicht zu löschen und die Änderungen sollten gesquasched werden (damit die Historie in GitHub a) nicht so lang ist und b) möglichst wenige unserer Namen enthält).