Das Scriptmanagement umfasst verschiedene Funktionsbereiche:

Für das Erstellen von Scripten können unterschiedliche Werkzeuge eingesetzt werden. So eignet sich die PowerShell ISE mit dem ScriptRunner ISE Add-on sehr gut zum Erstellen neuer und Ändern vorhandener Scripte. Doch auch andere Editoren wie Visual Studio (Core) sind geeignet, PowerShell-Scripte zu entwickeln.

Das ScriptRunner ISE Add-on in Verbindung mit der ScriptRunner Admin App unterstützt das Anschauen, das Freigeben zum Ändern, Check-In und Check-Out von Scripten. Dabei wird eine Versionshistorie erstellt sowie im zentralen Staging-Verzeichnis bei jeder Änderung eine Versionskopie erzeugt, sofern die Archivierungsfunktion mittels ScriptRunnerSettings-Cmdlets aktiviert wurde.

Zur Versionskontrolle können auch andere Systeme wie Git, SVN, TFS und andere mit ScriptRunner verwendet werden. In diesem Fall kann ScriptRunner mit ScriptRunnerSettings-Cmdlets so konfiguriert werden, dass das Scriptverzeichnis aus dem Repository auf ein ausgechecktes Git-, SVN-, TFS- usw. Verzeichnis gesetzt werden kann.
Wichtig ist, dass sich das ausgecheckte Verzeichnis auf dem ScriptRunner Service Host befindet. Der Script Library Connector zeigt die aktuelle Konfiguration an.

ScriptRunner erkennt die Scripte in diesem Verzeichnis automatisch und bindet sie inklusive der generierten Metadaten in ScriptRunner ein. Unter anderem wird die Beschreibung für das Script automatisch aus der Synopsis oder der Beschreibung im Script-Header ausgelesen und sowohl in der ScriptRunner Admin App als auch in der Delegate App angezeigt und auch in Aktionen und Reports verwendet.

Die Aktualisierung des Git-, SVN-, TFS- etc. Verzeichnisses kann nun von ScriptRunner selbst über ein entsprechendes Script mittels Scheduled Action durchgeführt werden. Änderungen, neue Scripte etc. werden automatisch erkannt und es wird geprüft, ob die Skripte noch zu den zugeordneten Aktionen passen, Fehler enthalten oder noch verwendet werden können.

Der ScriptRunner wurde auch um eine Funktion zum Importieren bereits vorhandener Scripte erweitert. In diesem Zusammenhang wurden die Beispielscripte aus der Installationsroutine herausgenommen und sind separat im Installationspaket enthalten. So kann jeder Kunde auf Beispiele zugreifen und diese bei Bedarf in seine ScriptRunner-Umgebung importieren. Die importierten Skripte werden im Repository unter dem Verzeichnis _UPLOAD_ abgelegt. Bereits beim Import können dem Script Tags zugewiesen werden.

Das Tagging von Scripten wurde weiter ausgebaut und um System-Tags ergänzt. In der Grundfunktion werden Unterverzeichnisse des Script Library-Verzeichnisses von ScriptRunner automatisch in Tags abgebildet. Wird ein Script zwischen Unterverzeichnissen verschoben, ändern sich auch seine Basis-Tags. Dies ist insbesondere vor dem Hintergrund der Integration von Git, SVN, TFS und anderen Verzeichnissen zu beachten.

Die automatisch generierten Tags an Scripten können entfernt, geändert oder ergänzt werden, da sie Metadaten der Scripte sind. Die ursprüngliche Verzeichnisstruktur bleibt dabei erhalten.

Neben diesen Tags gibt es einige System-Tags in ScriptRunner. Zum Beispiel wird ein mit der Admin App importiertes Script mit dem Tag _UPLOAD_ gekennzeichnet, um es besser identifizieren und suchen zu können. Dieses System-Tag kann später wieder entfernt werden.

Wird ein Script in der ScriptRunner Admin App zur Bearbeitung mit dem ISE Add-on freigegeben, erhält es das System-Tag _DEV_ und steuert den Check-Out- und Check-In-Prozess. Wird die Freigabe dann wieder zurückgenommen, wird das System-Tag automatisch wieder entfernt.

Das Testen geänderter Scripte ist ein wichtiger Bestandteil der Qualitätssicherung und der Prozesskette für Scripte. ScriptRunner unterstützt das Testen mit zwei sehr unterschiedlichen Funktionen: Staging und Pester.

Beim Staging wird ein geändertes PowerShell-Script, das noch nicht eingecheckt wurde, in der zugehörigen Aktion separat behandelt. Mit der Admin App kann das geänderte Script auf einem Testsystem ausgeführt werden, während die gleiche Aktion z.B. für Delegate App-Anwender mit dem bisherigen Script auf dem bisherigen Zielsystem ausgeführt wird. Somit ermöglicht ScriptRunner einem DevOps-Engineer, sehr agil Änderungen an Scripten vorzunehmen und diese zu testen.

Pester ist ein Unit-Test-Framework zum Testen von selbst geschriebenen Powershell-Funktionen. Neben dem notwendigen PowerShell-Modul „Pester“ schreibt der DevOp entsprechende Testskripte, indem er eine eigene Funktion mit dem Pester-Modul aufruft. Die entsprechenden Testskripte werden in ScriptRunner unter der Unterbibliothek Pester organisiert.

Mehr über Pester erfahren Sie in unserem Artikel Einführung in Pester – Part 1.

Scripte werden von ScriptRunner letztlich in Aktionen verwendet. Eine Aktion ist eine Ausführungsrichtlinie, die festlegt, welches Script auf welchem System mit welchem administrativen Konto ausgeführt werden kann, welche Parameter eingegeben werden und welche voreingestellt sind, wer berechtigt ist, die Aktion zu starten und wie der Start erfolgt (manuell, delegiert, geplant, ereignisgesteuert).

Die Scriptverwaltung im ScriptRunner unterstützt die Erstellung und Einhaltung von Ausführungsrichtlinien mit verschiedenen Funktionen. Die kontinuierliche Überwachung der Script Library Verzeichnisse stellt sicher, dass gewünschte oder unerwünschte Änderungen bemerkt werden. Neue Scripte, die z. B. direkt in das Verzeichnis kopiert wurden, werden automatisch erkannt. Beim Parsen der Scripte werden Metadaten erzeugt, die dann auf Änderungen überprüft werden, z. B. wenn Parameterdefinitionen der Scripte geändert wurden und nicht mehr zur bereits konfigurierten Aktion/Policy passen. Die entsprechende Aktion wird als fehlerhaft behandelt und nicht mehr ausgeführt. Das Gleiche gilt für Skripte, die fälschlicherweise oder absichtlich aus dem Verzeichnis der Scriptbibliothek gelöscht wurden.