Versionierung von Skripte

Immer mal wieder …

… gibt es im IP-Symcon Forum Anfragen hinsichtlich dem „externen“ Bearbeiten bzw. Versionieren von Skripten und die unterschiedlichsten Lösungen dazu. Meistens läuft IPS auf einem Server, auf welchem man keinen direkten Dateizugriff hat. Normalerweise arbeitet man mit dem symcon-eigenen Scripteditor, welcher solide seinen Dienst tut oder man loggt sich remote via SSH am Server ein und bearbeitet (besser patched) kleine Sachen direkt auf der Kommandozeile. Für die normalen Dinge des Lebens ist das absolut ausreichend und auch perfekt so – alles an einem Ort und per Browser von überall zugreifbar.

Es gibt aber auch Skripte – gerade welche man im Forum veröffentlicht – die schon den Charakter eines eigenen kleinen Programmes haben und durch die Community einiges an Veränderung erfahren. Meistens schreiben die Autoren in den Header den aktuellen Stand bzw. Versionsnummer oder Datum rein. Eine echte Versionierung ist das natürlich nicht.

Liebgewonnen aus der Modulentwicklung

Mit der Modulentwicklung und der zur Verfügung gestellten „Extension for IP-Symcon“ zog Visual Studio Code endgültig als IDE bei mir ein. Nach einer gewissen Eingewöhnungsphase kann ich mir eine Entwicklung ohne gar nicht mehr vorstellen. Der Code-Editor erlangt immer größere Beliebtheit, er ist Open Source, ist für unzählige Programmiersprachen konfigurierbar und die Versionierung mittels GIT ist auch gleich mit dabei. Mittels zahlreicher Erweiterungen (Extensions) kann man sich den Editor perfekt zu seinem Programmierknecht gefügig machen. Dementsprechend liegt es natürlich nahe den Editor für „größere“ Skripte zu verwenden.

Der große Unterschied

Warum also nicht einfach loslegen und einfach mal machen? Die Modulentwicklung hat im Unterschied zur Skriptbearbeitung einen klaren definierten Installations- und Updateprozess, d.h. die Versionierung von Modulen ist schon Teil bzw. Bedingung der Entwicklung. Ein Modul kann zwar via Store oder Modul Control installiert werden, aber Ursprung dafür ist immer ein Link auf ein Commit von einem Repository. Skripte dagegen kann man einfach so in IPS anlegen, bearbeiten und auch wieder aus den System löschen.

Jetzt könnte man sagen: „Warum nicht genauso machen wie bei den Modulen?“. Nein – für mich kein gangbarer Weg, weil man dann den gesamten Mechanismus der Skriptverwaltung in IPS aushebelt und sich die Flexibilität nimmt – schnell mal ein Fehler auszumerzen oder eine Idee auszuprobieren. Und wie gesagt, jedes Skript muss auch nicht versioniert werden.

Download & Upload via (S)FTP

Es gibt somit nicht den zentralen Ort der Skriptverwaltung, oder anders ausgedrückt – das Skript in IPS ist für mich die einzige „Wahrheit“ 🙂

Es gibt auch Module, welche die Kommunikation mit externen Repositories (Github usw.) übernehmen, aber die Handhabung war für mich irgendwie unpraktikabel und ich möchte auch nicht die bestehende IPS Installation beeinflussen. D.h. ich möchte weiterhin in IPS arbeiten ohne jegliche Einschränkungen bzw. Veränderungen und trotzdem für mich ein Sammlung an ausgewählten Skripten extern bearbeiten und versionieren.

Bei der Suche nach einer Lösung bin ich jetzt auf eine Extension gestoßen, welche diesem Vorgehen schon sehr weit entgegenkommt => FTP-Sync extension for VS Code!

Was ist der große Vorteil der Erweiterung? Mit ihr kann man selektiv einzelne Dateien sowohl downloaden als auch uploaden, also in beide Richtungen. Will man also ein Skript mittels VSC extern bearbeiten, dann kann man sich mit einem Klick die aktuelle Version vom IPS-System holen, bearbeiten, versionieren und dann einfach wieder ins System zurück uploaden. Wie auf dem Bild schematisch dargestellt übernimmt Visual Studio eine Art Broker zwischen IPS und Versionskontrollsystem.

View post on imgur.com

Zusammenfassung

Ich habe mir jetzt auf meinem Entwicklungsrechner ein Arbeitsbereich mit Visual Studio Code eingerichtet, welches alle versionierungsbedürftigen Skripte beinhaltet und dieses dann als Github Repository angelegt.

Da die Extension SFTP unterstützt und es auch noch mit privaten SSH Keys umgehen kann, musste ich an meinem IPS Server nicht einmal etwas anpassen.

Einen kleinen Wermutstropfen gibt es bislang noch, zwar unterstützt die Erweiterung das remote Browsen über alle Dateien, aber das „Downloaden“ in den lokalen Bestand funktioniert bei mir nicht wie erwartet. Die heruntergeladene Datei landet dann außerhalb des Projektes, also ein Verzeichnis weiter oben. Dabei wird auch noch der Projektverzeichnisname vor dem eigentlichen Dateinamen angefügt. Ich denke da ist ein kleiner Suchen-und-Ersetzen-Bug drin. Ich habe mir jetzt erstmal so beholfen die entsprechenden Skripte per WinSCP rüber zu kopieren und ab da konnte ich die gegenseitige Synchronisierung starten. Vielleicht gibt es da ja in Zukunft noch eine Lösung.

Fazit
Die Extension macht grundsätzlich was sie soll, nämlich die Skripte in beide Richtungen zu synchronisieren. Würde jetzt noch das Browsen und gezielte Auswählen einer auf dem Server verfügbaren Datei (Skripts) möglich wäre die Lösung perfekt.

Update 23.03.2022:

Habe gerade einen Fix für das Download-Problem gefunden. In der Datei list-command.js gibt es eine Function „GetLocalPath“, welche den Remote-Pfad durch den Lokalen-Pfad ersetzt und dabei den letzten Slash (/) verschwinden lässt 🙁

Hier mein Patch:

function getLocalPath(fileRemotePath) {
return {
fsPath: fileRemotePath.replace(ftpconfig.getConfig().remotePath, ftpconfig.rootPath().fsPath + '/')
};
}