[Modul] Skript-Bereitstellung

  1. Voraussetzungen

    • ab IP-Symcon 6.0
  2. Enthaltene Module
    ScriptDeployment:

  3. Installation
    Über den Module Store!
    Zur Zeit noch Beta, also direkt nach Symcon Skript-Bereitstellung suchen.

  4. 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

  1. 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).
  2. alle Skripte eines Paketes werden in einem Paket-Verzeichnis unter einen sinnvollen Namen abgelegt
  3. 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.

2 „Gefällt mir“

Richtig coole Idee!!! :+1: :pray: :loveips:

Finde ich auch…nur… ich versteh es nicht :smiley:
Ok, der Sinn besteht im einfachen Teilen von Skripten. Aber wie soll das funktionieren?
Und ja, ich habs mir drei mal durchgelesen.
Im Store finde ich nichts :wink:

Ja, die Suche, falle ich immer wieder drauf rein … Suchbegriff muss richtigerweise „Symcon Skript-Bereitstellung“ lauten

Teilen trifft es nicht so ganz 100%
Ich habe ein paar Skripte, die auf den verschiedenen (meiner) Systeme gleich halten will. Und manuell ist das aufwendig und fehlerträchtig.
Und mein Testsystem hatte ich mal seinerzeit vom ProdSys geklont und damit ist es ja schon längst auseinander gelaufen.
Und so habe ich die relevanten Skripte in einem Git-Repository, dort halte ich sie bei Änderungen manuell aktuell und kann dann „auf Knopfdruck“ die anderen Systeme aktualisieren.
Beispiel für solche Repositories wäre zB GitHub - demel42/ips-deployment-basics oder GitHub - demel42/ips-deployment-inventory.
Wenn man das nicht im Git ablegen möchte, dann kann man das mittels ZIP-Archiv machen.

Ich bin noch nicht dazu gekommen das Modul zu testen.

Wenn man schon ein Repo hat - das nutzen und teilen?

Gruß Heiko

Das Repo muss einen bestimmten Aufbau haben, aber wenn man das so hat, dann geht das auf jeden Fall.

Ist für mich eine Ebene unterhalb eines Moduls aber mit einem geregelten Update-Verfahren.

Wie immer, ist das natürlich aus persönlichem Bedarf entstanden, von daher vermutlich noch ziemlich ist ein anderer Blick und Input natürlich wichtig

1 „Gefällt mir“

Ich versuch das die nächsten Tage mal - habe auch mehrere Installationen zu bedienen :slight_smile: