-
Voraussetzungen
- ab IP-Symcon 6.0
-
Enthaltene Module
ScriptDeployment: -
Installation
Über den Module Store!
Zur Zeit noch Beta, also direkt nach Symcon Skript-Bereitstellung suchen. -
Dokumentation
IPSymconScriptDeployment
Hintergrund: ich habe inzwischen einige IPS-Installationen im privaten Umfeld, die ich betreue.
„Natürlich“ sind das Systeme, die so konzipiert sind, wie mein eigenes System; d.h. es sind auch diverse Skripte im Einsatz, die im Laufe der Zeit entstanden sind und natürlich weiter entwickelt werden. Und damit stellte sich mir die Frage, wie ich mit Änderungen verfahren kann.
Eine Sache, die ich immer sehr aufwendig fand, war der manuelle Abgleich der Script auf den Systemen. Einzelne kopieren, vergleichen, eventuelle lokale Angabe sichern/ersetzen …
Nein, das war mir dann doch zu lästig. Daher habe ich ein Modul entworfen, mit dem man Skripte bereitstellen/verteilen kann: IPSymconScriptDeployment
Um das machen zu können sind zwei Schritte erforderlich
- individuelle Informationen müssen aus den Skripten entfernt werden. Das mache ich mit Hilfe eines Mapping-Skriptes (meines heisst GetLocalConfig), das ein Ident übergeben bekommt und einen Schlüsselwert zurück liefert. Das sind z.B. bestimmte Hilfsskripte (die ja auf jedem System potentiell eine andere Objekt-ID haben) oder Benutzerkennungen etc pp.
Damit sind die zu verteilenden Skripte völlig unabhängig, zudem sind alle relevanten Funktionen in einem Skript zusammengefasst (und damit auch besser wartbar). - alle Skripte eines Paketes werden in einem Paket-Verzeichnis unter einen sinnvollen Namen abgelegt
- in diesem Paket befinden sich auch eine Verzeichnisdatei namens dictionary.json, die alle relevanten Informationen enthält.
Zur Verteilung dieser Pakete gibt es zwei Möglichkeiten
- dieses Paket wird in einem Github-Repository abgelegt. Die URL zum Download des Paketes wird in der Instanz eingetragen. Vorteil: es kann zyklisch nachgeschaut werden, ob ein Update anstehen würde.
- das Paket wird als ZIP-Archiv gepackt und über eine Instanz-Funktion manuell in das IPS geladen
Egal auf welchem Weg das Paket auf dem Ziel-IPS landet, wird es dann in einer Mediendatei gesichert und bei Bedarf in einem zu konfigurierenden temporären Verzeichnis ausgepackt. Die Verknüpfung der Skripte mit dem lokalen Verzeichnis wird in einem weiteren Medien-Objekt gesichert (Objekt-ID zu o.g. Skript-Name).
Es wird auch eine nachträgliche Integration von Bestandssystemen unterstützt.
Es kann in jedem IPS mehrere solche Pakete existieren, damit man das in sinnvolle Pakete zerlegen kann.
Nebenbei kann ich so mein Testsystem ziemlich nah am Produktivsystem halten, ohne den Aufwand zu betreiben, die settings.json zu kopieren und dann alles rauszuwerfen, was nur im Produktivsysten sein darf.